
Show HN: Whiteboardfree – Developer Jobs at Companies That Don't Whiteboard - vbordo
https://whiteboardfree.com/
======
brokenwren
I've been using whiteboards for 2 decades during the interview process and
they work great, if you ask the right questions. I've built great engineering
teams at companies like Orbtiz and whiteboards were one of our best tools.

The reason they are important is that they are part of every engineers day-to-
day work. We use them to collaborate and design and understand.

Therefore, if a candidate can't whiteboard a design, solution, architecture,
etc. in a manner that other engineers can understand it, they are going to
struggle.

That being said, the way Google and other companies use whiteboards is an epic
fail. Asking someone to code on a whiteboard is stupid. Asking them to solve
algorithm puzzlers on a whiteboard is lame. This isn't how we use whiteboards
every day so why should a candidate be expected to use them this way during an
interview.

~~~
dalbasal
An important thing to remember is that broken/not-broken is completely
different for each side of that desk: candidate person & hiring person. This
is always the case for selection steps.

The employer (or school, etc) wants to make successful hires and to avoid bad
ones. False positives are always a big problem. False negatives are usually
much smaller one. A process is good if it produces good hires, and no bad
ones.

In principle, a process that hires 3 good candidates from a pool containing 5
good candidates and lots of bad ones is good. Avoiding bad hires is paramount.
Missing 2 good hires is not as bad as making one bad hire, not near as bad
usually.

Most employers don't care about false negatives at all. If they do, they
probably care most about missing _really_ good outlier hires, not mistakenly
selecting the 5th best candidate instead of the 4th. The only reason to care
is fairness. People instintively care about fairness so this affects practices
but it's not nearly like false positives.

Employers that need huge volume (eg, the army) are the only ones that care
about false positives as much as candidates do.

The candidate (student etc.) generally feels the process is "broken" when it
is _unfair_ to them. Unfair means that a person could have done the job well,
but cannot get hired. Ie, if the candidate is a "false negative" then the
process is broken.

Anyway... When things become systemic, the "brokenness" becomes acute to a
candidate. If whiteboards (your architecture version, Google's CS version or
any other version) are prevelant and you suck at them... you can't get hired.
There _are_ people who suck at your test (whatever it is) but would be good at
the job. Your proxy _is_ a biased against some people, every proxy is.

Like I said, a lot of things are like this. One side is working the numbers
game, the other side isn't. Insurance markets, college entrance, executive
appointments, PayPal's fraudster detection (bastards!), credit scores,
investment (even startup investment)...

~~~
braythwayt
I agree that most companies don't care about false negatives.

The problem is that very few companies know how much false negatives are
costing them, so it is very difficult to evaluate whether the false negatives
are—cough—a negligible tradeoff against weeding out the false positives.

False positives are right in your face. But it is nearly impossible to
systematically keep track of the candidates that aren't hired to see if they
are successful elsewhere.

So people lean towards eliminating false positives at all costs. It's another
variation on "Looking for the watch where the light is better."

~~~
ska

       It's another variation on "Looking for the watch where the light is better."
    

This really doesn't fit. If there are dozens of watches scattered around, of
course you first look where the light is good.

These situations aren't at all symmetric. A false positive always costs you
(the company). A false negative is only a cost to you if you fail to hire well
for that position.

