11–20 of 58 posts
Earlier quoted context omitted.
Agreed. My first job they gave me a copy of Deitel & Deitel's "C How to program" along with the test. You actually lost points if you didn't open it!
You know the syntax of switch in the language you have been using in the last three months. If you don't, something's wrong!
Trick questions, or questions with some kind of gottcha have no place in interviews, However, simple, straightforward programming exercises are essential. I've seen people who claim to have X years of industry experience who can talk a good game, but literally can't write a switch statement without reference to the internet. I also like to ask people to peer review some code with both obvious and more subtle errors i…
Some questions do let you guage how the person responds to stress and unknown environments - that may be helpful.
You need to consider what you are trying to determine by asking any question. Really, what is it about the candidate you want to know? After pinning down precisely what you want to know then tailor a question to figure this out with as little peripheral stuff as possible.
If you want to know if someone can generate some code in their preferred language on the spot, fine. Pick a very simple problem, like 'Write a program to display numbers in the fibinocci sequence', and explain the fib seq to them if they don't know it. I wouldn't even count points off if they make any kind of mistake that a compiler would catch as long as they know how to fix it. Have them do it on the white board.
This kind of Q isn't designed to figure out how much they know of 10 different languages. It's designed to see if they can put some code down in their preferred language and have it do something useful.
The biggest constraint in an interview isn't the honesty of the candidate, or even their knowledge; it's the N hour time limit. Your goal as the interviewer is to squeeze as much information about who the candidate really is in the time allowed.
If you have the sense from whiteboard discussions that the candidate understands computer science (like gets recursion) but you want to make sure they can code, why not choose a subset of a problem that you (your company) needs to solve?
If you have the sense from whiteboard discussions that the candidate understands computer science (like gets recursion) but you want to make sure they can code, why not choose a subset of a problem that you (your company) needs to solve?
Good way to get some free consulting ;-)
I interviewed once with a company that OCRed medical documents. One guy held up a sheet of paper and asked "How much memory does this take up?" which was a deliberately open-ended question. I was initially stumped, but then he started feeding me domain knowledge and assumptions, such as common DPI values and expected fidelity. Then I started coming up with estimates.
I don't think he expected me to have answer right off. I think he wanted to see how much I could figure out on my own if given hints.
Earlier quoted context omitted.
You know the syntax of switch in the language you have been using in the last three months. If you don't, something's wrong!
Sure, but we're talking about testing ability vs. memory - switch is incidental.
You can't be a good programmer and forget the syntax of the language you are working in. If you need to look up something as fundamental as switch statement in the internet, it's like a writer looking up words in the dictionary before writing them down in his novel.
Trick questions, or questions with some kind of gottcha have no place in interviews, However, simple, straightforward programming exercises are essential. I've seen people who claim to have X years of industry experience who can talk a good game, but literally can't write a switch statement without reference to the internet. I also like to ask people to peer review some code with both obvious and more subtle errors i…
Hmm... I know > 10 languages. I'm not sure I could remember the exact syntax in several of those languages on the spot. Is it case, is it switch, etc. If you do this, your test is on rote memorization. Give them a novel problem and have them solve it with a real computer and in tact syntax lookup. Then see what and how they did it and go over their reasoning. I'll hire the guy with the wisdom over the guy who can spi…
I do agree though that testing specific language skills is mostly pointless. The only time I've been given a programming test as part of an interview I was given a basic language spec that filled a couple pages then a book of problems to solve in the new language. Thats the way you should test programming skill in my opinion.
Programming challenges sort the wheat from the chaff - in particular those who cannot code at all, but beyond that I've rarely found them predictive of future performance. Much more important that you hire a good fit for your company. An unhappy or toxic coder can bring a startup to its knees - hire slow, fire fast and all that.