
Anyone else thinks that Whiteboard interview is just covered ageism? - zerogvt
It&#x27;s the second time in a few months I&#x27;m being turned down with the pretext of a failed whiteboard interview. Things like improper syntax and not getting the damned recursive solution fast enough.
Given that I am 42 yrs old and been at this line of work for 14 yrs now I think it&#x27;s safe to assume that I neither have the time nor the appetite to constantly exercise on solving mind puzzles in whiteboard. I am good at what I do -and I do it at a top level company- but it has nothing to do with coding on a whiteboard. I&#x27;m sure that anyone who is a few years _out_ of the university and _into_ a real job finds it both hard and surreal to go through these hoops to land a job. Whiteboarding simply tests for skills that are not needed nor exercised once you&#x27;re out of uni<i>.<p>Thinking all that it then dawned on me. Maybe this abomination is just a way to take out older candidates and favor young ones. A form of ageism that is legally safe for the company.<p>Dunno - what&#x27;s your thoughts?<p></i>By whiteboarding here I mean testing the form of questions one can find in places like hackerank and the like. Obviously, drawing a large system design or using a whiteboard as an aid to describe&#x2F;analyze other aspects of a system is not the topic I&#x27;m touching on here.<p>PS 1: I&#x27;m done with that sh1tshow myself. I sincerely hope I&#x27;m never that desperate to put myself through that again.<p>PS 2: For what is worth here&#x27;s a repo with all companies that do not use whiteboarding: https:&#x2F;&#x2F;github.com&#x2F;poteto&#x2F;hiring-without-whiteboards
======
rmah
I'm even older than you and have no problem with using a whiteboard during
interviews. That said, interviewers who get hung up about precise syntax are
poor interviewers and need coaching. Or are just looking for an excuse to ding
someone. More to the point, I don't see how asking to put answers to technical
questions on a whiteboard favors younger people over older people.

~~~
ryanisnan
I agree. What would age have to do with recalling syntactic idiosyncrasies, or
being able to theorize about problems with a dry-erase marker and a whiteboard
(or a pen and pencil, or a keyboard and a computer)?

Reading between the lines, you seem upset about having to answer questions
about technical problems you perceive to be irrelevant, and that these
technical problems are more likely to be solved successfully by those who have
recently practiced them (e.g. graduates).

I too agree that, while abstract technical interview questions have little
bearing on most day-to-day work, they do some things quite well:

1 - Define a well-bounded problem of sufficient difficulty 2 - Give the
interviewee a good baseline for objective success 3 - Exercise a person's mind
to think about complicated problems

While they are contrived and not entirely representative of daily work, they
are not without value.

~~~
asark
I think most of the dislike comes from the tendency of typical whiteboard
questions to favor someone who happens to have seen a very similar problem
recently, the same way someone who comes up with the correct answer to a brain
teaser very quickly is usually someone who's seen it before. Many rely on
that, in fact, since otherwise they'd be asking people to come up with a
publishable (once published, perhaps) finding, under pressure, on the spot, in
maybe an hour.

This might be fine if the "very similar problem" is something you'd likely
have encountered in your work, but often they questions are drawn from a pool
that _most_ people in this line of work see rarely if at all, and if they do
it's likely to be some very small subset of the questions, so dedicated study
of the remainder of the pool still puts one at a large advantage, regardless
how useful it is in doing your actual work.

They're measures of "how bad you want it" (how much of your time you spent
memorizing stuff you don't actually use to prep for the interviews) and/or how
recently you took an algorithms course. And maybe those are things worth
measuring, I dunno. Maybe the absence of strong enough signals on either of
those is important enough that it makes sense to use them to reject people who
are otherwise very capable of doing the actual work.

~~~
username90
> Many rely on that, in fact, since otherwise they'd be asking people to come
> up with a publishable (once published, perhaps) finding, under pressure, on
> the spot, in maybe an hour.

In much of science the hard part is asking the right question rather than
coming up with the solution, so figuring out these algorithms is not
equivalent to making publishable research.

------
ohaideredevs
"It's the second time in a few months I'm being turned down with the pretext
of a failed whiteboard interview. Things like improper syntax and not getting
the damned recursive solution fast enough."

Is it a pretext, or did you actually fail the interview? I want to work for
West-coast-pay company at some point, and it seems that the idea there is for
me to spend 6 months learning stuff I will never use, so I can compete with
the kids who spent 4 years learning mostly stuff they will never use.

That is, if I fail it, it's not because I am older, it's because I don't know
stuff fresh grads know.

IT is full of grinding pretty meaningless stuff (especially at lower levels),
as much as we romanticize it.

~~~
ziddoap
> _That is, if I fail it, it 's not because I am older, it's because I don't
> know stuff fresh grads know._

