Here is the dirty little secret about evaluating the code you write in the interview:
What is on the piece of paper (or editor) doesn’t make a whole lot of difference.
What happens when you and I talk about what you wrote tells me almost everything I need to know.
Less than one percent of interview code I’ve ever seen even compiled. What I was really looking for was:
- Did he understand the problem?
- How did he approach the problem?
- Does he appear as if he has any idea what he’s doing?
- Can he explain what he has done?
- Can he defend what he has done?
- Does he understand the concepts of order, cleanness, iteration, branching, recursion, etc., etc., etc…
- Based on this small sample, do I think he can do the work we need done?
- Do I like him? Will he fit in and be a good team member?
So assuming they interview like I did (a big assumption), here’s the good news…whether or not you’ll do well has already been determined. So don’t bother to “cram” between now and Tuesday. Relax. And have fun.
Be yourself and it will all work out OK (one way or the other).