More DBA job interview questions and answers at
http://dba.fyicenter.com/Interview-Questions/
(Continued from previous question...)
5 Hints for a successful technical job interview
5 Simple things to make your job interviews better:
1. Smile. Seriously, when you shake everybody's hand, smile at them. These people are looking at you trying to decide if they want to spend 8 hours a day 5 days a week with you for the foreseeable future. Put them at ease, make them comfortable with you. Too often I see people in interviews extremely uptight and nervous. It's hard to want to work with an over wound stress ball. When they're comparing candidates at the end of the process if there are two equally qualified candidates they're going to choose the one who seemed the most personable. Every time. Try hard at this.
2. Have your story ready. Look over your resume and pick out 3-4 projects that highlight some skill or experience of yours, especially those that match the job description. Boil it down to a 4-5 sentence story and when you see an opening in the interview let it out. This is your chance to say: "You have a need, I have filled this very need before. This is how". Practice your stories on others (significant others are a good place for this) so that you get used to telling it. Make sure it's smooth and concise. If you try to do this on the fly you'll forget something, or say too much, or ramble. But if your practiced and ready you can hit your cues and make sure you communicate exactly how you'll contribute. A polished story also gives the impression that you know what you're doing, and it gives you a chance to show off your communication skills. None of this stuff will come up explicitly when they talk about you, but they'll all remember it.
3. Don't try to BS questions. They're asking you the question. And they made up the questions. They know the answer, and they have an expectation for what you'll provide. Some people think they can tease out the answer by starting vague and triangulating. Or just straight BS. Interviewers can tell and you look like an idiot or a liar. If you don't know an answer say: I have no idea. Then sketch out how you would find out. Not being able to answer a question doesn't kill your chances, but trying to weasel around it probably will.
4. Write some code by hand on paper the night before. Writing code by hand and writing code by IDE are very different. You won't have IntelliSense and code completion going for you on a white board. You won't be able to open up a project template. You don't want to get derailed on a simple question because you can't remember the syntax for a command line program in C#. Make sure you can write a basic hello world, that compiles and runs, in any language you might be asked questions on. Write a couple the night before so when you have an actual problem to work on you can work on the problem not trying to remember all the stuff the IDE does for you.
During interviews I give people a lot of slack for things like this, because IDE's do a lot of the basic set up work, and I imagine that's pretty typical. But if you can smoothly whip out a running program you look a lot more competent than you do trying to explain that "whatever the namespace definition looks like goes right here and the
main would go here with arguments I think".
5. Ask the Joel Test Questions. Every interview ends with "Do you have any questions?" and it's always the hardest part of the interview for people. Pick a few of the questions from Joel's test and ask. You'll learn a lot about the company, which is good, and you'll broadcast your professionalism. People who take the time to think about these sorts of things (version control, build processes, design, and specifications) are more than just code monkeys, they're well rounded developers who can contribute to the overall success of projects. They're a great series of questions to make you look smart and learn something at the same time.
None of these hints is going to get you a job if you're unqualified. But they will help you convince people of your qualifications and convince them that you would a valuable team member.
(Continued on next question...)