I believe this is exactly the point that the parent poster is making. You
don't know the stuff fresh grads know _because_ you're older (obviously this
isn't an absolute, but likely). Therefor, structuring the interview around
stuff that only fresh graduates are likely to be up-to-date with would be
discriminating against older people.

If you fail, it _is_ at least related to you being older, if the focus of the
interview was designed around hiring fresh graduates.

~~~
munificent
College dropout here. Young people sometimes don't know this stuff either.

This is probably less ageist than it is education-ist, which is not too far
away from classist.

Personally, I do think it's worth testing candidates on these pure CS skills,
even though I myself didn't have them and had to study before I interviewed at
Google. What I've found since then is:

1\. Surprise, surprise, I actually have used quite a few of these concepts in
my work. My experience may not be typical, but my role really does benefit
from my having a better grounding in algorithms than I did before.

2\. When communicating with other people at the company, it is _very_ helpful
to be able to presume a baseline understanding of algorithms, data structures,
and big-O. A lot of code reviews and design discussions are easier and faster
when you can just say "yeah, but that's O(n^2)" or "BFS would let you early
out more frequently here".

As an interview technique, I also think there is some value in testing an
arbitrary skill a candidate might not have, because it's a good gauge of
hustle and discipline. Yeah, learning algorithms is a chore and a hassle.
But... a lot of shit you have to do at work is a chore and a hassle.

If the interviewer can see that you're able to make yourself do that for the
interview, it's a good sign you'll have the discipline to do some of the
grunge work that is inescapable in the software field.

~~~
srfilipek
I agree with your first points, but...

> Yeah, learning algorithms is a chore and a hassle

> If the interviewer can see that you're able to make yourself do that for the
> interview, it's a good sign you'll have the discipline to do some of the
> grunge work...

This doesn't make any sense, unless very, very specific bounds are put on the
interview questions beforehand...

Without that, what is a candidate to do? Memorize all known data structures
and algorithms?

~~~
munificent
_> Memorize all known data structures and algorithms?_

No, but you should know the classics. That's kind of the "general contract"
for how these big tech companies interview. Most also proactively tell
candidates what material they should expect to be interviewed on, like:

[https://careers.google.com/how-we-hire/interview/#onsite-
int...](https://careers.google.com/how-we-hire/interview/#onsite-interviews)

A good interviewer is not aiming to ask gotcha questions where if you don't
know that one specific weird algorithm for that one specific data structure,
you're entirely hosed. That provides almost no useful signal to the
interviewer.

But they will ask questions where some well known data structure is part of
the solution and then provide guidance as needed based on what you seem to
know.

------
pdpi
If you're writing code on a whiteboard in an interview, syntax, library calls,
etc, should not at all be part of the evaluation process. You dodged a bullet
on that one.

Being able to "get the recursive solution fast enough"? Depends a lot on the
expectations, might or might not be an eliminating criterion. Definitely a
problem e.g. for functional-heavy environments, where that style of reasoning
is expected to be your bread and butter.

In the general case, I've seen fairly senior developers crash and burn on
basic programming interviews (be they on a whiteboard, on a laptop, or
whatever other format) due to genuinely weak programming skills, so I don't
agree with the assumption that some candidates are "above" these interviews.

Also, a lot of seemingly pointless questions are good questions phrased wrong.
E.g. I will never ask you to implement depth-first tree traversal on a
whiteboard, but will ask to pretty print a directory structure, and make a
note of whether a candidate notices this actually _is_ depth-first traversal
dressed up as a practical day-to-day problem.

Of course, just because the interview format is not fundamentally flawed
doesn't mean that plenty of companies don't mess up implementing it in
practice...

Then again, your PSes suggest you don't want a reasoned discussion so much as
you just needed to get that off your chest, which is fair enough.

------
Kapura
In my experience, whiteboard interviews are absolutely a form of gatekeeping.
Whether the firms know it or not, they are excluding candidates who would have
succeeded in the role by including weird unrelated side content in the
interview. As the OP rightly mentions, nothing you program on a whiteboard has
any application once you are actually in the job. It can be incredibly
frustrating to know that you can do the work of a job, but be denied because
of an old superstitious test.

The only silver lining is that, ultimately, companies hire the candidates they
interview for. If a company makes its hiring decisions based on trivia
quizzing and whiteboards, they'll ultimately produce software that reflects
that. During my last big job search, I eventually started asking upfront if
there was whiteboard coding in the interview. I don't want to waste my time.

------
gfodor
Beyond whiteboard based coding being a bad medium, on-the-spot programming
exercises are a super noisy, poor medium for assessment compared to the
alternative: a work sample in the form of a 4-8 hour programming exercise done
by the person on their own terms. No exploding deadline, no restrictions on
tools other than those necessary to show the person's relevant job skills.
Make a bunch of them, put the time into them, and let the candidate have a
chance to pick from a library of exercises that are interesting and fun to do.

The main downside to a work sample is that a lot of people will say they
simply don't have the time to do it. That's fine, you'll lose some people, but
you'll also have people applying who really want to work for the company. From
there, you'll have a small number of people who do a great job on it. By the
time they are in your office interviewing, the idea that you'd reject them
because of a slip-up on a small coding exercise on a whiteboard is absurd,
because you already have a mountain of evidence regarding their skills as a
programmer. The in-interview exercises will be there to test other skills like
communication and collaboration, not writing good programs.

~~~
munificent
I think there's a good argument that larger-scale work-sample exercises like
this are even _more_ ageist because older candidates are more likely to have
family commitments that give them less free time to allocate for things like
this.

~~~
gfodor
Frankly, I've heard this before and I disagree. (I'm a parent.) It does mean
you have to be selective with regards to what companies you apply to: you
don't have infinite time (and nor does anyone.)

It's a catch-22, however. I look for companies that have good interview
processes, because it means they are going to have good employees. I feel
pretty strongly that good skill assessment is a critical component to hiring
good people. I don't think you can hire programmers based upon resumes,
references, or 'track record' alone. I think you need to assess their skills
in a very deep way during the interview process, since there are a lot of
candidates who look good on paper and can talk the talk (deliberately) but
when actually put to work aren't up to the job.

So, I look highly upon companies that actually provide a good forum for
showcasing my skills: not just because it means my interview will be fair, but
it also means that the people I'm working with will have had their skills
assessed in a similar way. I'm willing to make that tradeoff in time and
prioritization. It's basically this tradeoff: unless you think you can hire
good programmers without a assessment, you either should expect to be assessed
(and should look kindly upon assessment mechanisms you feel do a good job of
assessing your skills, like a work sample), or you should expect to work with
less skilled programmers, on average, if you get the job.

edit: should add, I love your game programming book! :) thanks for writing it.

~~~
munificent
Yes, I agree with you overall. I'm not crazy about the algorithms-on-a-
whiteboard process, even after having been on the other side of the table many
times. I have very little confidence on my ability to judge someone's
suitability as an engineer based on their performance at a whiteboard.

At the same time, I just wanted to point out that deeper interviews have flaws
too. The time commitment is a real challenge, in particular for people that
have kids or are in an economic place where they may be working multiple jobs.
You don't want someone's inability to commit the time to interview to
inadvertently filter them out. Especially because the people who have the
least time are often the ones most in need of a good-paying, stable software
job.

 _> edit: should add, I love your game programming book! :) thanks for writing
it._

You're welcome! :)

------
giancarlostoro
I tend to avoid places that whiteboard, the one time I did have to do it I
sucked it up only because a friend stuck their neck out to get me the
interview. I was told syntax didn't have to be perfect. Yeah I think they may
come up with stupid excuses basically to not hire you.

Honestly, interviews go two ways: you figure out if you _really_ want to work
there, and they do as well. If they don't want you, assume it's for the best,
you would of had to deal with worse: coworkers who hate your personality or
have a toxic personality.

~~~
padobson
_you figure out if you really want to work there, and they do as well_

I don't think this can be overstated. If you don't enjoy the interview
process, you probably don't want to work there.

At the same time, interviewing is often the only way you can find out if a
company is really serious about hiring. In my experience, most companies with
organized HR have certain positions that they are "always hiring". Which isn't
really true, they just want to have the light on in case a rock star happens
to be looking for a job.

I've been on a bunch of interviews where it was clear neither the company or
hiring manager was enthusiastic about finding someone to fill a position, but
that HR was pressuring them to keep the light on.

