(I'm at Microsoft, FWIW, every engineering team here does hiring their own way)
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.
I hate to show my ignorance, but why the focus on binary trees? I've been programming for decades, but there are plenty of things I've never touched because I just didn't have a need in the particular job. Binary trees are one of those things.
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?
Even if you have used them like a few months ago. Very few people work on variation of the same problem over and over again, except in research.
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.
> How is it the best way if you are not going to be writing code on a whiteboard on a daily basis on the job you are going to be interviewing for?
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.
It's about gaming the system to get a job. When you are in a position to hire other people, you can worry about a less awful method to select candidates.
They all just seem to be varying levels of fanciness over relatively common data structures and algorithms. I was only applying for internships but the whiteboard stuff wasn't too bad when I did (and other questions I practiced online), I imagine almost completely because we'd done 2 related modules at university.
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.
I interviewed (unsuccessfully) at google. If you want to be prepped, yes, I would recommend going over the algorithm books, and make sure that you can do all the basics in your sleep.
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.
> 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
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.
By re-learning computer science concepts you haven't had to use in real life without Googling in a decade.
(I'm at Microsoft, FWIW, every engineering team here does hiring their own way)
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.
I hate to show my ignorance, but why the focus on binary trees? I've been programming for decades, but there are plenty of things I've never touched because I just didn't have a need in the particular job. Binary trees are one of those things.
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?
I'd like to interview at MS next year, I have no formal CS training. Can you give me any hints?
5 replies →
Even if you have used them like a few months ago. Very few people work on variation of the same problem over and over again, except in research.
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.
I found actually using a whiteboard, or pen & paper, is the best.
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.
How is it the best way if you are not going to be writing code on a whiteboard on a daily basis on the job you are going to be interviewing for?
> How is it the best way if you are not going to be writing code on a whiteboard on a daily basis on the job you are going to be interviewing for?
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.
It's about gaming the system to get a job. When you are in a position to hire other people, you can worry about a less awful method to select candidates.
1 reply →
Look at glassdoor.com or careercup.com for questions from a certain company. Practice using paper and pencil.
Have a friend do a mock interview with you.
They all just seem to be varying levels of fanciness over relatively common data structures and algorithms. I was only applying for internships but the whiteboard stuff wasn't too bad when I did (and other questions I practiced online), I imagine almost completely because we'd done 2 related modules at university.
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.
You might want to check the latest post on this topic on Eric Lippert's blog: http://ericlippert.com/2015/06/01/writing-code-on-whiteboard...
Get a couple books on algorithms, memorize like its CS 101 basically.
I interviewed (unsuccessfully) at google. If you want to be prepped, yes, I would recommend going over the algorithm books, and make sure that you can do all the basics in your sleep.
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.
> 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
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.
2 replies →