3 ms·
My problem with the coding questions (other than the fact that everyone has seen them) is that they're too shallow. So the questions are binary. If you can't do
by msg 17y ago
My problem with the coding questions (other than the fact that everyone has seen them) is that they're too shallow. So the questions are binary. If you can't do them, interview over, sure. But if you can do them they don't say that much. They're almost short enough to count as trivia.
I prefer asking for a program that will take about an hour, but will also get a range of correct answers and mistakes. The ideal question has maximum dispersion, like a good hash function. You can observe a variety of strengths and weaknesses, and the horrible candidates will cry, the mediocre candidates will cringe, the good candidates will nod, and the strong candidates will laugh.
- ambition 17y agoCould you give some concrete examples of the sorts of programs you mean?
- msg 17y agoI give you a file of words, one per line, which may contain duplicates. Output the words in sorted order, removing duplicates, with a count of the number of times it appeared in the original file. Your program should be small and efficient. So there's file I/O, string matching, string storage, counting probably means a simple data structure, and there's formatted output to print the number of occurrences. You can also ask deeper questions, such as the big-O of the algorithm/data structure they come up with, and what happens if the file is too large to load in main memory. Perl programmers (for example) will laugh at this question, but in my experience that puts them ahead of the rest of the interviewing pack. I ask a similar question in my interviews that has some simple math instead of strings. I don't demand that my interviewees can remember the name of every library function, but if there's too much handwaving I get suspicious.