Also the fact that a candidate you passed on does well elsewhere doesn't mean
you were wrong to pass on them (it could, but it's not clear).

~~~
braythwayt
I was not equating this to a scenario where you are only looking for one
watch. The expression (and anecdote behind it) is also used to describe
managing according to metrics that are easy to collect, often at the expense
of outcomes.

That applies in the case of caring more about false positives than false
negatives, since nobody (or close enough) even knows how many false negatives
they have.

Your statement that someone being successful elsewhere doesn't prove we have a
false negative underscores the uncertainty involved. It doesn't invalidate
what I'm saying in the least.

But if we want to be rigorous, we could do some direct testing. Let's say we
give a telephone screening and four interviews to each candidate. Simpkifying
somewhat, let's say that our policy is that a fail on any one eliminates the
candidate.

If we hire lots of people, we can collect false positive and false negative
stats by randomly passing someone who fails exactly one test.

If a lot of people who fail a particular test end up succeeding, we can infer
that the test provides false negatives.

On the other hand, if everyone who gets the random "free pass" on one
particular test ends up failing, we can presume it has low false negatives,
and maybe abandon the random passes for that test.

~~~
ska
I understood the analogy you were trying to draw, I just disagree with it.

The original joke/anectdote works because it leads to clearly suboptimal
search - the guy knows his watch isn't near the streetlight, but he's looking
there because he can see.

This is a very different situation. To abuse the analogy further, the guys
best bet to find a watch seems to be just looking near the streetlight. After
all, not only can you see better there, but most of the watches are near there
too.

~~~
pandaman
What your opponent is saying is that the cost of false negatives is unknown
because it's hard to calculate. So people only calculate the cost of of false
positive because it's easy to calculate then compare it to the unknown value
and conclude that it's greater, not dissimilar to the gentleman who had been
looking for the watch under a streetlight.

Your saying "false negative is only a cost to you if you fail to hire well for
that position" could be easily disproved with examples of people, who were
rejected and started their own competitive business (e.g. [1]). IMHO, one of
the goals of having 10Ks of engineers on staff is to keep them from the
competition. But since nobody is tracking this and the extreme cases like
WhatsApp can be hand-waved away it's easy to pretend that the false negative's
cost is miniscule.

1\.
[https://en.wikipedia.org/wiki/WhatsApp#History](https://en.wikipedia.org/wiki/WhatsApp#History)

~~~
ska
If I’d seen any evidence that this cost wasn’t minuscule int the typical case,
I’d be much more interested in expending the effort to try and measure it
better and act on that - but that has an opportunity cost also. So you are
suggesting incur a real cost just in case? I don’t buy it.

The guy with the watch analogy only works if there is good reason to believe
he’d be better off searching elsewhere. But we don’t appear to have that
here....

~~~
pandaman
I am not sure you checked out the link I've given. It's quite a substantial
evidence that not hiring Koum and Acton might have costed FB somewhere around
$19B if one were to believe WhatsApp was acquired to neutralize competition
and not for its amazing revenue.

Let's be generous and say the WhatsApp was a 10x unicorn so FB overpayed only
9B for it. Which makes 4.5B loss per false negative on each founder. If a
false positive was, on average, 1M loss (which is an extremely generous in an
organization such as FB in my recollection), it means you could have had 4000
false positives for each of these negatives and still come ahead.

And, it brings us back to the Type I and II errors - it's always cheaper to
make one, which has a limited downside than the unknown (potentially very high
one). Typical example given is that while you are on the way to an expensive
cruise you realize that you might have forgotten to turn off the stove. If you
go back you might miss your 10K cruise. If you cary on, you might lose you 1M
house. On average, people who miss cruise in such circumstances fare much
better than ones, who risk their houses.

~~~
ska
I know that story - but think it is enough of an outlier (regardless of how it
went down) to basically be irrelevant to almost all hires. The idea that
people are routinely filtering out great hires in their thousands in ways that
come back to haunt them ... doesn’t seem plausible.

I get what you guys are saying, there just doesn’t seem to be real evidence
that is an issue nearly all cases. Whatsapp notwithstanding

~~~
pandaman
No, the idea is that you don't know what you are filtering out. As I said -
it's extremely easy to just hand-wave. And if you want to believe that you
know the unknown downside I am not the one to persuade you otherwise. But
acknowledging that it's just a personal belief not only unsubstantiated but
contradicted by data could be a good first step :)

~~~
ska
I think we are talking past each other. I have never said I know the unknown,
that would be silly. But funds,entsllu can’t avoid false negatives without
degrading other performance , assuming some reasonable things. Even without
those assumption, there is a very real cost to what you are suggesting. You
seem to be waving off this cost.

So in order for it to make sense to spend that money, you want some evidence
there will be a positive return. Far from contradicting my position, what
limited data I have seen does not support that effort, at least in the general
case. Certainly whatsapp and the like don’t speak to it - they are very much
outliers.

By all means try it. If your false positive rate explodes it will be an
expensive lesson, but that’s always a risk.

One last point, the idea that nobody thinks about this and try’s thinks is
laughable , which is worth noting because some comments in this thread almost
suggest that it’s true,.

~~~
pandaman
> You seem to be waving off this cost.

With my example of sacrificing a 10K cruise for a chance to not lose a 1M
home, I figure?

> Far from contradicting my position, what limited data I have seen does not
> support that effort, at least in the general case.

Indeed, the data does not contradict a statement "on average, false positives
are 4.5B each", which nobody has argued. However, it does contradict the
statement "false negatives have any cost only when you are unable to fill the
position as the result", which you have made in this thread.

>One last point, the idea that nobody thinks about this and try’s thinks is
laughable , which is worth noting because some comments in this thread almost
suggest that it’s true,.

Again, it would be silly to say that nobody thinks about it. Evidently, a
number of people think the same way you do.

~~~
ska
Perhaps they do that because it has proven out over time. At any rate, we’re
well past diminishing returns here, so I’m out.

------
crsv
We don't whiteboard at my company, as we favor a take home technical exercise
and debrief/walkthrough format for interviewing our engineers. That being
said, I'm super turned off by the incessant whining from the community about
various interviewing practices. Here's the tough truth I think: Some companies
simply do not understand how to properly engage in employee selection. They
get some quick guidance from a google search and have too much autonomy in the
process to make their own decisions because the company hasn't really
empowered their talent processes to be well thought out and planned. This
happens frequently. The real shame in it all it that it focuses the
conversation on these high level exercises - be it coding on a white board or
rallying against take home exercises or demanding to be paid for interview
work, and ultimately to the employer you're put in a spot where you can't help
but feel a little reactionary as the transactionality of the relationship is
constant: I need to know you can do the work, prove to me you can, I will then
hire you and pay you to work.

What a cluster it's all becoming on the software engineering side.

~~~
stronglikedan
> a take home technical exercise

> prove to me you can (do the work)

A take home exercise only proves they can get the work done elsewhere. It
doesn't prove that they actually did it.

~~~
phendrenad2
This whole thing misses the point. We need WhiteboardFreeAndAlsoTakeHomeFree.
In other industries, my resume and a quick discussion verifying that I
actually did the work I said I did is suffficient

~~~
brianwawok
So say you are at a job. fairly happy. Maybe not your dream job, but you
decide to look around and interview with me.

I could present you two options:

1) I just hire you after a 30 minute chat. 50% you don't work out, and we fire
you after 30 days.

2) We have a longer interview. We whiteboard. We take home test. We whiteboard
some more. 90% chance that you don't get fired after 30 days.

Which would you prefer? As a business owner, I am happy to just try people I
don't know well - IFF they are willing to accept that there is a very good
chance they are fired within the first 30 days.

There is such a huge range in developers. The haves vs the have-nots can be a
100x different productivity difference. I really want to try to tease that
difference out. It is really really hard.

~~~
actionowl
> 1) I just hire you after a 30 minute chat. 50% you don't work out, and we
> fire you after 30 days.

Personally, that's my preference. If I don't think I can do the job I'll know
after a 30 minute chat.

~~~
ryandrake
Same here. I feel I have vastly more control of my work performance over the
course of 30 days than I have control of the assessment of 6 interviewers
after seeing me for 30 minutes.