~~~
bquinlan
_I don 't think this can be overstated. If you don't enjoy the interview
process, you probably don't want to work there._

I disagree with this. The interview that I enjoyed the most was with founders
who took me out for beer. We talked a bit about software but most of the
discussion was small talk.

After a few months of working there, I realized that some of the people in the
office didn't really have any qualifications except "liking beer" and it
wasn't a professionally interesting place to work.

My least pleasant interview experience was with Google but I enjoy working
there.

------
xenocratus
I was not prepared when I had my last interview like this, but if I ever go
interviewing again I'll make sure to have my own algorithmic problem at hand
(to which I'd know by heart all the tricks and improvements).

Then at the end of the interview I'll ask the interviewers to solve the
problem (or just give a description of how it would work). Point being - if
they interview you on this stuff but can't do it themselves without knowing
the solutions before, then how could they reasonably claim to be assessing
you? And would you want to work for someone who does this to potential
employees?

It sometimes seems like these interviews are d __k measuring contests between
the two parties.

~~~
crimsonalucard
That's perfect. If you think an interview went badly. Give them an algorithm
problem at the question session that very likely they won't be able to solve.
That's a perfect way to show them their bias.

------
gfodor
It amazes me people still actually do this. Why would you, in 2019, not just
ask a person to bring their laptop with their preferred development
environment set up on it and ask them to solve some basic coding exercises
there instead.

Physically writing code with a marker on a wall seems akin to asking a
mechanic applying for a job to demonstrate their skill at repairing cars by
performing a 'repair' on a miniature car made of lego bricks.

Edit: one thing I noticed once I started having candidates work on their own
laptop was a) some very unqualified people slipped through the screen and this
can be obvious when they have no programming tools on their personal machine
and b) you can learn a lot quickly from seeing someone use their own machine
-- you get a clean signal if they are adept at using their text editor, git,
build tools, etc, without risk of a contrived setup making it a false
negative.

~~~
rolltiide
Square’s interview was like that a few years ago. Even has pair programming
with the interviewer. Most fun I had in an interview!

Still stings when you thought you had a positive experience but they didnt
think so. Only other time I had that experience was with first dates that I
thought went well.

~~~
gfodor
Yep nobody likes getting turned down by a potential employer, but it stings
'less' if you feel like you were treated fairly and given an objective, un-
biased forum to showcase your skills. Nothing is more demoralizing than being
able to replay in your head the point in the interview where you got 'dinged'
for something ridiculous due to a quirk of the process like marker-based-
programming and feeling that sent you on the trajectory for a rejection. In
those scenarios, it can even be a self-fullfilling prophecy, since if you are
intimidated by marker-based-programming it can just lead to little mistakes
due to nerves that ultimately cost you the job.

~~~
rolltiide
> Nothing is more demoralizing than being able to reply in your head the point
> in the interview where you got 'dinged' for something ridiculous due to a
> quirk of the process like marker-based-programming and feeling that sent you
> on the trajectory for a rejection.

Honestly, I'm so desensitized to that so I don't feel that way. I go in
expecting a random brain teaser that I BS my way through.

I actually land most jobs by recycling interview questions and answers from
prior interviews.

"Let me know if you've seen this question before" NOPE

But more companies have also done more core competency related exercises with
IDE's set up or take home exercises. Haven't been paid for a take home
exercise yet, but I'm hearing thats happening a little more too. I think a lot
of startups in the bay area are content that their employees will stay for
around 18 months, so they dont need the brainteaser rationale that they need
to interview an engineer on the idea that they change teams.

------
40acres
I don't have a problem with whiteboarding, I collaborate with teammates all
the time to design rough sketches and even bits of code on the whiteboard. The
only critism I would have is if the interviewer is overly strict on things
like syntax and API names.

White boarding questions should be related to the fundamentals of computer
science and programming. Trees, hashes and arrays have been and will be around
forever, it's fair game in an interview setting.

~~~
crimsonalucard
Right but these questions can get mind bending. Like count the amount of ways
to make change for a dollar. That's a basic tree question.

------
stcredzero
_Anyone else thinks that Whiteboard interview is just covered ageism?_

It really depends on who is interviewing you. It can be. Even the Google
Hangouts, screen-sharing one can be. I've definitely had that sense from one
interview.

 _Given that I am 42 yrs old and been at this line of work for 14 yrs now_

I'm a bit older than you, and have just a bit more experience, so I think I
know where you are coming from.

 _Whiteboarding simply tests for skills that are not needed nor exercised once
you 're out of uni._

Again, this greatly depends on who is applying the technique and how it is
being applied. It _can_ be applied to see if the person can actually do the
kind of systems thinking to put a new design together and make it specifiable,
such that someone could go and implement it.

That said, I've also taught courses to high school, college, and professional
students, and I think the skill set for interviewing and the difficulty of
learning good application of the techniques is of the same scale as teaching.
In other words, don't expect to get good outcomes by just giving interviewers
a few seminars, then telling them to go at it. You'll get the same level of
interviewing as the level of teaching you get by doing the same thing to TA's
with no experience.

The biggest single issue I've seen in whiteboard interviews, is the
interviewers being hyper focused on what they want to find, and not listening
to what the candidate is saying.

------
southphillyman
Yesterday I read that Google actually decreases their expectations in the
white boarding exercises for experienced hires because they realize the
leetcoding techniques will not be as fresh in an experienced dev's mind. The
expectations are higher in regards to system design and resume questions. That
seems to be fair imo.

Later in the material it said that they reject over 80% of people who make it
onsite. The bar at FAANGs is just relatively high regardless what kind of role
you are trying to get. My mentality is preparing for high bar whiteboard
interviews best case lands a job at a FAANG and worst case makes it incredibly
easier to land a job elsewhere at a company that doesn't rely on whiteboarding
or has a lower bar in general. That's to say investing in whiteboard practice
has little downside and has an acceptable time/reward ratio given the results
if you are even just ok at it. In terms of ageism whiteboarding is not
required to filter older devs out. Resumes viewing can do that. Why would they
waste 6+ hours of their expensive Sr. devs time to put someone through a
pointless exercise? Serious candidates will commit the same 1-3 months of
study whether they are 23 or 43.

~~~
zerogvt
Great to hear that. I went through that hell (of course fell into the 80%) a
few moths ago. Needless to say I was in total awe by the whole process. Awe as
in, what the heck did I waste whole weeks for? How can the -seemingly best IT
company- hire like that? Funniest part was that the recruiter giving me the
bad news was assuming that I'd spent some more time in the future trying again
to get in g. Like this is a life purpose or sth and she actually mentioned
exactly that. Most people don't get in at first attempt. Which is like saying
"we know we do it wrong because we hire the same people the second time
around" so what the heck is all that supposed to test? Perseverance? Anyway -
after that I had serious doubts that I'd ever be happy working there anyway so
I was pretty confident that there wouldn't be no second time.

