Wednesday, August 06, 2008
Thoughts on "Coding Interviews"
In my job search, I was asked to write code in a couple of interviews. Personally, I don't like asking coding questions in interviews, and if I have a question about a programmer's ability, I'll use a simple programming test that's emailed to them a couple of days before - and ask them to explain their code in the interview.
For me, the problems with interview code questions are the following:
1. It's a completely weird environment. No computer, no compiler, and extremely vague requirements. Few programmers do well in this environment.
2. Lots of room for silly "gotcha" pickiness that has little to do with actual programming skill.
3. The programming problem often involves too much code for a few minutes.
As an interviewee, my strategy for programming questions was the following:
0. Get the requirements, and state any assumptions. If you're wondering about a definition or something, go ahead and ask - it's better to do this than to get "gotcha'ed". Frankly, I also like to use the requirements discussion to "run out the clock" so that the coding lasts only a few minutes.
An aside: if the interviewer gets impatient at this point, they're probably not very good programmers themselves, or they're very junior.
1. Set up the data structures.
2. Discuss the main modules/classes/APIs you expect to use. Don't get hung up on the details of library calls or whatever; in real life, you'd look these up anyway, so go ahead and say so.
3. Only code the "top level" function that implements the main algorithm, using the data structures and APIs you outlined above. Bury stuff that's tedious and that takes a lot of code behind a module that you discuss but don't write, unless the interviewer insists.
Also, up front, state that you're explicitly skipping error conditions and error handling, but discuss how you'd code error handling if you were doing this "for real".
4. If you get gotcha'ed, go ahead and make the corrections. Don't get flustered.
If you expect to have this sort of "live programming" asked in an interview, it may be useful to have a practice session where you sit in front of a "friendly" and write some code on a piece of paper so you get used to the environment.
For me, the problems with interview code questions are the following:
1. It's a completely weird environment. No computer, no compiler, and extremely vague requirements. Few programmers do well in this environment.
2. Lots of room for silly "gotcha" pickiness that has little to do with actual programming skill.
3. The programming problem often involves too much code for a few minutes.
As an interviewee, my strategy for programming questions was the following:
0. Get the requirements, and state any assumptions. If you're wondering about a definition or something, go ahead and ask - it's better to do this than to get "gotcha'ed". Frankly, I also like to use the requirements discussion to "run out the clock" so that the coding lasts only a few minutes.
An aside: if the interviewer gets impatient at this point, they're probably not very good programmers themselves, or they're very junior.
1. Set up the data structures.
2. Discuss the main modules/classes/APIs you expect to use. Don't get hung up on the details of library calls or whatever; in real life, you'd look these up anyway, so go ahead and say so.
3. Only code the "top level" function that implements the main algorithm, using the data structures and APIs you outlined above. Bury stuff that's tedious and that takes a lot of code behind a module that you discuss but don't write, unless the interviewer insists.
Also, up front, state that you're explicitly skipping error conditions and error handling, but discuss how you'd code error handling if you were doing this "for real".
4. If you get gotcha'ed, go ahead and make the corrections. Don't get flustered.
If you expect to have this sort of "live programming" asked in an interview, it may be useful to have a practice session where you sit in front of a "friendly" and write some code on a piece of paper so you get used to the environment.
Comments:
<< Home
Good advice, foobarista. I'm of a similar opinion. I'd much rather discuss things at a higher level and see how someone goes about designing something rather than the minutia of the actual coding. I suspect that in 10-20 years even more of the coding will be automated anyway, so the real value a developer will bring is in how he or she designs for performance, future enhancement and flexibility.
Post a Comment
<< Home