Ask HN: How to improve a whiteboard interview performance?
I often struggle to come up with any kind of specific solution on the spot even if I can outline the general idea. I don't usually feel particularly nervous, so it is not that. Shortly after an interview ends, on my walk outside, I often have a breakthrough when the solution comes to me in a much greater detail, so that I can articulate it much better at least to myself.
I have also noticed that I can typically only solve Medium problems on LeetCode within an hour when left alone. Hard problems often take me a couple of hours at least.
The observations above make me think that maybe I'm slow and/or ill equipped when it comes to solving problems on the go. And certain types of problems are easier for me to solve in solitude.
Does anyone have any suggestions what I can do improve my onsite performance? I will of course keep on practicing, but certain opportunities are getting away from me.
12 comments
[ 383 ms ] story [ 2365 ms ] threadIf you want to master it, I guess you need to buy a whiteboard, and have a programmer friend give you random problems on a timer.
Having said that, do you really wanna work at a company that does this? I would never ever go to FB again, and not just for the pathetic and horrendous things it does, but the interview process just feels like "ooh, i know this crappy thing that was taught in high school, which nobody actually uses/needs, and you don't".
I have very little experience interviewing (my previous job lasted 10+ years, my current one - almost 6). But I thought that solving problems on a whiteboard is fairly common, if not a golden standard for an on-site. At least both of the on-sites I had recently had a whiteboard component.
I think certain problems are a good _partial_ fit for a whiteboard interview: math/geometry, graphs and trees, combinatorics, system design. However, it does not feel natural to solve the _entire_ problem on a whiteboard. Additionally, I was also expecting whiteboard sessions to be a collaboration and a discussion. That hasn't been my experience so far.. I had either very little feedback, or a feedback that was more confusing than helpful (to me at least). Hence the question if I can do anything at an interview to increase the chances of a positive outcome. Or if there is a systematic approach to this problem.
There is.
The whiteboard firing squad questions are pretty predictable once you do enough of them.
The very bad ones will ask directly from one of the popular sites. DFS/BFS/Invert Binary Tree/Coin Change/Hop Jump Skip/you know.
You have to learn it once and can regurgitate until you forget them again.
I am happy to help a fellow HN'er and work out some trial whiteboard interviews with you if you feel that would help.
Sure.
What do you have in mind that takes less, not more commitment in time from the candidate however?
> If you want to master it, I guess you need to buy a whiteboard, and have a programmer friend give you random problems on a timer.
Yup!
> Having said that, do you really wanna work at a company that does this?
I would take a whiteboard firing squad any day over the takehome test firing squad where they ask me to implement Todoist from scratch - backend and frontend, refuse to provide me any feedback/insight, tell me "do your best, follow your best judgement, treat this like production code" and then after hours of me writing tests and code, come back to me and say I spent too much time developing the backend and the frontend was not progressive enough.
The whiteboard firing squad questions are pretty predictable.
The very bad ones will ask directly from one of the popular sites. DFS/BFS/Invert Binary Tree/Coin Change/Hop Jump Skip/you know.
I have to learn it once and can regurgitate until I forget them again.
I pay the heavy cost once upfront and amortize it over all the interviews.
No such thing for a take home coding test!
Take Home coding tests are great at gauging real life performance of a candidate, if done right, but in my limited exposure (I don't have a lot of time to work on coding tests just so I can collect data samples to back my opinion), coding tests are handled extremely poorly, with expectations being set extremely vaguely.
Any realistic assignment requires a dialogue between the consumer and producer.
Companies are trying to minimize the time/money they spend on each interview.
Clarifications cost money.
Hoping a company will engage in a "what really are your requirements? are you trying to test my basic coding competency or do you want to see the best I have got?" will elicit a very vague response, if any.
If a company treats a home coding test as a real assignment and provides the candidate with the resources they need, I see no problem.
Unfortunately from my personal experience and anecdotes from others, it's just not the case.
that's not just you.
It's me and everyone else I know.
That's why these are called whiteboard firing squads.
The only way I know to improve on whiteboard interview performance is to do more whiteboard interviews unfortunately.
I know it does not make sense. I know it does not teach your or help you further any actual skill you will actually use day to day, but that's the problem we programmers have painted ourselves into.
The "remote" equivalent to whiteboard interviews are "live coding" sessions where you type code into a site like codebunk.io
Some random person who works at your potential employer will send you a link to a site you can type code into and ask you to solve a "5 minute problem". It's not fizzbuzz, it's not a for loop - it's going to be something slightly tricky like finding the sum of 3 numbers that add up to a specific number.
One thing I can recommend at a whiteboard firing squad is to see whether the firing squad has people in it that want you to win.
If you think out loud, show them you know what you're talking about, they might come out, feel your issue and work with you.
Isn't that the kind of people you want to work with regularly anyways?
I am happy to work out some trial whiteboard interviews with you if you feel that would help.
As opposed to failing 2 out of 2 whiteboard interviews, the "live coding" sessions have been a mixed experience for me. It often works just fine if I'm given a clearly defined problem at the beginning of the interview and enough time to quietly think about it. It does not work very well when I'm asked behavioral questions first, coding session is limited to 20 minutes, problem keeps evolving and interviewer comes across impatient or in a rush. Solving a LeetCode/HackerRank hard problem within an hour also does not work for me. But most companies in my experience have been more reasonable than that so far.
Btw, TripleByte (no affiliation) does a much better job at technical screens in my opinion than the rest of the companies I tried so far. I wish more companies would use them.
Also, there seem to be several different types of whiteboard interview, a) the algorithmic solution, b) the conversation starter, and c) the problem analysis. I mention this so that you don't focus solely on the algorithmic type, the other two really are there to help interviewers know how you approach problems.
In this case there were 3 code scenarios written to the whiteboard. The interviewer asked questions expecting a definite specific answer based upon the provided code samples. This did only a few things: forced me to read the code, forced me to carefully consider the question, and finally answer the question. They went through about 30 questions like this and treated like a casual conversation. Things were not rushed.
What this did not do:
* They did not ask me to brainstorm anything until the end as a bonus round once my nerves were down and my confidence was high. Normally, as in normal development where there isn't performance pressure, it takes a few minutes to think through an ideal solution to a given problem and then execute on it. If an interviewer expects equivalent performance with a gun to somebody's head be prepared for disappointment from multiple perspectives. I say this even though I am one of those few people who perform better under pressure.
* They did not ask me to write a bunch of code on the whiteboard before. I have been through this before and the results are mixed. On one hand the interview is pleased that I can answer a given question immediately and under pressure without delay and that the answer appears correct. On the other hand they are sorely disappointed in that my answer does not reflect their favorite code style or require use of their favorite tools. This is stupid nonsense. If that pettiness really is that important for the interviewer then address it after candidate selection. Otherwise the interview is simply wasting everybody's time including their own. Simply: If they didn't want the answer then why did they bother asking the question in the first place?
* They didn't ask me random code trivia. I have seen some code interviewers go off on tangents about irrelevant factoids and edge cases that don't matter to the performance of anybody. Instead this employer focused their attention on whether I understood how the code in question works and things like scope, order of precedence, and common code behaviors. Clearly the goal was to separate those who could code from those who could not. If additional filtering is required then they could solve for it with an additional interview.
--
As far as being the candidate and participating in whiteboard interviews my only advice is this: Answer the question as directly as possible and be done. Do not be fancy or clever. If they want to circle-jerk you with nonsense and continuous edge cases to see how you perform under pressure just repeat the advice. Answer each question as directly as possible with the least effort possible and be done.
The goal here is to use this as an opportunity to evaluate the interviewer. This is primarily why you want to spend as little time and effort on the whiteboard as possible. Instead read the interviewer. Determine if they are randomly all over the place. Are their evaluations of you simply pass/fail or are they full of subjective stupidity. When they do come back with subjective stupidity ask them very pointed questions about their decision making. An interview can go both ways and if they don't have their stuff together you may not want to work there.