~~~
twblalock
They hire that way because they are optimizing to avoid hiring bad engineers.
Their entire process is shaped around that goal. In such a process, passing on
good people is not considered a problem -- especially when they will reapply,
which they do.

------
notacoward
I think it's a bit in between. FWIW, at 54 I've never failed a whiteboard
interview, including at my current FAANG employer, so this is most certainly
not sour grapes.

While not _deliberately_ ageist, I think whiteboard interviews work out a bit
that way. What can be tested in such an interview? Only a sampling of domain
knowledge. It will tend to be a sample weighted toward the particular problems
and algorithms that will be super-fresh in the minds of people still in or
fresh out of school (usually because the interviewers themselves are). To
someone older but still well versed in that domain, those _particular_ details
might have been crowded out by a thousand other things learned since. They
might seem less familiar because of changes in language, notation, or idiom.
Those same differences will also affect how the result is "graded" even if the
candidate solves the problem quickly and well.

Whiteboard interviews also fail to measure other things such as ability to
select algorithms or higher-level approaches, people or organizational skills,
industry knowledge, or a developed "instinct" about what symptoms suggest what
problems in the relevant kinds of code. As more weight is given to whiteboard
skills, less weight is given to literally everything else.

As I said, I don't think any of this _intentionally_ disadvantages older
workers, but it can have that effect without intention. It has never hurt me
personally, but I have plenty of peers who I know beyond doubt could code
rings around the people who interviewed them. They just couldn't dance that
particular dance well enough in that moment and got rejected. That's a loss
for the (potential) employer as well as for them.

------
zucker42
Not saying that whiteboard interviews are perfect, but is there something
inherent to them that makes them favorable to younger applicants? Your main
argument to this effect is:

> Whiteboarding simply tests for skills that are not needed nor exercised once
> you're out of uni.

But I don't know if "whiteboarding skills" are any more useful _during_
college either. Also, I always thought explanations were the crucial part of
the interview, and I think technical explanation is an important skill.

That said, it may be a flawed practice. I'm open to arguments to that effect.
But so is everything else[1]. I'm interested to hear some thoughts.

