
Ask HN: How to improve a whiteboard interview performance? - ZhL
I have recently started looking for a new job. And I think I have a performance problem when it comes to a whiteboard interview.<p>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&#x27;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.<p>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.<p>The observations above make me think that maybe I&#x27;m slow and&#x2F;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.<p>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.
======
subhobroto
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.

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

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

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

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

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

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

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

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

~~~
ZhL
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?

