Quote:
Originally Posted by Vampyr
Interpreted and dynamic languages like Python and Ruby require a lot more mental capacity on the part of the developer. You have to keep track of what types your variables are/could be, and since everything is interpreted and dynamic you can do crazy stuff like adding methods to classes at run time.
|
Sorry, but I have to disagree here. Keeping track of variable type is pretty trivial. If you were coding in C++ you're likely worried about performance, memory management, and thread safety which is considerably more complex (and that's excluding language issues). I've never heard of someone scripting in Python worried about cache coherency, or worried about casting a float to an int causing a CPU stall. Scripting languages have their place, but there's good reason why they're not used for high-performance code or large-scale distributed systems. Regardless, I would never expect to be interviewed on them, especially if they're using a language like C.
Anyways, on to the advice I typed up yesterday:
1) Read Programming Interviews Exposed, the book. It has a bunch of practice problems covering a variety of topics, and they tell you how you should approach many of the problems. If you happen to get a question from the book, just be honest and say you've seen it.
2) Talk through the whiteboard problems. If you sit there are stare at the board when you're thinking, the interviewer has no idea what's going on. Talk through what you're thinking. Also remember that most of these questions are chosen for a reason. For example, "Reverse all the words in a string in C" is really trying to find out if you understand null-terminated strings, how to walk an array with pointers, and see if you jump on the first algorithm that works or if you can find a more optimized one. So instead of just writing code on the board, saying extra stuff like "I'm using pointers to walk backwards through an array, which is tricky since I can point one past the end, but not one past the beginning, so my pointer will always be one element in front of what I'm referencing, like reverse iterators" not only tells me what you're trying to do (if you make a stupid mistake), but also tells me you understand some of the rules of pointers and arrays in C, and you know some implementation details of the STL.
3) Don't make assumptions. I've heard too many stories of interviewers asking a vague question just to see if you're going to rush into an implementation or find out all the details first (but keep in mind, I'm in Microsoft land). So if you get asked "Reverse a string", be sure to ask all the questions before you begin. What language? Null-terminated strings? Is this a reversal in place? If not, how are you handling the memory allocation? If you feel dumb asking the questions, then at least state your assumptions as you do (back to point 2), "So I'm assuming null-terminated strings in C here with an in-place reversal, right?".
4) Do the algorithm first. Make sure you have the algorithm down before you start coding. Not only does this look good, but whiteboard coding is top-to-bottom, which is not likely how you really code, so avoid the weird issue of forgetting a few steps and get it all down before trying to code it. There's been a few times where I've actually skipped the coding after getting the algorithm, since it was trivial at that point. Also, once you're done, go over the tests you were using before and make sure your code works. Always offer to do more tests (since sometimes that is the interview), but give them the opportunity to stop it and move on.
5) Pick 3 things you want them to know about you and make sure you tell them. Nothing is worse than leaving an interview for your dream job and realizing that you answered all the questions, but they never got a chance to learn what made you better than the next guy. Make sure you speak about your passions, your personal projects, etc. I generally think about it like this, all mathematicians should be able to add numbers together, you need to find out what makes one candidate better than the other. While some whiteboard questions are hard (some are designed to be impossible), assume everyone can solve them. Worry about standing out from the crowd.