[1]
[https://en.m.wikipedia.org/wiki/Goodhart's_law](https://en.m.wikipedia.org/wiki/Goodhart's_law)

------
dkasper
100% not ageism. Whiteboarding itself is just a skill to practice. I don’t
pick jobs based on the interview process, I pick the companies I wanted to
join and practice the skills needed to pass the interview. After 10 years in
the industry my whiteboarding was always terrible until my last round of
interviews where I decided to actually focus on it and I passed the interviews
at Facebook and Google. My problem was that I could always solve the problems
but I was too slow without the keyboard and the compiler to help. So I
practiced writing code without those tools and got faster. I think if anything
my experience helped, so I’ve come around on whiteboarding. It’s not perfect,
but any good coder can learn it and the bar is not really that high.

------
jcomis
Same with "culture fit" interviews imo. How people don't think they just
create massive bias is amazing to me.

~~~
pytester
"Not the right culture fit" is pretty much code for "we have reasons we'd like
to reject the candidate which we don't want to go into too much detail about".

The vaguer the reason for rejection the more suspicious I tend to be that it's
at least implicitly related to some sort of shameful prejudice.

~~~
erik_seaberg
Dinging a candidate on culture fit is very rare for me, and basically means "I
think some people would quit to avoid working with this guy."

~~~
pytester
IME when a candidate gets dinged for a reason that would make people quit to
avoid working with him (e.g. "he obviously doesn't shower") then people don't
tend to invoke the words "culture fit".

------
crsv
I do not think white boarding is a cover for ageism.

I think a group collaborative exercise where you're sketching, drawing, or
otherwise visualizing an abstract concept to explain a point, answer a
question, or justify a decision is a skill that talented, effective people can
leverage regularly to get great results at work.

I think testing for this skill is a really good idea.

I think that doing this in a way that's equitable and emotionally supportive
to the candidate takes thoughtfulness and effort, and not every company/person
in this process does this well.

I also think there's a great number of people who turn this concept in to a
boogeyman to rationalize their interpersonal or technical ineffectiveness.

I would use a whiteboard interview to evaluate a candidate (and have), I would
happily submit to a whiteboard interview (and have), and I think that all
things being equal, the noise around them mostly comes from people who perform
poorly on them and if I'm a betting man, a team made up of people who
performed well on an equitable, well structured whiteboarding exercise would
outperform one made of people who did not in the work context of building
software as a team.

------
closeparen
Some of the most impressive whiteboard/coderpad performances I’ve seen have
been from middle aged candidates. When someone has been using a language for
15+ years, their agility and fluency in expressing their algorithmic ideas in
code is incredible. Most candidates seem to understand and articulate a
solution by the end of the interview, but it’s the fluent ones who can prove
it with end to end working code.

------
passwordreset
Whiteboard interviews would be great if they tested the kind of things that we
would do on a whiteboard, namely design and _maybe_ pseudocode. If someone is
interviewing for an algorithm job, I'd expect they could write text in boxes
that might describe how the algorithm works. If someone is interviewing for a
front end position, I'd expect that they could draw some boxes describing the
UI, and depending on the underlying technology maybe add the info on the
containers and subwindows, or describing the MVC model, or high level actions
drawn with arrows that show what gets affected if some button or UI item is
pressed or selected. If someone is being hired for a networking job, then I
might expect to draw up some boxes that show a topology for some scenario and
identify where the security structures might need to be. For a straight-up
programming job, maybe I could see drawing flow charts or sequence diagrams or
something that might actually be useful to draw out. I would certainly not
expect to write code on a whiteboard. That's not what whiteboards are for.

------
jdblair
I've been on both sides of the whiteboard interview (candidate and
interviewer), and I've failed a good number of them. The last one I had as a
candidate was about 4 years ago, incidentally when I was 42 (I did get that
job and I'm still with the same company).

The best whiteboard interview evaluates a candidate for technical skills and
soft skills at the same time. I want to see if candidates ask questions and
can deal successfully with ambiguity as much as knowing the "right" answer. At
the same time I'm asking questions about their previous work, specifically
looking for concrete examples of how they balance the needs of different
stakeholders in a project.

The worst whiteboard interviews look to evaluate knowledge of a specific
algorithm, and don't provide help when the candidate is stuck. The very worst
is just a pretext to cover up the interviewers biases.

In my experience, the right company is out there for you, but as an older
candidate it can take waiting a long time for the right opportunity where you
can highlight the specific skills you've spent your life accumulating.

------
maximente
i wouldn't take it too personally nor read too much into it. the whiteboard
interview wants to extract signal ranging from "make sure this person isn't a
complete n00b/fraud" to really relevant problems that should probably be
eminently doable, depending on role. but due to a variety of factors it
doesn't do this very well. for many the biggest is social pressure where at
least 1 person is completely watching you work, which is stressful if novel or
you're shy. or lack of familiar tooling, or whatever.

yes there are myriad better ways to extract this signal but, as the saying
goes, you get to choose the game you play but not its rules. you've enumerated
one option which is refusing whiteboard interviews, but you could also level
up your whiteboard game without too too much effort. personally i don't think
it's time to reach for malice after 2 failed attempts at something i'm
inferring you haven't done in awhile.

------
jim_barris77
You’re suspicions and frustrations are valid and are based on your experience
alone. No one else here was in those interview rooms with you and if you
subconsciously picked up on the presence of an age bias you probably weren’t
pulling it out of thin air. In my experience in multiple industries as both
interviewer and interviewee I’ve felt similar biases and often had them
inarguably confirmed. And I’m somewhat ashamed to say that I’ve partially
acted on such biases as well in rare cases. Interviewees deserve better
treatment and more transparency, period. No one should have the right to exert
that kind of toxic power dynamic on a fellow professional. I’m 32 in a new
workplace in SF and I can already feel the subtle force of ageism lurking in
the subtext of interactions with coworkers. I appreciated this post, thank you
for speaking out on this. PS I love white-boarding.

------
unoti
There's a basic truth about being a knowledge worker that most people don't
think about. This truth holds for young, old, programmer and non-programmer
alike.

If you want to stay relevant and fresh long term, you need to be continuously
learning. You can get away with not worrying about ongoing learning in the
short term, say 8 years or less, but in the long term it's going to catch up
with you.

This is one key reason programmers tend to move to other careers or into
management after 10+ years: it's a lot of work to continuously learn. And
worse than that, it's uncomfortable and makes you feel dumb when you know
you're really smart and capable. Learning to embrace that feeling of being
dumb, of being a beginner, is key to growth. And once you stop growing and
learning, you start getting old.

For developers this means learning new languages, techniques, technologies,
methodologies. If we accept that this learning is going to be happening, then
it's not too much to ask that data structures and algorithms refreshers are
part of this ongoing learning say 1 out of every 3 or 4 years.

Most engineers actually don't do this, and just stick with what they've been
doing for the most part. Or just happen to passively learn whatever is rolling
by them in the course of doing their job.

For engineering, there are actually tons of things that need to be studied
that are technically not part of the job: writing skills, communication
skills, math skills. Sometimes these things help you even though they're not
part of the daily grind. The same goes for algorithms and data structures.

Studying these things also sends a signal to your interviewer: you're willing
to go figure it out even when it's not fun and not convenient. As a hiring
manager, I like that. And we can debate whether it's a good thing, but it is
what the situation is at many places. Plus, it's fun to study a lot of it, so
it's a good option to get on the learning.

------
rvz
> Whiteboarding simply tests for skills that are not needed nor exercised once
> you're out of uni.

In today's tech industry, these algorithm questions is now used as an effort
to trip up candidates and to always try to "See how you think" in an
unrealistic scenario. The questions I've been given and have seen are mostly
irrelevant and are always done for us in the libraries I use at work.

I had interviewed at one startup in the UK who asked me a algorithm question
that they admitted that they don't use and their excuse is the same: "To see
how you think." Not only this doesn't make sense if one has already seen this
problem, but the fact that they don't use it makes you wonder the real reason
why they are doing this.

The simple answer is: Because it works for FAANG (Who actually do use these
algorithms); Thus everyone else copies them. This is why hiring in this
industry is a complete circus.

> Things like improper syntax and not getting the damned recursive solution
> fast enough.

A problem statement like that is like: `Design and implement the optimal
solution to this 'problem' in X language in less than 15 minutes.`

This is a red flag for you as a candidate who is allowing room for the
interviewer to nit-pick you here to waste your time. It should never be that
important to worry about the specific language semantics here due to the time
limit. But again the interviewer is there to be impressed on how much the
candidate knows about the intricate details of the language + data structure +
algorithms all in 15 minutes which is nonsensical requirements for a typical
software engineering role.

Frankly speaking, the interview dance in the tech-industry is an excuse to
trip up candidates who have not practiced for more than 6-9 months on data
structures and algorithms and the latest tools that everyone is adopting. It
is so 'broken' that interviewing at FAANG companies is an entire industry
itself.

For them, whiteboarding like this is essentially trying to find a silver
needle in the sky.

~~~
twblalock
A lot of teams at FAANG companies don't use those algorithms either.

However, if you want to hire generalist programmers who are good at solving
problems and can work on a variety of projects, it's perfectly reasonable to
want to see how they think.

------
rgbrgb
I've only done whiteboarding in interviews for system diagram type stuff and
explaining high level ideas. At my job, this is mostly what we use the
whiteboards for in day-to-day work. Some people say they built a system, but
when you ask them to draw the boxes and arrows to describe how data flows, it
becomes obvious what pieces (if any) they actually touched. I think the people
who do best in these are either more senior in their careers or have done a
lot of side-projects from scratch. They have either seen a system evolve over
time and solved scaling bottlenecks or they've set up many systems with a few
different stacks and have thought about what the pieces are for.

------
ebiester
It depends. If you're talking about whiteboarding code, I only have to do that
once a year or so, usually because I'm in a meeting and want to demonstrate
what I mean and code is easier. If you're talking about whiteboarding a
design, I do that much more frequently. I prefer a pair programming exercise
in this case, but I've reverted to whiteboard in cases where there were
technical issues. It's not my favorite but neither is trying to do it in a
text editor without support.

I see nothing wrong in having to show a high level design of a system as a
senior engineer, because we are asked to do that quite often.

------
jasonmcaffee
I'm older as well, but I usually ask my candidates to use the whiteboard to
workout solutions. It demonstrates that you can communicate effectively, as
well as think on your feet :) I don't think it should be all about coding
riddles, but I also don't think you should be surprised by them.

As a developer, I've always used whiteboarding as a way to communicate ideas,
architecture, etc. There have been whiteboards in every office of every
company I've worked at.