In other words, I think there is far more than 50% chance that things work out
after 30 days and far less than 50% chance that I impress 6 interviewers.

------
danpalmer
Might be worth clarifying whether this is “don’t use a whiteboard during
interviews” or “don’t ask candidates to code obscure algorithms” on a
whiteboard.

We use a whiteboard in our interviews for sketching UI, and sometimes drawing
a database table. Generally candidates find this much easier than talking
through their design, and we think that interview very closely represents what
we do on a day to day basis.

~~~
jakelazaroff
There was a good article that popped up on here a couple months ago about
this: "Organizational Skills Beat Algorithmic Wizardry". [1]

If you're asking candidates to balance a binary search tree when no one in the
history of your company has ever had to do that, you're asking the wrong
questions.

[1] [http://prog21.dadgum.com/177.html](http://prog21.dadgum.com/177.html)

~~~
danpalmer
Yep. Which is why we don’t.

We do a mock technical meeting with multiple members of our tech team and the
candidate presenting options, talking through pros and cons, etc. Much of the
interview is about assessing communication rather than technical skills.

The interview is basically a standard tech meeting that we hold regularly in
the team to discuss designs of new projects.

~~~
jakelazaroff
Sorry — that comment was meant in support of yours, with the "you" being
generic :)

------
ddtaylor
I was just speaking with a co-worker about how I consider this interview
culture to be a race to the bottom in how much unpaid work companies are
getting from prospective employees. When I interviewed with Facebook they do
back to back whiteboard interviews for about 6+ hours then sometimes they give
"homework" problems, etc. Even skilled candidates can't refuse because a less
skilled candidate will come along willing to make the sacrifice.

I don't have any solutions only complaints and bitterness, sorry.

~~~
bgribble
At my startup we pay interviewees a decent hourly consulting rate for take-
home problems or full-day followup onsites (after the first interview).

We only do them when we are pretty excited about a candidate but need more
information to make a hiring decision.

It's cheap, really, considering the cost of sourcing candidates and the cost
of making a bad hiring decision.

~~~
scarface74
When I'm looking for a job, I usually have 3 or 4 strong prospects and looking
back on my spreadsheets that I keep when I am looking, it usually takes about
2 weeks from the time I reach out to my network of recruiters and I have an
offer (the shortest was 4 days from looking to having an offer from what was
then a top 10 Fortune 500 company).

Why would I go through that trouble? I have 20+ years of experience that I can
explain how I architected and developed from the website, to the middle tier,
to the database to multiple VPCs on AWS and dev ops. I'm not going to do
homework.

When I was first starting out I might, but living in a major metro area that's
not on the west coast, there are more openings for senior devs/architects than
people to fill them.

If a company wants to try me out, I'm more than willing to do a contract to
perm, but my hourly rate is going to be enough to cover self employment taxes,
make up for not getting paid for time off and at least two or three weeks
between employment.

~~~
noahc
> If a company wants to try me out, I'm more than willing to do a contract to
> perm, but my hourly rate is going to be enough to cover self employment
> taxes, make up for not getting paid for time off and at least two or three
> weeks between employment.

What does that number look like? 10k a week?

~~~
scarface74
For a 1099 contract where I'm responsible for my own self employment taxes....

2080 - hours in a work year

-80 Paid Holidays

-120 Paid Time off

-120 Gap between employment (based on my history)

= 1760 work hours per year

FTE Salary * .028 (Employer Medicare Contribution) + $7967 (maximum social
security amount - 128500*.062) = minimum salary

minimum salary/1720 hours = pay rate.

Take a reasonable salary for my market as $140,000, that is about $152000/1720
= $88.37/hour minimum.

Adjust the number based on market, skill set, and the amount of time you
estimate between jobs. I'm also not taking into account health benefits that
you would need to pay yourself because I'm covered under my wife, or 401K
matching. I would add 4% to the hourly rate to cover 401K matching.

------
JTbane
Whiteboards are not the problem- rather the questions that candidates are
asked are bad.

Asking someone to solve an obscure mathematical problem (the Two Egg problem
seems to be in fashion) doesn't do much except test whether the candidate has
memorized the answer.

~~~
ybrah
Whiteboard problems are used to show that you can work through a problem,
while communicating well about your thought process. They're also good general
intelligence tests, if administered correctly.

~~~
ivanche
I think an obvious reason for this type of interview problems is because
developers at work usually talk loudly while solving problems and write code
without the help of any external resource while the clock is ticking in the
background. Oh, wait...

~~~
lordCarbonFiber
What both you and the parent post you're deriding are missing is white-
boarding (when done correctly) isn't about the _problem_ at all. It's just an
easy way to get a candidate in the room and construct a technical
conversation.

As an employer I don't care how great your skills are, if you can't walk me
through your thought process for 45 minutes you're not going to be overly
successful. If you can't incorporate feed back or engage when pressed to
change your design you're probably not going to be successful.

