I missed a few things recently in a technical interview that I damn well know. I hate dislike some styles of technical interviews and I’m not alone. I just don’t always shine in the ones that require a raft of instant answers to problems.
Some biased quotes on the subject I agree with:
Scott Meyers: I hate anything that asks me to design on the spot. That’s asking to demonstrate a skill rarely required on the job in a high-stress environment, where it is difficult for a candidate to accurately prove their abilities. I think it’s fundamentally an unfair thing to request of a candidate.
Matt Gerrans: I don’t like when I’m asked to write a program that does X on a piece of paper. Don’t ask the candidate to write a program on paper. That is a waste of time and sweat. People don’t write software on paper, they do it with computers using auto-completion, macros, indexed API documentation, and context-sensitive help. They think about it, refactor it, and even rewrite it. If you want to see a person’s work, ask them to write some small module or implement some interface before the interview and bring the code on a notebook PC or on hard copy. Then you can review it and discuss the design, coding style, and decisions that went into it. This will give you a much more realistic and useful assessment of a person’s work and style.
When I have interviewed people for jobs I have always asked them to do a simple project before coming in. Usually just a simple gui and database application (of about the scope one would expect in a 3rd year unit assignment - half a days work maybe for the average person). This instantly weeds out 99% of those who couldn’t be arsed and shows that a candidate can do something useful from the get go. Some quick discussion about the code can verify that the code’s author and the applicant are the same person. Asking them to make a change or addition to their code also helps illustrate their abilities whilst keeping nerves down as its their own code that they are familiar with.
In response to my mild embarrassment over stuffing up some tech questions, I am going to spend a few days or week, as they are available, over the near future backtracking over some c and c++ to reinvigorate that part of my brain that appears to atrophy as soon as someone whispers the words interview and technical in the same sentence.
In any case, I am thinking of picking up a new language soon (Python seems to be the front runner at present), so reimplementing half of Sedgewick for kicks first might get me started before I embark on doing the same thing in the new language as one should. So this could become a “what you should know in a language” sort of series. We’ll see.
In any case, the following is a minimal tree and queue implementation in c to warm up. For whatever reason, I totally forgot how to do a breadth first traversal in an interview last week. Brain totally froze. How dreadfully embarrassing! Granted, it was the second interview of the day which might have had something to do with it.
Don’t use this for assignment study or for controlling a nuclear reactor as I’ve quickly hacked it out on the evening of a public holiday after a few glasses of wine. Comments are welcome - but remember this is a quick first version - obviously some of that ugly looking double pointer stuff could be typedef-ed away as well as well as a more decent set of tests. I think its right 
Let me know if I’ve cocked some of it up as its been a good while since I’ve done straight c.
This is only bare bones enough to implement a BFT - so I know full well that there are some fairly obvious functions missing - deleting the tree would be an obvious omission should this be a serious attempt at a library.
I’ll do a c++ version as soon as the next bottle is opened. Tomorrow.
tree.h tree.c queue.h queue.c main.c
Here is some sample output:
bcg@bcg-laptop:$ ./tree_test
test_tree_created passed
test_tree_empty passed
test_node_data passed
test_node_linked left passed
test_node_linked right passed
Depth first:
1 2 4 5 8 3 6 9 7
Breadth first:
1 2 3 4 5 6 7 8 9
