My friend and Web Dev colleague, James Socol, wrote a piece recently about some hiring things. I think it’s a good idea, and it would certainly make my job easier. It reminded me that I’m putting off a few posts about hiring.
I want to touch a bit on the “build/implement/write an X” style technical questions. For example:
- Implement a linked list
- Write a url parser
- Make an image resizer in Javascript
Often we get candidates who are exceptionally smart on paper, have great Github accounts, but fall flat on the in person implementation.
For some people this is hard. So let’s get over the nerves. I’m not going to tell you it’s silly to be nervous or that I’m as nervous as you (I’m not), or anything that you already know. I will tell you this. If you notice yourself not thinking as sharply as you normally do, count backwards from 10. Then carry on. Repeat if necessary. Usually our interviews are 45 minutes long. 10 seconds of you counting backwards isn’t going to kill us for time.
Hopefully this will calm you. If this doesn’t… well it was worth a shot.
So let’s get down to brass tacks. I want to know how you implement things. I want to know how you think. I don’t care as much about the answer, but the correct answer is comforting.
If I tell you “implement an image resizer in Javascript” and you start diving into JavaScript code and get flustered, I can’t really help you. If you can do that without getting flustered and produce something that works, I’ll be impressed, but somewhat alarmed.
What I really want is you to step back from the problem. I want you to show me what the resizer will look like and how it will behave. You don’t need to go into too many details, but enough details so I know you understand the problem.
If the problem is easily testable (like writing a url parser), it wouldn’t hurt to have some tests to start.
Then I want you to write the code backwards from high level to low level. Write the HTML, write the initialization code, and finally write the event handlers.
This is not only easier to follow in an interview, it’s basic problems solving, because you end up breaking the problem into smaller chunks.