Do your recruiting right and you shouldn't need the white board to simulate
whether the candidate can code at all (I think white-boarding with the intent
of looking for named algorithms is a waste of everyone's time), instead you
want to see if they can synthesize information, engage with other people, and
otherwise display the soft skills that tend to be much more useful metrics for
employee success than coding aptitude.

Granted, my industry is known for not having deep coding problems to solve,
this strategy might not be as useful in verticals that require more technology
chops.

~~~
krisdol
>As an employer I don't care how great your skills are, if you can't walk me
through your thought process for 45 minutes you're not going to be overly
successful. If you can't incorporate feed back or engage when pressed to
change your design you're probably not going to be successful.

The post you're responding to makes a great point that this isn't the normal
working environment for 99% of actually-writing-code developers. I discuss and
iterate designs with my coworkers/leads/managers/architects just fine, but a
surprise algorithmic problem you have to simultaneously solve, draw on a
whiteboard, and constantly present to an audience while being timed isn't
something I have been great at. I bet many others aren't either. I got good at
it after a few interviews last time I was looking for a job; but if I hit the
interview trail again today, I'm confident that I would flounder in that
setting for a while.

Imagine if, instead, the candidate worked out a project -- maybe at home, or
maybe in an interview room for some time -- then you take time to review and
understand their work and then go through this back-and-forth process of
discussing their work. This would also benefit the candidate's understanding
of how you collaborate to problem solve in your work environment.

The problem with this approach is that it requires the interviewer to actually
invest time to understand the candidate's work.

Anyway, I hope you see why many see it as a problem that the process for a
candidate to succeed at a job interview is to practice interviewing skills
rather than demonstrating their engineer skills.

------
vinayms
Comment: I think whiteboards get unnecessary flak when the real culprits are
games and riddles. I would argue that using a whiteboard to convey ideas is a
fundamental skill if one has to work in a creative team.

Question: How do you validate that the posted company or job position doesn't
need whiteboard? Is it after the fact, as in a disgruntled candidate
complaining? I couldn't find any information about this on the site.

~~~
clarry
> I would argue that using a whiteboard to convey ideas is a fundamental skill
> if one has to work in a creative team.

Yet a lot of people are never really taught to do it. Perhaps they pick up
this fundamental skill just fine after a couple whiteboarding sessions in the
company.

If a company is rejecting candidates for not having a skill that is really
easy and quick to obtain, they'd better not be one of these companies that
keep complaining about shortage of talent.

------
slackoverflower
FYI All your subscriber's emails are accessible at
[https://whiteboardfree.com/email_subscribers.json](https://whiteboardfree.com/email_subscribers.json)
since you didn't put any authentication on those endpoints. It's a basic Rails
app so I'm guessing other users may got a hold of the list already.

~~~
swyx
I guess their Privacy Policy checks out
[https://whiteboardfree.com/privacy](https://whiteboardfree.com/privacy)

------
nickthemagicman
I never realized whiteboarding was an issue. I wish someone would would make
one of these sites for open office free jobs.(not the softare)

~~~
tom_mellior
StackOverflow's job board has the "Joel Test" part where employers posting
jobs can check off the points from
[https://www.joelonsoftware.com/2000/08/09/the-joel-
test-12-s...](https://www.joelonsoftware.com/2000/08/09/the-joel-
test-12-steps-to-better-code/) that they fulfill. One of them is "quiet
working conditions", which comes close. Before looking it up just now, I could
have sworn the point was something like "every developer has a door they can
close", but oh well.

Anyway, I hoped you could search only for jobs where this box was checked by
the company, but apparently not...

EDIT: It does allow searching for minimal salary and remote jobs, among the
wishes listed in a sibling comment.

~~~
maxsilver
> Before looking it up just now, I could have sworn the point was something
> like "every developer has a door they can close", but oh well.

EDIT: Ok, my mistake, my memory is failing me. "Doors that close" is used in a
whole bunch of Joel blog posts, and "walls and doors" is used in the original
Joel Test description.

But WaybackMachine seems to confirm that the official label from the "Joel
Test" has always been "quiet working conditions" and does not appear to have
been changed.

~~~
tom_mellior
Sounds plausible, but the blog post from 2000 also has it as "Do programmers
have quiet working conditions?"

So unless Joel went back and rewrote the past, it might be our memories. I am
fairly sure that he did have another blog post that stated explicitly that
every developer at FogCreek had a door.

------
jasonrhaas
Wow, there are so many new ways that people are coming up with to recruit
software developers. Clearly there is a problem here that needs to be solved.

I understand that the company needs a way to vet people to make sure they are
technically proficient for the job. However, there must be a better way of
filtering people. I just bailed on a company after they told me what the
interview process would be:

\- Take home coding quiz where you need to sign up and use their algorithm
platform. As you would expect, there was asynchronous programming and a
recursion algorithm involved (two for one!)

\- 3 more technical interviews. 2 of which were screen share and/or white
boarding sessions. 1 is a "riddle part", which I assume is some kind of brain
teaser involving a recursive algorithm.

After I saw the coding quiz and all the follow on stuff I just told them I
wasn't interested. I was kind of offended, and it didn't put me in a positive
mindset towards the company and engineers that worked there.

~~~
scruple
It all amounts to little more than our industries hazing rituals.

~~~
nathanaldensr
This is what I tell people all the time. That one word sums up nearly every
dysfunctional interviewing and filtering process.

Hazing.

It's just monkeys making sure they only hire other similar-looking and
similarly-acting monkeys.

------
heckanoobs
I still whiteboard my programming question when giving interviews, can someone
summarize the case against whiteboards?

I'm just looking for the candidate's thought process and some pseudocode. I
could do the same thing in an empty text file but the substance of the
interview wouldn't change.

My feeling right now is that being anti whiteboard is focusing on trivialities
like complaining that the office style guide uses Allman vs K&R bracketing or
something. But I'm open to having my mind changed if there's something more to
it.

~~~
sidlls
Being anti-whiteboard is a proxy for being against the "regurgitate this CS
trivia on a board in front of me" style of interview, not against the use of a
whiteboard.

Most problems in practice that require non-trivial application of algorithms,
dynamic programming and the like have two characteristics that make them
differ considerably from whiteboard style quizzes. For one, they're going to
be much less contrived (pick a random leetcode question for an example of
this, odds are it's contrived). Secondly, they're going to be resolved when
developers talk to each other about them and there is recognition of the
solution, which most of the time is an application of algorithms and data
structures with library implementations.

The ability to whiteboard things like "given an array of integers and a target
find the indices of the pair of integers in the array that sum to the target"
and "find the first missing positive integer in an unsorted array in O(n) time
and O(1) space" provides almost no useful information about a candidate's
ability to solve an actual problem the company faces in most instances. There
are exceptions, but interviewing everyone for the standard of that one
exception is asinine.

------
akyu
Whiteboarding is fine when done well, horrible when done poorly. The variance
is on the side of the interviewers.

I've done a lot of interviews over the years, and I've encountered a couple
stereotypes:

1\. The gotcha interviewers. He pulled out his old algorithm text book and
found the hardest problem.

2\. The no bullshit interviewer. Asks you to code a somewhat challenging, but
solvable problem. No tricks. Basically non-trival fizz buzz problems. The
problem with these is there are only so many practical problems you can give
before it gets put up on leetcode, and every interviewee has memorized the
code.

3\. The clueless interviewer. They try to give you a weird mix of an IQ test
and a personality test, and maybe throw in a little bit of API trivia while
they are at it.

------
danielbarla
Is whiteboard interviewing so bad that people would go out of their way to
avoid it? I mean, I've encountered / can imagine horror stories for all the
usual alternatives: a) take this 3-day long mini-project, do it using all of
our preferred technologies (some of which you'll be using for the first time)
and get it back to us - it should only take you 4 hours! Or b) do this on
site, using our machines and environments which will be unfamiliar to you. Or
c) speak to some random invigilator over Skype. Or d) do a written test, or e)
take us through your GitHub collection, which may or may not exist, etc.