I'd say somewhere around 75% of all interviews I've had for positions at other
companies have included whiteboarding.

------
jmull
I don’t see ageism in it.

If you’re, say, six years out of school you are still quite young but your
school skills that might give you an advantage at a whiteboard will be pretty
damn rusty.

Interviews in general are not really “fair” since the employer really has no
way to get out of a short meeting (or series of short meetings) what they
really want to know.

Given that it isn’t possible to have reasonable certainty and the massive cost
of being wrong, a strategy of erring on the side of rejecting good candidates
rather than accepting poor candidates isn’t unreasonable as long as you feel
your pool of candidates is rich enough.

------
xvedejas
I'm young and have also been turned down often due to whiteboard interviews.
What surprises me is that you were only rejected twice in a few months. I had
to go through many, many more rejections than that much quicker than that
before I found a good fit. Don't assume these interviews favor young people,
it certainly didn't feel like that to me. I think most places just want to
reject most people, because it's easier to justify rejecting someone good than
accepting someone bad.

------
blunte
I'm going through this right now, with 26 years of professional experience and
an undergrad degree in CompSci.

There are many problems with hiring. Many. And as with standardized testing in
public schools, one problem is how to judge the capability of many people
(applicants, in this case) in a reasonable time, ESPECIALLY when the judges
may not be experts in all relevant topics. The popular answer is to test
against standards that are easy to measure. In the end, the companies may end
up with fewer false positives (hiring an idiot), but will accept the
likelihood of having more false negatives (missing out on a good employee).

I don't agree with this approach, but mainly because of more a fundamental
reason. The #1 reason that most hiring is broken nowadays is that it focuses
on specific skills (often an unlikely/unrealistic laundry-list of
technologies) rather than focusing on the candidate's ability to learn, think,
and communicate.

Regarding filtering out older candidates, this is more a side effect of
testing on topics that would be more familiar to more recent grads. Likewise,
if interviews included demonstrating how a candidate would choose between C#,
Python, Ruby, Go, C++, Java, or Javascript for a given fantasy scenario, or
when to choose between bare metal servers onsite or virtualized hardware
onsite or managed or unmanaged cloud resources, younger and less experienced
candidates would fail more than older ones. They just don't have enough
experiences in different situations to know how to make these decisions (with
an reasoning to back them up).

The practical reality that I see is that older developers just may not be
worth the extra cost compared to younger, less experienced ones. This will be
especially true in many corporate environments where the more experienced,
more senior dev will have higher expectations, want more authority and
autonomy, and otherwise feel stymied by corporate drag. If the older worker
hasn't ascended into management, they have little road left to travel.

What many of us older devs didn't realize is the situation we would now be in.
At this point, we must forge our own paths - by starting a consulting
business, forming a startup, building a SaaS or other income-generating
product, etc. It does little good to be angry at the system (since our
complaints will absolutely not change anything).

------
tw1010
I buy this. But then again, why go through all the trouble? They can just
reject you once they see how old you are (and blame something else or not tell
you at all).

------
scarface74
I’m 45, had dozens of interviews in the last 10 years, only one or two
rejections and 5 jobs. I am a developer and haven’t had anything resembling a
white board interview.

For the job I have now, I was hired as a developer but never actually had any
development related questions besides asking about my previous projects and
architectural decisions. I also don’t live anywhere near Silicon Valley and
mostly worked at your standard Enterprise shops.

