Huh? You're worrying about whether or not what you write on a white board will compile? How do you know? Press a magic button to OCR what you've written, download it into some computer somewhere, and compile it? Sounds like you're interviewing at firms with technology I didn't know existed.
Your interviewers have you code on a white board so that they can evaluate you, not your code. They want to see how you handle a problem, how you approach your work, how you think on your feet, how you deal with interaction, and how your intelligence and experience applies to their business. Anyone who worries about whether white board code actually compiles is missing the point. If they're more interested in perfect syntax than embracing you and your potential contribution, then you don't want to work for them anyway.
I think you're making this too hard on yourself. Memorize nothing. Just be yourself. Programming is like riding a bike; once it's part of your DNA, you don't have to worry about it. Just relax, trust your inner programmer, and let this become a self-solving problem; some jerks may reject you, but the right fit will come when someone sees who you really are.
I agree, though I think, perhaps, the author has a point about something. It's one thing to be asked to write code on the whiteboard for a practical problem. During the interview process for my current employer, I was asked to sketch out a database design for a given application, including actually writing out some of the SQL to generate the tables, constraints, etc. I was then asked to write queries to pull reports against my schema. I was also asked to show some code to pull said queries from the database, in the language of my choice.
Those sorts of questions seems appropriate for the position in question. Asking me to implement a linked list or binary tree? Not so applicable. Might I use these sorts of things? Yeah, but the senior engineers assume I know how to use Google.
It's often hard to ask relevant questions that will fit into the time allotted for an interview. Your DB schema example is a good one - it shows that the candidate can design (and to a lesser extent, implement) an application. Your example (I'm assuming) is missing strong algorithmic problem solving however. It would be good to have an additional question to test this kind of knowledge.
It's also important to realize that most technical interviews are really about weeding out bad candidates than finding good ones.
It may also be necessary to have questions general enough that any given candidate stands a chance at solving it. If a candidate doesn't have SQL experience your example would be bad (assuming the company didn't require SQL experience).
This is why you see questions like "implement a binary tree." Any competent programmer should be able to implement a binary tree. If they have never seen a binary tree before, they are simple enough to describe in 5 minutes.
I once asked a candidate to implement a trie. He had never heard of a trie before so I drew one on the whiteboard and briefly explained it. He asked me a few questions and then proceeded to implement one. We then discussed the pros and cons of different methods to store the nodes (vector, list, map). It showed me that, given a spec, he could code a data structure and the following discussion showed me he understood memory and time constraints.
Good points, but, how many interviewers would severely penalize someone for not even knowing what a binary tree was? I think explaining the tree and asking for an implementation could be a fair question, but only if the question assumes that the implementation is the important bit.
Also a good point. I'd be surprised if a programmer didn't know what a binary tree was and would certainly consider it a warning sign. I would assume that, given a description, they probably wouldn't be able to code one (or code much of anything). However I'm willing to be proven wrong and if they were able to implement one I would be pleasantly surprised.
Of course, I can only speak for myself. I'm sure many programmers would immediately write them off.
I would assume that, given a description, they probably wouldn't be able to code one (or code much of anything).
That's a pretty glaring assumption, especially since it's subject to empirical verification. It also contains an assumption of its own -- that all programming needs a heavyweight familiarity with algorithms. There's a lot of programming contexts where the productive programmer just uses a hash so the mental bandwidth can be devoted to something else.
(FWIW, I do sometimes wish those programmers knew a little more about algorithms.)
I agree that it is a glaring assumption, and perhaps is "culturally" biased. Someone programming in Perl or Python, would probably be very familiar with the built in data structures (hashmaps, dictionaries) but may not be familiar with others.
And this is exactly why I would give the programmer the benefit of the doubt. If they are able to implement a binary tree then I wouldn't hold it against them (and I hope most other programmers would extend the same courtesy).
However I have never met a programmer who did not know what a binary tree was.
Thanks for your support. The reason I mention "on a white board, no syntax errors, compilable" is because I've been dinged at the whiteboard for these silly reasons. No shit ! And Gayle Laakmann, author of "Cracking the Coding Interview" actually says it's important to write nearly perfect code at the whiteboard.
How do you know you were dinged for these silly reasons? Did they actually tell you that?
I wouldn't be surprised if there are programmers out there who ding candidates for silly reasons like that, but in my experience they are the minority.
Huh? You're worrying about whether or not what you write on a white board will compile? How do you know? Press a magic button to OCR what you've written, download it into some computer somewhere, and compile it? Sounds like you're interviewing at firms with technology I didn't know existed.
Your interviewers have you code on a white board so that they can evaluate you, not your code. They want to see how you handle a problem, how you approach your work, how you think on your feet, how you deal with interaction, and how your intelligence and experience applies to their business. Anyone who worries about whether white board code actually compiles is missing the point. If they're more interested in perfect syntax than embracing you and your potential contribution, then you don't want to work for them anyway.
I think you're making this too hard on yourself. Memorize nothing. Just be yourself. Programming is like riding a bike; once it's part of your DNA, you don't have to worry about it. Just relax, trust your inner programmer, and let this become a self-solving problem; some jerks may reject you, but the right fit will come when someone sees who you really are.