Ask HN: How to improve a whiteboard interview performance?

Hey ZhL,

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.

Haha - whiteboard firing squad - I like that. Thank you for the offer to do a trial interview. I really appreciate that! Let me see how this week interviews go, and I may take you up on that.

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.

I interviewed at FB London about 6-7 years ago, and they also gave me whiteboard interviews. They're one of the stupidest things ever invented.

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.

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".

Yeah, that would require a whiteboard and a programmer friend who is kind of enough to endure the misery of watching me struggle with a marker, trying to remember how to write by hand again..

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.

> 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.

> They're one of the stupidest things ever invented

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.

It's been a long long time since I've interviewed for a developer job, and unless anything wildly radical happens, unlikely to happen ever again. BUT... At the time I recall that what worked very well was that I'd start with the knucklehead solution. I'd say, "Well, a naive way of doing this would be..." and what this does is buys a bit more time of thinking as you talk through the facile way of doing things. That alone is not going to be enough to pass this kind of interview, but I remember this as a useful trick.

Yes, starting with a brute force solution is a good advise. That paid off for me a couple of times. I need to keep reminding that myself - sometimes I get carried away trying to jump straight ahead to something more optimal.

I've only experienced one whiteboard interview in six onsites within the past three years, so their popularity may be waning.

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.

If I ever get into a position where I will be interviewing like that again, I will definitely buy a white board and solve coding problems on your white board, alone. This should get us a little more familiar with the actual interview situation. It's not 100%, but it's something you can easily start doing today.

Yes, I think that will help. For me personally it is also helpful to be able to analyze the problem by myself, without having to talk through it. Being able to write some code in an editor is also helpful as it springs my brain into action. Not sure how to adapt all of that for a whiteboard interview. Maybe a mental trick? Or an entirely different way to approach the problem?