My preferred way of testing people was usually to try to get them to show me
that they have thought about why they develop software in the fashion that
they do. I would prefer to do this in person, at a very high level, but it
often ended up being a written test (where necessary, the language was your
choice, or pseudocode). Is this wrong?

~~~
twblalock
> Is whiteboard interviewing so bad that people would go out of their way to
> avoid it? I mean, I've encountered / can imagine horror stories for all the
> usual alternatives: a) take this 3-day long mini-project, do it using all of
> our preferred technologies (some of which you'll be using for the first
> time) and get it back to us - it should only take you 4 hours! Or b) do this
> on site, using our machines and environments which will be unfamiliar to
> you. Or c) speak to some random invigilator over Skype. Or d) do a written
> test, or e) take us through your GitHub collection, which may or may not
> exist, etc.

This is the problem. There was recently a large HN thread about the take-home
projects and how so many people didn't like them.

None of the options are popular: if you use whiteboarding, people will
complain it's a bunch of brain teasers unrelated to real programming work. If
you use take-home projects, people will complain about doing unpaid work.

Would professional certifications help? I doubt it -- they would need to be
based on standardized tests, which would have the same drawbacks as the
whiteboarding questions nobody likes.

~~~
danielbarla
To give an alternative approach - I found that in general, I could get a
pretty good idea about a candidate using either the verbal interaction or
written test.

The idea was to give questions which are almost a polar opposite of the
strange trivia style questions you see in certification exams. Instead of the
candidate having to remember which overload of an API returns a byte[], we'd
instead talk about things like how they prefer to structure a project, and how
this feeds into maintainability, etc. If the person was into object
orientation, we'd talk about that, if they were into a more functional style,
same angle, but I want them to have thought about it from a software
engineering side. It sounds wishy-washy, but with just a few pointed
questions, you can detect both BS answers, as well as someone who hasn't
really thought about it. I tend to find that this quality in an individual is
a very important predictor of performance, as it indicates deep care and
interest about their craft. With good candidates, you can get really deep into
a discussion and know within 5 minutes that they are quality.

Along the way, you'd also get a pretty good picture of the persons strengths
and stylistic preferences, which you can use to determine how and where they
would fit in with the team(s) you had in mind.

The only downsides are that I wasn't always available for these interviews,
and the written equivalent intimidating and could take long. Also, various
people swore that they either can't perform well in written or verbal
conditions, so perhaps letting the candidate choose between the two might be
beneficial.

------
yanslookup
I recently had an onsite tech screen at a FANG company that requires
whiteboard programming. The problem itself wasn't hard but I missed a
requirement that was actually a hint. I shutdown and couldn't move on or work
through it.

That said, I don't think whiteboard programming is always bad but it is a
skill that I don't exercise and it showed.

My advice, talk through the problem with the interviewer and don't start
writing code on the whiteboard until the interviewer has ok'd your proposed
solution.

~~~
dominotw
I usually need like good 5-10 minutes of quite time to think about the problem
in peace. I just can't seem to do with interviewer staring at me and hounding
me to 'think out loud', sorry I can't talk and think at the same time. I have
no practise at 'thinking out loud' , i never do it in real life.

~~~
bradlys
And that's why you have to practice.

I was the same but I do a lot better now after having done some 200+ technical
interviews and a lot of practice on my own.

~~~
Clubber
200 technical interviews?! What the hell? You shouldn't have to do 200 in your
lifetime. This kinda reminds me of those MCSE certification bootcamps they
used to have. They didn't teach you anything useful, they just taught you how
to hack the test.

------
ryanong
At plated we do two coding interviews. The first is concrete, we have a
library that is poorly written and their job is to implement a new feature and
refactor it. This is a great interview to understand core skills. The second
interview is a modeling exercise where we build an app from scratch with
escalating amount of complexity but only asking for what the database and api
endpoints would look like.

~~~
maxxxxx
This seems pretty reasonable to me.

------
stefanve
My personal experience in hiring is that people should be able to explain
concepts in a clear why. So usually I ask to explain an pattern that they say
they have experience in. I let him/her choose how they want to explain it
whiteboard / pen and paper / words only, sitting or standing. I don't care as
long as the person is good in explaining and has a firm grasp of the subject.
Both are needed to do a proper job. There are lots of people that are unable
to explain MVC in a clear let alone correctly even if they used .NET MVC or
spring MVC (or whatever)for 10+ years. After that is seldom useful to ask
anything else.. this approach had never failed me.

