In my line of work, I get to interview software developers. I've had to invent questions over the last while, and along with a handful of "Describe in the past when you.." questions, I have a bunch of raw technical questions I ask candidates. I always let the candidates know that it's important to say "I don't know", if they don't know. There's absolutely nothing wrong with saying that because nobody knows everything (except our recruiter who has heard answers so many times, she can answer them):
- What's the difference between TCP and UDP? When would you use each one?
- What's the difference between an INNER JOIN and OUTER JOIN?
- What are pass-by-value and pass-by-reference? When is each one used?
- In regular expressions, what are the differences between greedy and lazy?
- etc..
When candidates answer the questions, I'm looking for three things:
- Honesty: This is a double-edged sword. If your resume claims they have a lot of a particular experience, I'll expect them to be able to answer questions in that domain; and vice-versa if they don't.
- Clarity: Thinking outloud is more than welcome, and so are revisions to answers ("Wait, no.."). But when they arrive at answer, they need to be able to explain it in a way that I can understand.
- Correctness: When they answer with a proud smile on their face and look at me knowing that they just aced the question - but got it completely wrong - warning bells go off in my head.
If you've ever been interviewed by me, and didn't get the position, please keep in mind that your answers to these questions are only part of what I use to gauge your skills, and I'm only one of a few people whose opinions matter.
No comments:
Post a Comment