~~~
zerogvt
Can you please contribute the names of these companies to
[https://github.com/poteto/hiring-without-
whiteboards](https://github.com/poteto/hiring-without-whiteboards) You'd make
me and a lot other people a big big favor. Thanks a mil.

~~~
scarface74
I can tell you that it’s every company I’ve interviewed with in Atlanta for
the last 20 years.

------
II2II
Anyone can crash and burn in a situation like that, particularly since it
sounds like they are putting too much emphasis on the wrong things. I have had
a couple of interviewers go back to the question and ask how I would approach
it in a more realistic setting, meaning that they were more interest in
process than the solution. Unfortunately, that was the exception rather than
the rule.

------
jdauriemma
If we stipulate that whiteboard interviews might be useful for evaluating
candidates in some cases, a good whiteboard interview would have specific
criteria expressed in some sort of rubric or other document. That document
would be shared with the candidate and evaluator(s) in advance of the
interview. This ensures that the candidate and evaluators have a shared notion
of what constitutes success before the interview. An opaque process,
unfortunately, can cultivate the type of suspicion that you're expressing
here. It sounds like your whiteboard interviews did not give you a good sense
of the types of skills they were looking to evaluate during the interview.

I think it's great that you have such high self-esteem and aren't doubting
yourself just because some other people don't see your value. That said, I
think more data is needed before concluding that whiteboard interviews in
general are tantamount to an age filter.

Edit: please note that I have said "if we stipulate," not "if we accept as an
a priori truth" that whiteboard interviews are good. It's simply a rhetorical
device for evaluating whether or not your whiteboard interview is at risk for
evaluator bias.

~~~
Kapura
This is a ridiculous position to take. The amount of code that I have to write
on a whiteboard to successfully do my job as an engineer is shockingly close
to nil. The very notion of having a whiteboard section for a programming job
is insane.

You wouldn't expect a driver's test to include a significant oral portion,
where the drivers spend an hour describing how they would parallel park. A
whiteboard interview makes just as much sense, regardless if you're sharing a
rubric.

~~~
twblalock
Whether or not whiteboard interviews make sense for programmers is a different
question than whether or not they are intended as an age filter.

~~~
Kapura
If there is a portion of a programming interview that doesn't make sense for
programmers; but the results of this section skew the results of the interview
highly towards recent college graduates, what would you say is going on?

~~~
jdauriemma
I think you're addressing a symptom, not a problem. When any candidate
evaluation process is opaque, you invite bias into the process. Whether
whiteboard interviews are useful or not is subject to debate (it's not a
factual statement that whiteboard interviews are universally bad). Whether a
whiteboard interview is done fairly and without bias is a different
proposition altogether, and the interviewers can do a lot in order to address
this concern.

------
davidw
I'm a bit older than you, and am really wary and tired of lame interview stuff
too.

------
kleer001
IMHO two samples isn't quite enough to form useful data. It's a rough trend,
certainly, but more tests are needed to be sure.

Could be you dodged a bullet. Could be the interviewers were hungry. Could be
they didn't like your clothes.

42 is not that old.

~~~
mrhappyunhappy
Could be his attitude. The older we get, the more rigid we come across. I know
I personally put up with a lot less shit than I used to, hence why I doubt
many would want to work with me - and that’s fine by me.

------
mars4rp
This is a discrimination issue, and this thread is full of comments about
people that have not been discriminated against. good for you, but it doesn't
mean the problem doesn't exist.

------
JMTQp8lwXL
I think leetcoding has become the norm to increase the friction when
considering new job opportunities and keep wages lower. It incentivizes people
to cut down on job hopping.

~~~
esoterica
That makes zero sense. Companies may want to increase friction for people
leaving them but they want to DECREASE friction for people joining them. Using
white boarding as part of your recruiting process would increase friction in
the wrong direction.

~~~
JMTQp8lwXL
If everyone uses whiteboards and leetcode, existing employers win. Now, I'm
less incentivized to join $NEW_FANG because I have other obligations in life
and can't commit to that much leetcode. On second thought, it does lead into
the OP's point: it seems like a legal proxy for age discrimination. New grads,
which will work for less and offer no experience (beyond internships), will
have more aptitude for leetcode-style assessment.

~~~
esoterica
Read my comment again. White boarding increases friction in the wrong
direction. Companies make decisions to benefit themselves, not the industry as
a whole.

Also hiring people who are willing to work for less money is not age
discrimination.

------
rolltiide
Literally only college grads are marginally good at that. Nobody likes
whiteboard interviews and has to brush up. Everyone knows tech interviews are
inefficient.

2nd interview in a few months you were rejected? The only ageism here is that
you probably dont have time to interview at the number of companies that your
competition does. Last time I interviewed I did 16 interviews in one month at
probably a dozen companies, received 2 offers. There are some blogs posted
here where people talk about doing many many more than that.

I would say whiteboards suck but no not the ageism you are looking for.

------
netik
You’re giving zero details here aside from “i failed the whiteboard interview
and it was horrible”

What happened?

Maybe it’s you.

------
username90
Most juniors fails white-boarding as well, so we can assume that most seniors
would fail whiteboard interviews when they were young as well. So I think this
isn't ageism, just people with lots of experience who don't want to admit that
they weren't the top X% of their cohort. Of course it is easy to believe you
could have passed them back then due to the Dunning Kruger and the "Good Old
days" effect, but that doesn't mean that it is true.

If your argument is that you barely passed those interviews a decade ago and
it takes too much energy to practice again, then I'll say it is a feature. The
more we discourage less capable people from joining the better, don't you
agree?

Of course this all assumes that white-boarding is a good indicator, but the
companies administrating them has pretty good statistics that they work. Also
it doesn't have to be on a white board, at least Google lets you write on a
Chromebook since a few years back. The important part is that the candidate
has to solve and code a non-trivial problem not available in public (meaning
they can't have seen it before).

------
netik
You’re giving zero context here aside from “there was a whiteboard and it was
horrible.”

What happened?

Age has nothing to do with it - if you can’t communicate.

~~~
zerogvt
I've already said way more than I should considering I need to stay in this
business for a good few more years. Communication was fine if that's what
you're asking.

------
cr0sh
I'm a bit older than OP - just recently turned 46. I've been a software
engineer (professionally) since I was 18 years old when I was first hired by a
small mom-n-pop shop.

One would think I could simply plop my resume down, do an in-person interview,
show a bit of code I've written in the past, plus my github, and that'd be
enough. Alas, it isn't.

I've had good interviews that used a whiteboard, and bad ones that did.
Overall, though, I detest whiteboard "challenges" and I specifically avoid
them. Currently, with my use of recruiters, I tell them specifically not to
send me to such interviews if they use a whiteboard (it would have to be
something really unique for me to consider it - maybe for a ground-floor
startup opp, or something in robotics or AI, etc).

The best interview I had that used a whiteboard was basically where they asked
me to write fizzbuzz whiteboard style. Whenever I am given such a task (ie -
write code), I ask the interviewer if they mind if I use "pseudocode" \- just
to get the whole "wrong syntax or keyword" issue out of the way. I've never
had a turn-down from this ask. I liked that they wanted me to show I could do
fizzbuzz "from memory" because it would show I wasn't copying/pasting from
that github repo of "all versions of fizzbuzz", and it would also show I had
some idea about programming. After that, and the in-person portion of the
interview, they gave me a take-home challenge to write some piece of small
software (IIRC, it was a random-number dice game or something), and upload it
to their system for evaluation. I actually ended up getting an offer of a
position from that job, but I ended up taking a different position with
another company.

The worst whiteboard interview I had, though, felt like a complete grilling
session. It started off reasonable enough; ushered into a large conference
room, and I was questioned by a couple of programmers on their team, plus
their hiring manager. All seemed ok. They asked me to do some whiteboard work
- some SQL coding IIRC, among other things - all was going ok as I was writing
down an answer, but every time I turned around to the interviewers - there
were more people in the room. By the end of it all, it felt like the entire
staff of the company was in that room and nobody was out doing their job. Had
to be 20 or 30 people in there. To be honest, it rattled me - mainly because
it was so odd.

I didn't get an offer on that job - and to this day, I am glad I didn't. While
the company and the office location all had a "hip and upcoming" startup-like
vibe, plus open-office floor plan, etc - at the same time, I wondered why they
had such a large SWE team (10+ people from what I recall) for what was
essentially a basic PHP CRUD application.

It was interesting to note OP's idea of it being a potential age filter; I'm
not sure I agree with that fully. I wonder if it isn't meant as more of a
filter for those who didn't go to school to learn the craft. I mean, I've
probably done at least once certain things being asked for - but if they couch
them in terms that are "defined in the literature" (this also covers asking
about "patterns") - I'll most likely be lost. Because I don't know all of that
terminology, or what it applies to. I've been coding in some fashion or
another since I was 10 years old, but I haven't gone to school for it (aside
from a couple of community college classes for C/C++ - algorithms and/or
patterns were not discussed).

If so, it's kinda on them because they didn't read my resume carefully; I note
up-front that I don't have that education, that I am a self-learner, and that
I don't like to be a "specialist" in a particular language or framework-du-
jour. Rather, I'm a business problem solver - the ultimate choice of how that
problem is solved is an implementation detail that has only a certain bearing
on the problem solution. Mainly, it's better to come up with a solution and
then choose a language for the specifics of that solution that will work to
implement it. 9/10 times you don't need the latest language or framework for
most problems. It's more knowing when you do, rather than just picking one and
sticking with it forever (ie - I don't want to become someone mired in only
using and knowing COBOL). Likely, any problems that crop up in a solution tend
to do with how the solution was implemented, not what language/framework it
was implemented in.

Lastly - something I have noted post-interview is the fact that seemingly none
of the potential employers care to contact or do contact any references you
give them. You can ask them if they want/need references, but even those that
do, never follow up on them. I am not sure why this doesn't happen - maybe
it's just a simple constraint of time vs number of resumes/interviews? Or
maybe it's due to past candidates gaming the system, and making it an
unreliable metric to the process?

------
wellpast
This is an interesting take. I'm in my forties, will/hope to be a direct tech
contributor for my full career, and definitely make sure to prepare well for
whiteboard interviews. I find them fun to a degree, and I used to nail them in
my youth...and still do well...

Still, the ageism take is interesting but I don't like falling back to that
kind of thinking b/c it is counterproductive.

The evolution of my own performance in whiteboard interviews (and anecdotally
what I've heard from other experienced developers) is interesting:

I don't feel like it is directly due to age or cognitive change/decline, but
more to do with mastery/experience.

As you get more experienced in this craft (as with others), one of the most
important skills you learn is navigating _context_. After solving real world
problems repeatedly, you move further away from the aseptic environs of
academia/learning and find that prioritization and contextual understanding is
far more important to superior execution.

More explanation...

I was in an interview recently and got the typical line of puzzle coding
questions. These puzzle questions are completely denuded of context (which is
irritable to a professional practitioner). Or, rather, the context becomes not
to solve a problem with a given set of _outcome_ constraints (real world) ...
but solve a problem and try to guess what the interviewer's particular
fetishes are and try to hit those.

Do you get the impression the interviewer has a fetish for OO solutions? You
better angle on that or your going to get the ding. Do they want to see you
pull out a cool data structure like a min heap? You better realize that right
away and get there. Generally speaking, you can "win" in these types of
interviews if you angle for big-O optimality (I've found).

I've interviewed this way, myself. But over time -- with experience -- I've
found that this doesn't really even correlate that well with outcome. I've
interviewed and worked with people that absolutely nail these whiteboard
problems but when you get them on the job, and with real world curveballs
thrown at them, they freeze - either due to some issue of work ethic,
psychological issue/fear, or in the absence of _grades_ they just can't seem
to make a move.

What I've found is interviewing with just a Q & A style response and digging
into the work they've done and finding out how much ownership they have taken
in their past work, how much curiosity they show (for any given piece of tech,
just ask and see how well they know it and can even teach it to you if you
don't know it), how much drive they have to get things not just done, but get
them done well/solidly. Then, pretty quickly I can tell you if we've got a
good hire.

Conversely I've made hires where the candidate did not do so well in the
whiteboard but proceeded to excel in the professional context.

Think about this: if you have a person that is curious and drives to build the
thing well... imagine the day (and these days come but not so often) that they
encounter some need for a difficult algorithm. What is this conscientious
person going to do? They're not going wing it and write a bad solution. They
are going to go do their due diligence, their research, consult with their
team members, and they'll get the right solution. So, say they are not so
great with coming up with a novel algo on their own. One, that's a skill they
can develop, but two -- it's a skill that's only needed in a few people on
your team and then you'll overcome those steps at the intermittent times that
they come through.

Now of course this ^ way of interviewing requires a personal skillset in one's
self -- that is, you have to have a good work ethic, be intensely curious,
very responsible, etc in order to recognize these same qualities in the
candidate.

Unfortunately, I've found the industry dominates with "smart people" but who
tend toward what I call a 'philistinic' position. They lean way too much on
their natural intelligence and use that as an excuse to not really grow their
skillset. This is what some people call 'expert beginners' and there are far
more of these, ime, than truly skilled practitioners.

So -- back to the ageism thing. I think it's less ageism and more an overall
industry deficit. If we understood our work better and could produce more
masters/professionals then I'd think we'd see an increased valuing of
experience.

Blaming it on ageism I think only deters us from getting there.

------
dlphn___xyz
Why are you still applying to entry level dev roles at 42? Do you have a
portfolio?

~~~
tomalpha
I'm around this age and haven't applied for entry-level dev roles since I was
truly an entry level candidate.

I've endured whiteboard sessions for every role I've gone for.

~~~
dlphn___xyz
shouldn’t you have built up a body of work that conveys your level of
knowledge so you dont have to endure these assessments?

------
brador
If it was trivial you would have completed the exercises, no?

Truth is you're using age and "years coded" as a cover for competency. Hit the
books, refresh your knowledge stack. There's no shame in improving.

~~~
jerf
I'm 40. As it happens I like Haskell and I've spent some time with it, and I
expect I could get through most recursion interview tests, so this is not sour
grapes on my part, but: I really can see just how easily my career and hobbies
could have turned so I would be a good developer that should pass interviews,
but stumble and fall when trying to write a recursive version of some
algorithm.

(I'd add that in practice, almost nobody ever _directly_ writes a recursive
version of anything anymore. You should generally be using combinators like
map and filter and the crazier stuff Haskell provides rather than directly
writing recursion schemes by hand. It does happen in Haskell for a couple of
specific cases, but even the ones I can think of are exceptional cases for
dealing with certain optimizer corner cases, not places where it was
absolutely necessary to write direct recursive code. Even for a pure-FP job I
wouldn't hammer on it in an interview; I'd want to very rapidly move up the
stack to more interesting and relevant questions in our precious interview
time. I suppose it's an integration testing approach to interviews rather than
unit testing; I'd rather find something where recursion is used in passing to
ensure that you've got it than sit there and pound on that specifically. It's
not a good interview question unless that's all your interviewee can handle.)

------
27182818284
The whiteboard threads are always interesting to me because with more than ten
years experience in software development in enterprise and startups now, I've
never had to do a whiteboard interview.

Are they common outside the big six names? I.e., outside of Facebook, Google,
Apple, Microsoft, Amazon, and Netflix? I wonder what the actual percentage of
"Needed to pass a whiteboard-based Q&A to get a salaried position" is.

From my viewpoint, having never run in to them, they seem like something that
was much more popular in the past, but now rarely used or only used at the
aforementioned big six companies.

~~~
luc4sdreyer
In the 2019 Stack Overflow developer survey, 27.8% of respondents said they
encountered whiteboarding as part of their last successful interview process
that resulted in a job offer.

[https://insights.stackoverflow.com/survey/2019#work-_-
interv...](https://insights.stackoverflow.com/survey/2019#work-_-interview-
practices)

~~~
27182818284
Oh cool, thanks for the link! I should have thought to look at SO, as I
generally read those survey results, but it didn't occur to me to look for
this question there. 28% is a bit higher than I would have guessed even to
that answer.

