
Hiring Is Broken: What Do Developers Say About Technical Interviews? - chrisparnin
https://medium.com/@gameweld/hiring-is-broken-what-do-developers-say-about-technical-interviews-21821141ca71
======
duxup
For me they feel like trivia.

Personally, I'm terrible at coding trivia.

I'm better with lots of context and what an application is supposed to "do",
what problems it is intended to solve in a larger context, and how I can solve
them. Personally I've done far better with take home type assignments as I
like to sit down, think about things, and write out a couple solutions and
think about it.

------
davismwfl
What still dumbfounds me is we went through this in the dot com days (late
90's early 00's), and I admit to being a contributor to the stupidity but we
learned better ways 20 years ago. Back then we figured out we were excluding
great candidates that had the experience we needed just because they could not
answer some algorithm questions that they were likely never going to deal with
anyway.

I even remember one of the places I was at had put me in a consulting
development role initially because for their product development roles they
were still using these insane interview algorithm questions. Yet, it was
myself and another experienced engineer on the consulting side that were
excluded from product development initially that found and fixed race
conditions in their core product causing a major website and system to crash
hourly. All the fancy algorithms those guys could repeat and implement from
memory but none of that helped them fix a real world problem.

My own theory is that so many startups like this interview methodology because
they themselves are so fresh out of school they feel an exam style interview
is good because they lack the skills to evaluate anyone in another fashion.
What they are missing is that the person who wants to write known algorithms
from scratch is likely the worst person to help you get your product to
market. That person will waste a ton of time on problems that can honestly be
neat/fun to solve but have no bearing on getting to market and making money.

To be clear, I feel algorithms are a big part of our jobs, but for 90% of the
startups and small business in general, their first job is get a product to
market, not recreate the wheel. And for the vast majority of time our
"algorithm" knowledge is spent selecting the proper algorithms not being able
to write them from scratch out of memory. This is why I focus my interviews
with candidates on solving problems WITH me, but I use real world problems and
I don't care if they can write out the algorithm, I care they know what the
issue is, where to look and how they'd go about solving it. The process they
use it FAR more important than what they remember from school or studying to
pass an interview. That doesn't mean I won't ask them coding questions or how
to do something, but I care about process more then a perfect answer.

And sorry, but people with experience and families don't have the time to
spend doing 10-20 take home problems for different employers when applying for
a position. It is one of the most insane things to me, you are asking someone
to spend hours of time on a problem with low relevance that in the end means
that the candidate has to either take time away from their job (which if they
do they aren't a great candidate IMO) or they have to sacrifice significant
personal time which if they have a family is hard to do. So you are rewarding
a specific group of candidates (typically young & single) and not necessarily
finding the "best" candidate for the position.

My last bit of rant. Take home "tests" are one of the most lazy and
disrespectful things you can do to a candidate. It is the equivalent of saying
you aren't important enough for me to take time speaking with unless you can
jump this high. And the bar is set as if all candidates are 24 year old males
who have been running track their whole life. Experienced candidates have
families, have experiences which are far more valuable than your "jump this
high" test. Take the time, work through a problem or two with the person, this
also tells you if the person works well with you and the team. If they don't,
no matter how smart they are they are a bad hire.

