How do you practice answering whiteboard questions?
Generally, you have a problem, you research, you experiment and then you wrap all that in a nice easy to use utility class or api and forget the details because there is something else you need to work on and that problem was just one piece of the puzzle anyway.
The worst hypocrisy in all that, is if you ask a specific question to a veteran developer on a average size codebase, he will very often need to look in the code and you will not think any less of him. But if it is an interview and he does not remember some trivia in a piece of code he didn't write - my god, he is a loser.
My team does whiteboard questions, but we try to keep them practical.
Typically they are the types of problems that we'd expect new engineers to have to look into on their first day. Oftentimes the questions are less "come up and an answer" and more "let's explore this problem domain and see what we can uncover."
As an example, the interviewer will write up on the board a data structure that is too big and has redundant fields in it, and start a discussion about how to optimize that structure. The optimizations go more and more in-depth as the candidate gains experience thinking within the problem space.
Another problem, the interviewer will give an example of a synchronous operation and work with the candidate to break it up into a set of asynchronous calls.
My team tries to avoid "puzzle questions with 1 correct answer".
I do ask simple data structure questions just to test basic programming skills. On occasion someone does make it through who cannot even write a FOR loop.
My standard go to question is "Please do an in order print of this already sorted binary tree."
It is 5 lines of code, and ~80% of candidates who haven't seen a tree in a decade can still figure it out.
IMH the goal isn't to try and trick people, it is to try and see if people can hold a conversation about a technical topic and make valuable contributions to a discussion.
It all depends on the team though, the interviewing process is completely non-regulated here. We get training telling us what to legally not say, but other than that is a free for all.
Teams ask white boarding questions because they heard other teams ask white boarding questions.
http://finance.yahoo.com/news/11-common-interview-questions-...
1) Actual programming and a technical interview are not and never will be the same thing. Assume you know nothing. And I do literally mean nothing. 2) Start with a basic intro to programming book in a language you aren't familiar with and try to do simple tasks in a language you already know. This simulates a bit how it feels to program under pressure. Things you know you know seem not to come out quite as quickly. This helps to emphasize point #3. 3) Practice. Practice. Practice. Practice. Practice. A decent chunk of your typical interview questions exist out there. I'm not saying to memorize them, but be familiar with their solutions. Eventually you'll get to the point that an approach for solving a new problem will come from pieces of old ones. 4) Since coding is done on whiteboards, do not use a compiler. Pencil and paper. 5) Find someone to give you an honest-to-goodness mock interview.
While this may be quite different from interviews for MS Redmond/etc full time jobs, this was my experience:
In my interviews, I mentioned off the bat that I wasn't great at algorithmic stuff. Now, don't get me wrong, I can do them, I'm just far, far behind the curve. (Students, esp. CS students, in India spend lots of time on sites like SPOJ and CodeChef solving algorithmic questions; I prefer to do stuff in open source). The interviewers were understanding. I got asked fun stuff like "what do you enjoy about [project I work on]". "Walk me through some large problems you grappled with on [project] and how you solved them". I got to have great back-and-forths on these things. It wasn't easy explaining nuanced and intricate problems, but I was able to give them a rough picture which I think is what they wanted. Shifting the focus from "can he solve this puzzle" to "what work has he done in the past" was great.
There were also algorithmic-y things, but not the usual kind. For example, one interview focused on designing and optimizing a build tool. The idea was that we had a bunch of components, with dependencies on other components, and I had to efficiently generate a viable order of building. There were some other constraints which I forgot. I realized that the problem was similar to a garbage collector (not that I knew how to model that either :P), and did some sort of mark-and-sweep thing. Then, after being asked by the interviewer, I optimized out some for loops and stuff.
I didn't need to know any algorithms beforehand. Sure, if I had known how `make` does dependency management, or had read up on garbage collectors, I would have done it faster. But I didn't need to know anything, and it worked out.
My fellow interns had really rigorous algorithmic interviews. They were okay with that because they were good at them. It's understandable that "solve this puzzle" is the default since not everyone has real world projects they've worked on (students). I don't like the status quo, but I don't think the interviewers will be intent on maintaining it either. If you have stuff you've worked on that you'd prefer to talk about, I think they'd like that.
If you think the interviewer will be open to it, I suggest mentioning it. They will know you're not from CS; you can mention that you don't have much practice with algorithmic stuff.
Major YMMV though. Also I've done very few programming interviews so the advice here could be totally misguided. :)
What I mean to say is, I have tended to use existing libraries that might make use of binary trees, but that I have never had to print or modify them. If modification is necessary, it's always through the library. So while I understand the basic concepts, I'm having trouble understanding why it would be a useful interview question.
Do developers at Google and Microsoft actually manipulate binary trees on a daily basis? Like, ALL of them? I can understand that they would be a common thing in the bowels of some code, but surely not all developers in either company would run into them on a regular basis?
No computers. Pen only.
For me, rehearsing an answer works out. Then, I try to see how to deconstruct it and apply it to a similar problem I don't know.
I can deliver an answer sounding confident and competent because I practiced an answer. It's a bit of a crap shoot.
What irks me the most is that people are doing the interviews. They can be fooled and persuaded with tones and intonations without them realizing it.
It's not. I hate whiteboarding as much as you but I try not to think of it that way. This method is just a way to increase your chances of succeeding. I've not succeeded in every interview, for sure.
I do what I must to press on. :(
The best thing to do is not to take the rejection personally. I always ask, as nicely as possible, what areas I should focus on to improve for the future.
Sometimes I get no response but I often get replies, good replies.
We do what we must.
That's true. I have other features that reduces my chances of getting hired, but doesn't eliminate them. Still, I wish I had someone else's mind.
Have a friend do a mock interview with you.
You spot patterns but there's so many different ways they can ask things and things that you just remember from studying it, that I imagine I'd do worse now unless it was close to what I've done since. On the spot I couldn't invert a BST right now.
I suspect you could probably pass a whiteboard interview a few weeks after taking a mooc on data structures/algorithms with enough depth for example.
That said, memorization, in my limited experience, won't be that helpful, because the questions will likely come with a twist that requires that you understand the algorithms and are good at adapting and applying them - and you need to be able to do it in 45 minutes on a whiteboard. It is very difficult.
I did find "cracking the coding interview" to be helpful prep, and really, the hard problems are fair game. Again, memorizing won't really help you, instead, view these as the kinds of problems you need to be able to solve in 45 min at the whiteboard.
I am kind of blown away that people can do this. I went home and did one of the questions I remembered from my interview with a compiler, and it took me several hours (though I didn't look up a solution, I did use the compiler constantly to check logic, and so forth, something that isn't available of course if you write on paper or a whiteboard). I suppose might be able to get this down to 45 min at a whiteboard, but it would take me a lot of time to get that sharp, months or more of study and practice.
None of this is mean to comment on whether this is or isn't a good interview process, it's just advice on how to prepare.
Yeah...that is memorization. I've had questions like that before and the problem isn't adapting. Its the fact I don't have everything memorized. I have no problems taking an algorithm off a book/Google and implementing it in 45 minutes, even with some kind of twist.
The problem is I can't remember things I haven't used in 10 years so expecting me to do anything with them in an interview is kinda pointless. Sure, I'll remember the purpose of the algorithm, but I'm not going to remember the algorithm implementation details.
I didn't get past the technical interview at google or amazon, so you might want to take advice from someone else, but here's what I think I'd need to pass the algorithm section of the technical entrance exam at google.
You must be able to do the following in about 5 minutes or less at a whiteboard with no errors:
1) print all permutations of a set 2) build and print a binary tree (preorder, postorder). 3) create a hashing function 4) quicksort and mergesort
(I'm leaving out linked lists, arrays, stacks and so forth because you won't be able to do 2 or 3 without them anyway).
The reason you need to memorize these (yes, I'll go ahead and use your word now, I agree with you that this is memorization) is that you can't be dealing with how to implement these if you're going to do enough in 45 minutes to pass the exam. I think that these three things form the foundation for most variants on recursion, sorting, traversal, combinatorics, and so forth.
Next, you need to be able to identify when something is a variant of these algorithms and solve it very quickly at the whiteboard. "Cracking the coding interview" is good practice for this, but in this case, I don't think "memorizing" these questions and answers would be especially helpful, because you're unlikely to get that exact question.
Here are a few of questions I've invented on the spot (not from my interview, not from cracking the coding interview) that you'd probably want to get close to solving in 45 minutes or so. In other words, if a buddy wanted to apply to a top tech company and asked me to give him some practice, I'd give him 45 minutes at a whiteboard for each of the following questions.
"In a binary tree with positive and negative integers, find and print all paths with a positive sum. Now assume the tree is ordered, and make your code more efficient."
"In an nxm matrix, find all sub square matrices with a positive determinant."
This might just be me, but I was kind of struck with just how much progress and accuracy you are expected to achieve at the whiteboard. And like I said, I am kind of blown away that people are able to do this. While I can pose those questions and develop a mental model for how to approach it, I just couldn't solve them at a whiteboard in 45 minutes to anything approaching what I believe is the standard.
Again, whether this is a good way to filter people out isn't something I'm discussing here, this is just my advice if you are planning to apply and want to be prepped. Also, there will be more than just data structures and algorithms on the exam.
That is why I stress its memorization because without memorizing things you've long since abstracted to libraries, you really can't perform in the stressful interview situation to the level the interviewer expects.
If, however, you take something the interviewee implemented in the past 6 months as the "standard problem" they could probably do it without much trouble.