http://www.phparch.com \ December 2018 \ 43Education Station
Interview Coding Challengesmaterial—a scenario working
programmers say is demoralizing
and an unrealistic test of actual
ability.David Heinemeier Hansson^5 , the
creator of Ruby on Rails, describes
the process as “whiteboard algorithm
hazing.”
Max Howell^6 adds, “Google: 90%
of our engineers use the software you
wrote (Homebrew), but you can’t invert
a binary tree on a whiteboard so f– off.”
I recall someone else in that discus-
sion mentioning regularly looking up
material in books they wrote.
How does this elitist whiteboard
hazing work against people? It selects
for recent college graduates who have
studied-up on these algorithms. It
works against people with real-world
experience who have been writing soft-
ware for a decade or four. It also works
against people who didn’t receive a
costly education.
Aline Lerner, in You can’t fix diver-
sity in tech without fixing the technical
interview^7 provides actual charts show-
ing ways this process adversely impacts
diverse groups. She explains the process,
statistically, proves to be non-deter-
ministic. Interviewees can’t tell how
they did; results are arbitrary. Imposter
syndrome kicks in, and those most
susceptible stop interviewing at all.
At the end of the day, because
technical interviewing is indeed
a game, like all games, it takes prac-
tice to improve. However, unless
you’ve been socialized to expect and
prepare for the game-like aspect of
the experience, it’s not something
that you can necessarily intuit.
Also, if you go into your interviews
expecting them to be indicative of
your aptitude at the job, which is,
at the outset, not an unreasonable5 David Heinemeier Hansson:
https://twitter.com/DHH
6 Max Howell: https://twitter.com/mxcl
7 You can’t fix diversity in tech with-
out fixing the technical interview:
http://wp.me/p6TMTl-dA
assumption, you will be crushed the
first time you crash and burn. But
the process isn’t a great or predict-
able indicator of your aptitude. On
top of that, you likely can’t tell how
you’re doing even when you do well.Aline also explains the origin of
puzzles in software developer inter-
views. Fortunately, I’ve not seen such
puzzles lately, but ten years ago I was
passed a wood-and-string puzzle
during an interview. We continued
talking. I soon passed it back, taken
apart (i.e., solved). The interview team
was surprised and said none of their
other candidates had solved it. I didn’t
mention I’d seen and solved it before.
What do I conclude from solving a
wooden puzzle during a software devel-
opment interview? When you get lucky,
don’t let on it was luck; let the inter-
viewers draw their own conclusions!Sample Project
Brandon Savage in Why Coding Tests
Are A Bad Interview Technique^8 explains
why “required projects” are such a diffi-
cult hurdle.
When you’re looking for a new
position, and each position wants you
to create a fully-working application
requiring 8-40 hours of development
time, that’s an unfair burden. Nobody
has time for five such projects when
applying to five positions, and anyone
working full time won’t likely have time
for even one.
Savage suggests having a code port-
folio and offering to provide samples.
Many people use contributions to open
source project as their samples; I use my
php[architect] articles as my portfolio.
Eli White wrote about Interviewing
Programmers^9 explains the interview
process for a senior candidate should
be far different from that for a junior
candidate. “Asking a coding test of
junior programmers is a GREAT tool
for helping to evaluate them.”8 Why Coding Tests Are A Bad Interview
Technique: https://wp.me/prN4Z-f0
9 Interviewing Programmers:
https://wp.me/p26bB-1CHowever, he suggests a different
thought process for considering senior
developers:Someone who is “senior enough”
(use your own definition) should
have their experience speak for
them enough so that there is no
reason to ask for a code sample, let
alone giving them a coding test.
Typically looking at their experience
and asking them a number of prob-
ing questions about their experience
should rapidly inform you if they
know what they are talking about.Joel Spolsky, in the Joel on Software
Guerilla Guide to Interviewing^10 writes:Serge Lang, a math professor at
Yale, used to give his Calculus
students a fairly simple algebra
problem on the first day of classes,
one which almost everyone could
solve, but some of them solved it as
quickly as they could write while
others took a while, and Profes-
sor Lang claimed that all of the
students who solved the problem
as quickly as they could write
would get an A in the Calculus
course, and all the others wouldn’t.
The speed with which they solved
a simple algebra problem was as
good a predictor of the final grade
in Calculus as a whole semester of
homework, tests, midterms, and a
final.I do suspect that “solution speed” has
a lot to do with success in those job
interviews. The interviewer only wants
to know if you find the challenge easy
or not. The challenge is intended to be
easy for the right candidate.
Let’s talk about how to be that “right
candidate.”My Approach
Regardless of what’s right or wrong,
these are the type of coding challenges
I’ve had presented at job interviews10 Guerilla Guide to Interviewing:
https://wp.me/p83KNI-eP