Every once in a while I read about a job interview for programmers and I find myself wondering if I would have been able to answer some of these questions, because although I learnt programming at school, I find myself incapable of answering some of them. Is it because I have read the wrong books or messed with the wrong language (C++)? Does it make me a bad programmer?
Are there some programming questions considered to be an absolute must-know-the-answer for someone to be a good programmer?
When I interview candidates, the important thing is not whether they can answer one or two specific questions. It is far more important that a potential employee can answer questions about past work experiences / projects in a way that will let me assert their skills, experience and attitude.
Are there some programming questions considered to be an absolute must-know-the-answer for someone to be a good programmer?
I think yes. Possibly the more relevant question is like
Are there some programming questions considered to be an absolute must-know-the-answer for someone to get hired in an interview?
which is I think a stronger yes. If you're interviewing in my office, and I ask you to write code on the whiteboard to sort an array or a list, and you can't do it, then my hunch is you are not a good programmer, but more importantly, there's no way I'm going to hire you.
The implicit followup question: ok, if such questions exist, which questions are they? They are the popular ones about lists and arrays and trees and parsing and calculators and all those little problems you find on the web that have code answers of 25 lines of code or less and are relatively language-agnostic. (They are not the boring specific minutae like 'what happens in C++ when you delete null?')
If you find yourself having trouble with some of these 'popular' questions, then go spend some time on a Saturday and solve them! You might learn something. And even more likely, you might be better prepared for your next interview, whenever that may be.
(my rambling opinion)
My favorite is "What are typical questions good programmers should be able to answer?".
If your question is: are there problems which you couldn't solve, say a couple of years into your career, that 10 years down the road you can, then yes that does happen.
IMHO solving logical puzzles is very much something that improves over time the more you do it.
Q: Write a program that reads a line of input from standard input and writes that to standard output and to a file.
I know someone with a job as a "computer guy" and who "knows" C++ and cannot do this. Simple file I/O, and some people don't know it.
It may be prudent to up the complexity of this question, but not by too much. If they know something basic like this, they can learn to use your latest new toy. The idea is to establish a minimum benchmark of "if you can do this, then you really do know language X" as opposed to "you know some parts of language X but would drag a development team down with your lack of basic knowledge."
This is so domain specific that I would think some questions for the specific domain and use that to judge if the interviewee has a clue about it.
For instance I interviewed a few guys for some DSP coding jobs and one of my questions was "What is a re-entrant function?". If you don't know what that is I would worry whether you fit to code real-time SW. The follow-up question would be "what do you check to see if a function is re-entrant?", but it would be the way the question is answered that is important rather than if you can come up with a definite list. If I interviewed someone for database programming I would choose different questions. Sorting an array or something like that - there's plenty of programming tasks where you don't need that or have tools that include functions for that, so not knowing how quicksort works doesn't necessarily mean you are not qualified for the job. So ask questions that are relevant for the job you are hiring for.
The problem with asking lots of very detailed questions is that people are usually quite nervous in situations like that. I remember one interview I was in where my brain basically shut down and I struggled with even the simple technical questions. Part of being a good interviewer should be the ability to spot things like this, you are not hiring a PR guy.
When I interview candidates I'm much more concerned about basic thinking than language knowledge.
My favorite interview was for QA when I asked her about a time in previous jobs she needed to think about the problem. She answered that when working on an RMA system she realized that the items were segregated by issue(I don't want it vs It doesn't work), but that the system assigned identical time frames for reshipment. It was working as specced, but made no sense. If someone returns a router because they don't need it, it needs to be inspected, tested and then reboxed. If they return if because it failed, that's entirely different. Yet every return was allocated 7 days.
To this day she is spectacular in QA, not only for braindead conclusions like that, but for paying more attention, and really analyzing the problem. Not to mention that she doesn't blink twice about needing a screwdriver to do her job or using a stun gun to repro hardware defects.
I give the "candidate" a small project or code snippet in the language of choice and ask him what he finds good and bad about the code.
The code itself has:
If the candidade can see (and he should) what could be improved and can explain how he would do it (like unit tests before refactoring), then he probably knows his stuff.
The art of programming is about being able to solve problems, not knowing the solution to problems* - though in a very general sense recognising and understanding common patterns and algorithms does make you more valuable as an experienced programmer.
FWIW, the few times I've interviewed anyone what I've always been interested in is their potential ability to work through a problem. Someone who's seen the problem before doesn't help me much because I'm explicitly interested in their process when confronted by the new. I don't even mind if the candidate does something wrong so long as it makes sense and they can correct it when pointed out. I guess this is just the way I'd like to be interviewed myself.
Write a program (preferably on the whiteboard) which takes as an input another program and outputs whether or not it would terminate.
all good programmers should know how to do this :-D
write a function to count the number of nodes in a tree. the tree is represented like so:
class node{
node left;
node right;
}
the answer should be
int count(node a){
if (a==null)
return 0;
return 1+count(a->left)+count(a->right);
}