------
runlevel1
Do people hate whiteboarding in general or the questions they're being asked
to draw?

I can fully understand dislike for puzzles and being asked to implement
irrelevant algorithms in pseudo code. The interview should reflect the job
being interviewed for.

I've found whiteboarding to be mutually helpful in questions about system
architecture. Plus, it's something that we actually do on-the-job.

~~~
Clubber
Yes, but you don't write what you expect to be fully functional code on a
whiteboard. A whiteboard is good for sharing ideas. Using it to write and
assess code is pretty stupid if you step back and think about it.

I mean ask yourself this: do you ever use the whiteboard to write code to the
extent you expect some poor kid trying to get his first job to do? Hell no,
you screen share an IDE or paste code in an email.

People used to have to write code on paper (I did this a few times in college
ages ago) and that comes from the cost of compiling stuff way back when.
Computing time is friggin cheap, that's why no one does it. To expect some new
guy to be adept at that ancient practice is silly.

~~~
runlevel1
I agree. This is a form of the psychological concept of encoding specificity
principle[1] which states that recall is most effective when the conditions at
the time of encoding match the conditions at the time of retrieval.

[1]:
[https://en.wikipedia.org/wiki/Encoding_specificity_principle](https://en.wikipedia.org/wiki/Encoding_specificity_principle)

------
lasereyes136
This all remains me of a quote I have recently seen: "Most Programmer wouldn't
hire themselves"

As long as we keep asking people to do things that aren't like the work that
we do, we will continue to get mismatches and people that interview well but
work poorly. I don't have a great solution, finding good people is hard.

------
exelius
Don’t whiteboard during interviews? Or don’t whiteboard at all? Dropping the
former is good, the latter is bad...

------
blauditore
What would be a good selection strategy without technical interviews? I've
seen people with good CV and reference projects being hired, only to turn out
they literally couldn't program. It's old news that sneaking to a CS degree
without learning anything substantial is possible, and those are easily
debunked in even simple task like solving FizzBuzz on the whiteboard.

~~~
JustSomeNobody
No whiteboard doesn't mean no technical interview. You can pair up on a real
computer, you can have a take home, things like that.

~~~
blauditore
Both of these have huge disadvantages for interviewing:

\- When working in front of a computer, people get worse at communicating.
Even if they try to speak out their thougts, it usually doesn't work well, as
thinking _and_ operating an IDE (or whatever at hand) already occupies a lot
of brain capacity.

\- Take-home exercises are hard to control: You don't know how long a
candidate worked on it. Even if there's a target like 4 hours, some might work
all night on it - either because they couldn't do it in the allocated time, or
because they fear some disadvantage. Apart of that, they might pay someone to
solve it for them.

~~~
actionowl
> Apart of that, they might pay someone to solve it for them.

I think that can be solved by having the candidate talk about their solution
and how they made certain choices.

------
zerr
What about CS-riddles/competitive programming free companies? Who only ask
_relevant_ to the job questions during interviews.

------
api
I've been programming since BASIC on a VIC-20 sometime around age 6. I can
code in like 10 languages and have written everything from crypto and network
protocols to distributed systems, database sync engines, and high throughput
video compression/decompression codecs.

I always fail whiteboard interviews. I can't code at all on a whiteboard.

~~~
nathanaldensr
You're the false negative that nearly every software company seems intent on
avoiding at all costs...

...and probably a better software developer than 99% of the people they end up
hiring.

~~~
api
I ended up starting my own so meh.

[https://zerotier.com/](https://zerotier.com/)

------
alpb
Aside: With about 40 job postings, each at 300$/month, they're probably making
$144k with little to no operational or infrastructure costs. They should be on
[https://www.indiehackers.com/products](https://www.indiehackers.com/products).

------
notadoc
If you're interested in someones coding prowess and process, review something
they have written with them. It's far more effective than commanding some
nervous candidate to get in front of a group of people and start writing code
on a wall.

------
innagadadavida
There is a Netflix and Lyft post, but going by past experiences there are
whiteboard coding problems. Are these companies spamming it? How do they
police these possibly fake posts? After all, the thing recruiters care most is
how many people apply.

------
_bxg1
...do people really hate whiteboard interviews enough for a website like this
to make money?

~~~
strken
Some proportion of perfectly good engineers couldn't pass a whiteboard
interview to save their lives, for much the same reason I couldn't pass a job
interview that measured communication skills by karaoke performance and emoji
literacy.

~~~
_bxg1
The company needs to evaluate your problem-solving skills though. I mean, I'll
admit that writing code on a literal whiteboard is more physically arduous
than on a keyboard or even a piece of paper, but if the root issue is live
coding challenges themselves, I don't see a way around it.

Some companies look at your GitHub profile instead, which imo is much more
unfair, because it presumes you've had the free time and the desire to work on
side projects, which shouldn't be a requirement for a job.

Maybe companies should adopt an either-or policy? Give the interviewer the
option to demonstrate their skills in the form that works best for them.

------
EgoIncarnate
Maybe Lyft varies it's interviews, but:

1)
[https://whiteboardfree.com/job_posts/52](https://whiteboardfree.com/job_posts/52)
\- Lyft - Data Engineering

2) [https://eng.lyft.com/interviewing-tips-for-android-
engineers...](https://eng.lyft.com/interviewing-tips-for-android-
engineers-f01ce7fba163) \- "Expect a few coding questions either on a
whiteboard " ( Dec 21, 2017 )

Pretty sure Netflix (also has a job listed) does whiteboard based evaluation
too.

------
stephenr
Up next: elevator music free jobs. Dev jobs at Companies without that
predictable elevator music.

Maybe I’m missing the point though.

~~~
jhall1468
The point is "post a job for $xxx". This shit has gotten popular after the
success of weworkremotely

------
JustSomeNobody
I don't mind whiteboarding. I do mind questions that are puzzles or
algorithmic in a way that does not directly reflect the company's current
software.

I usually (ok, almost always) flesh out designs and pseudocode with pencil and
paper anyway, so changing to use a whiteboard isn't an issue.

Standing in front of a handful of strangers glaring at me while I try and
figure out some stupid algorithm they had to Google themselves is hazing and
should be stopped.

Edit: Also, dinging me for small syntax issues on a whiteboard when I'm used
to using an IDE is not really cool.

------
weeksie
You know, when I'm interviewing someone my VASTLY preferred approach is to
have them walk me through something they've coded that they're proud of.
That's not aways possible, but often it is. Give me a good slow walk through
your github repo and tell me where and why you made the choices you did, what
the tradeoffs were, etc. . . Better than making some poor bastard jump through
hoops on problems that only vaguely resemble the ones they'll be solving at
work.

~~~
mongol
Yes this is the best method I have found. Let them explain something they have
worked on that provides them with experience they believe qualifies them for
the position. Here I can surely expect them to have depth, assess their
communication skills, be able to explain further on questions from me etc.

------
dahart
I'd love to hear alternatives, rather than a list of who doesn't.

I don't use whiteboards for coding tests, I use whiteboards as one (of
several) ways to evaluate how someone thinks on their feet without having
Stack Overflow & Google at their fingertips. I don't only want to know if
someone can code, I want to know about their process, how they think about
things, what assumptions they start with, and what kinds of things they like
to explore. I want to see some personality. Take home problems don't measure
that very well, nor do coding tests with online resources available.

I've never met a perfect interview, but what are some suggestions for more
acceptable and/or better ways to evaluate how someone thinks on their feet?

I remember hearing that Google's done quite a bit of research on hiring
practices vs outcomes, and that one of the leading predictors is having
external groups do the interviewing, i.e., making sure the people doing the
interviewing have no stake in the outcome.

~~~
parsnips
My hypothesis (of what people want in an interview):

Interviewer to engage in conversation with applicant about applicant's prior
work in detail. If the applicant can give sufficient explanations of
systems/projects and the interviewer can ask appropriate probing questions and
get sufficient responses to those questions from the applicant.. then the
interview can be concluded positively.

The crux of it, from the applicant point of view, is that they want to be
believed and treated "professionally". Further it's "insulting" to be
questioned about anything other than specific experiences. That's why you see
objections to every sort of "objective" line of interview:

sample projects - too much time, why am I coding for you for free?

github/open source - I have hobbies outside of programming

white boarding/google doc coding - not my environment for writing code. I need
emacs with xyz keybindings or we're not going to make progress.

algorithm problems solving - the job doesn't entail re-implementing hash
tables, or sorting algorithms... The question(s) are not germane to the
position

etc etc etc

~~~
dahart
> they want to be believed and treated "professionally". Further it's
> "insulting" to be questioned about anything other than specific experiences.

Yeah, I agree; I have the same hypothesis that this is what people want. And
it's a problem to assume and/or act like talking about anything other than
specific coding experience is in any way insulting. That's not exactly a
realistic expectation, nor is it a great attitude for getting hired.

Personality, behavior, poise, attitude and communication skills are
_absolutely_ relevant to someone's ability to do their job on a team. If you
can't think on your feet or answer a question without a computer in front of
you, and you start getting angry, how will you behave in meetings? That
behavior is precisely one of things I look for when I ask candidates to think
on their feet.

If someone assumes that being asked certain questions is "unprofessional",
then that's a red flag and I'll be more careful before hiring someone like
that. Now that I think about it, there's a bit of irony that if someone
performs poorly on these kinds of questions, I'm likely to spend more time
investigating that and asking more questions along those lines.

~~~
Clubber
Ask your doctor to do a free diagnosis so you know he's for real. See where he
instructs you to go.

~~~
dahart
Did you mean to reply to someone else? I appreciate the reply, but I’m
confused about what you're responding to and what point you’re trying to make.
I haven’t suggested or advocated anything about doing work for free.

That said, this example doesn’t convince me of much. Doctors have to go though
a full year (or more) of underpaid work (called residency), and worse,
extremely long and on-call hours. They think programmers are pretty spoiled,
at least the ones I know personally do. When I've complained to them about
pulling 80 hour weeks in films & games (sometimes without overtime pay), I've
gotten words back like "lazy" and "whiny". :P

Doctors also have to do unpaid diagnoses when they interview for jobs, in
order to prove they’re real. And they have to do unpaid diagnoses for their
family and friends, just like we have to do IT for family & friends.

If you want the job, you do need to demonstrate you’re capable of performing
the job, no? What alternative are you suggesting?

------
rbosinger
I had to write a JavaScript program on graph paper (with no computer on hand)
as a college test. Then the professor would type them out afterwards with you
and try to run it. Whenever I hear about this whiteboarding issue I think of
that. It was actually kind of fun in a weird way though. I drew nice curly
braces.

~~~
spraak
> I drew nice curly braces.

Heh, I code pretty often on paper when I'm working through a design and my
style has evolved to just using < and > as proxies for curly braces which
saves me time, since trying to draw a nice curly brace takes me so long.

------
donretag
I do not mind whiteboarding at all. I have three whiteboards at home for
brainstorming. I draw the line at doing take home tests.

I cannot interview a company if I am doing a take home assignment. With
whiteboarding, I get to also assess my potential co-workers abilities by
seeing if they are asking interesting questions.

------
iothetiger
This is great. I suspect the "coding exercises" in interviews are really
dominance hierarchy games. It goes against politeness theory and is a threat
to an individual's 'negative face' or need for autonomy.

------
lscore720
Some companies effectivdely use whiteboarding, others don't.

This is a true snapshot of the absurd sense of entitlement among some tech
workers these days. When the bubble eventually pops, people will look back at
this website promotion with awe.

It's like challenging the generally accepted standard that interviewees dress
up a bit more formally than a typical day at the office (i.e. button down
versus old T-shirt).

------
justin66
I interviewed once at a place where a friend worked as an engineer. She
assured me that they didn't do whiteboard questions. Guess what I had to
contend with during two different interviews...

------
djhworld
At my work one part of the interview is a System Design test, where the
candidate is presented with a problem and we ask them to come up with a system
(i.e. by gathering requirements etc)

Usually this means drawing stuff on the whiteboard with boxes and arrows. Not
looking for the perfect system or 'correct' solution, just really having a
look at what the candidate is experienced in and how they think.

Whiteboards are fine for that use case, and can be very expressive.

Doing binary search trees and stuff though doesn't seem as useful really.

------
bhuga
This is a good idea, although the focus on 'anti-whiteboard' is a bit
limiting. It's a shame it's its own site instead of a feature on other sites.

There's no interview process that works best for every candidate; some prefer
whiteboards or homework or practical debugging on their on computer or hand-
wavey design or whatever. Candidates (and companies!) could save a lot of time
by letting applicants filter their searches to companies using methods that
will let them put their best foot forward.

------
curtis
I'd much rather code on a whiteboard than do a take-home assignment. I may be
in the minority but I rather suspect I'm not the only one.

I can understand that some people find whiteboard coding really stressful. I
never have, and I have found take-home assignments to be a huge time-sink
which typically results in minimal feedback (and sometimes none at all).

Maybe the right thing to do is to just give interviewees a choice.

------
j7ake
Using a whiteboard to give a talk about your project is desirable in my
opinion , you might need to be more specific with what is whiteboard free.

------
edem
So is this supposed to be a good or a bad thing? I've used whiteboards in a
lot of interviews to great effect. I wouldn't confuse whiteboards with
riddles. I also hate riddles and puzzles because they check for the riddle-
solving skill, not the actual skill which will be used at work. Whiteboards
are a completely orthogonal topic to riddles.

------
donttrack
I was “surprise whiteboarded” recently. It was my first whiteboard interview
and I actually thought it was an interesting experience.

------
Shank
I really like the idea of this, but how many jobs posted here are for senior
or high experience positions? The whiteboard filter can still happen at any of
these companies in junior developer ranks.

This just creates elitism where the "senior" developers get nice hiring
processes, and the junior developers get stuck with traditional torture.

~~~
taurath
I think its still valid if someone doesn't have a good-size body of work,
however the more CS heavy it is and unrelated to the actual work the more
you're optimizing for "did this person recently graduate with a CS degree".

------
d--b
So all of these ask for a 2-week home project?

------
kazinator
How about "night-mode.com": developer jobs at old-school companies that
interview with a blackboard and chalk.

------
gldev3
What i want the most is being able to put these companies to test, i have 0
problems with whiteboard problems but like evaluating them, are they all
compotent or is it the company a one trick pony with only a few decent
engineers.

------
ivanhoe
It would be very useful to be able to filter just the remote positions.
Searching for "remote" as a location returns no results, and I can see in the
list that some remote positions are being offered.

------
pulkitsh1234
Free alternative: [https://github.com/poteto/hiring-without-
whiteboards](https://github.com/poteto/hiring-without-whiteboards)

------
tal_berzniz
A lot of the important tech decision take place around a whiteboard where
people communicate their ideas.

Whiteboard questions are okay. Only giving tasks is not how a real workplace
work

------
pagbot
Cool. A website full of companies to avoid. Thanks for posting!

------
diabeetusman
The Terms of Service page is blank
([https://whiteboardfree.com/terms](https://whiteboardfree.com/terms))

------
hellofunk
I think whiteboards are much better than the remote code-as-we-watch stuff,
which is even more common and not a good way to measure actual work skills.

------
hnrodey
Am I the only one who thought this post title meant jobs at companies that
simply don't use whiteboards in the day-to-day aspect of working?

------
dash_shi
Lyft doesn't do whiteboard when hiring engineers?

~~~
denvercoder904
That's the first thing I noticed about the list. I interviewed with Lyft last
year and they did whiteboard style interviews. Since when did this change?

~~~
jhall1468
It didnt. I'd guess they are just pulling in a ton of jobs so they look
popular enough to justify the fee to post a job there

------
kuon
I've been coding for 25 years and I wrote some complicated piece of software,
but I would be incapable to write code on a whiteboard.

------
keeptrying
Best job board marketing I've seen in a while.

------
smnplk
Call me racist, but I also don't like blackboards.

------
ybrah
Whiteboard problems work great as a general intelligence test if administered
correctly. A well designed whiteboard problem will filter out people of lesser
intelligence. This means the people you would be working with would generally
be more intelligent. This is not a bad thing.

Furthermore, whiteboards are great communication tools. I spend some time on
VRChat's whiteboard room teaching people various algorithms, and other
abstract things to help me learn. Someone who knows how to use a whiteboard
and communicate correctly would be a better hire than someone who doesn't.

If the company you work at uses whiteboard problems to vet interviewees, just
drill them. With a little practice, you'll have a better chance.

~~~
nunya213
This is so wrong that it actually hurts my brain. Albert Einstein, a
certifiable genius probably could not tell you how to invert a binary tree,
this has nothing to do with intelligence and everything to do with how many
HackerRank problems you have memorized.

~~~
Melchizedek
True, but there are also brain-teaser type problems that don't require
memorization of obscure algorithms, and those could actually be disguised
intelligence tests. (But I suppose if you really wanted to you could memorize
most of the brain-teaser problems in existence.)

~~~
nunya213
Google has already shown that those types of questions have 0 correlation to
developer success.

