
I don’t have time for coding challenges - PretzelFisch
https://css-irl.info/why-i-dont-have-time-for-your-coding-challenge/
======
autarch
> "I’m writing this as an interviewee, having never been on the other side of
> the interview table ..."

> ...

> "Most candidates will have side-projects or work they’ve done for previous
> employers."

As someone who has actually done a lot of interviewing, I can say with great
confidence that this is simply wrong. At my current employer, we have a
"homework assignment" as part of the interview process. We tell candidates
that they can point us at an existing project of theirs instead of doing the
homework. Few people take us up on this because few applicants have any
substantial public side projects or FOSS work they can share.

And sharing "work they've done for previous employers" is a great way to court
legal trouble. They shouldn't share it and as an interviewer I don't want to
see it!

~~~
johnfn
Them: "We've got a coding challenge for you..."

Me: "I've got this repo on Github with millions of downloads and 10k stars.
It's at least 20k lines of my own code. Would that be good to demonstrate my
coding ability?"

Them: "Haha, no, that'd be too much work for us. Please do the test instead."

Me: "Fine."

Then they rejected me because I used GET instead of POST. Clearly that shows I
have no idea how to code.

That was a large (1000+ employee) YC company, by the way.

~~~
golergka
> Then they rejected me because I used GET instead of POST.

OK, I'm honestly curious here. What was the request, and why did you make such
a decision? Do you think it is the right approach in this case, or that it's
an insignificant mistake that does not represent a person's understanding of
HTTP protocol?

I remember hearing about at least one story where using GET instead of POST
lead to disastrous consequences, as some robot crawled all over the "delete"
links - but I have to admit, I can't imagine how it would happen without other
significant design flaws happening as well (as "delete" links being public or
robot being able to crawl under authenticated user's identity). This sounds
like an error that can cause irrational irritation by the reviewer, but I
can't imagine it being the sole reason to decide that the author can't code.

~~~
johnfn
I was definitely in the wrong about GET/POST. The company I had previously
worked for simply didn't really care too much about getting the verbs right,
so I didn't really fret about them. And the company I'm currently at (multiple
thousands of employees, strong engineering culture if I dare say so myself)
just does everything as a POST. So it really is somewhat cultural whether you
care about GET/POST or not.

But, IMO, even if you don't know, it's the kind of thing you learn once in
code review and then don't worry about again.

~~~
cameronh90
For E2E encrypted APIs, one could well argue that worrying about HTTP verbs is
just wasting time for no good reason. POST (consistently) lets you attach a
body too.

Just using POST for everything is a pattern I've seen becoming more popular
recently.

~~~
chrisandchris
No we can get into an endless argument whether verbs are abused or not...

IMHO, GET (as of today) gas the issue that it does not support a body. If I‘m
executing a search (an idempodent action), how can I nicely pass a JSON object
configuring the search? I‘ll just use POST for that... So then we‘re at the
point where the url does not work anymore because we have a POST
/findEmployee; POST /findContract; ... instead of GET /employee and GET
/contract.

Maybe I‘m wrong here, but it doesn‘t like nice in my eyes using POST in that
way.

~~~
ulucs
The JS API's I used to develop in used a mix of query strings (for exact
matches) mixed with JSON (for more complicated queries) all in the url
parameters

------
ergocoder
Then, don't.

I want to move from my 2000 USD a month (this is a good salary already) in a
3rd world country to a FAANG that pays 20k USD per month.

I'm willing to go through any challenge because the reward is superb for me.

Not to mention, without objective interview questions, an introverted non-
native English speaker (who doesn't speak latin-germanic-based language) like
me would fail most of these subjective questions (e.g. bad culture fit, can't
articulate as well as a native speaker).

I like coding challenges. Please do more.

~~~
frequentnapper
I don't know of any software company that would hire an introverted person who
can't articulate themselves for 20k a month. This is how micro-service
architected fully optimized solutions that solve the wrong problem happen. Do
you really think the high value of a developer just comes from being able to
pass coding challenges when there's millions of them out there?

~~~
tick_tock_tick
That's only 240k probably not for a base salary but total comp sure.

~~~
duutfhhh
Well, I have a bridge to sell you if you believe it's total comp.

~~~
nilkn
That's perfectly in line with expectations for a new inexperienced hire at a
FAANG. If anything, it's a little high for entry-level even at these
companies. Obviously much higher numbers are attainable via career progression
or already having such a job to negotiate from as leverage.

------
mayoff
You're complaining that, to get a job, you have to demonstrate your ability to
do the job, in a standardized way so the employer can compare you to other
candidates with the merest hint of objectivity.

For a little (imperfect) contrast, here's a quote from an article about
auditioning for the Baltimore Symphony:

> In the audition I took in October of 2014 for the Baltimore Symphony, I
> began preparing the required audition list in August.

[http://www.bsomusicians.org/public_html/so-you-want-to-
audit...](http://www.bsomusicians.org/public_html/so-you-want-to-audition-for-
a-professional-orchestra/)

~~~
lhorie
> so the employer can compare

And why do we think this is objective? Ostensibly, the first one to clear some
threshold of competence ought to be good enough to be hired (in fact there's
even extensively studied algorithms[1] for this stuff). In the vast majority
of cases, it's highly unlikely that you're going to find an underpriced genius
via some misguided notion of test standardization.

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

~~~
username90
Big companies aren't looking for underpriced geniuses. Standardized hiring is
like index funds, many argue they can get better results by hand picking
stocks but index funds still tend to outperform managed investing unless you
are really really good at it. In a big company the people doing the hiring
will be mediocre at it, so you need a process they wont screw up.

------
52-6F-62
I'm of the opinion that if there needs to be some objective technical
challenge to determine a baseline of competency (and there are very many, very
strong arguments for that) then there need to be standards.

I've encountered so many variables (no pun intended) in technical interviews
that I've virtually stopped preparing. There's hardly any way _to_ prepare
when the field is so large and you never really know what you're going to be
tested on.

I've had people challenge me on theoretical system-time timezone conversions
(and incorrectly mark my correct answer wrong "because of physics"...), beside
reimplementing native JavaScript functions, beside complex algorithmic
problems, beside toy problems like building a binary calculator. [That's great
if you learn I can rig a web page for adding 100 and 101, but how do you know
if I know anything about databases for this back end position]

And those interviews were all for working with web tech, in a couple of the
cases just front end positions.

There needs to be a common, limited standard and/or domain-specific standards.

It's really counter-intuitive to me, and I don't understand how it benefits
the hiring process, if a company is looking for a web-back-end engineer for
what is essentially a complex crud app and wants to propose the candidate
solves a problem from a domain they've never worked in—and marking them on the
correctness of the answer, rather than the work process.

I'm for objective, technical challenges. But I've seen enough that it seems
apparent to me that it's broken.

(addendum: I've had several good interviews as well, and good interviewers. I
had a good one recently as well that was fitting for the domain. They're not
all bad, but most seem to be in my experience)

~~~
wry_discontent
I interview a lot of people for frontend positions. I ask one two-sum question
to see if they have some knowledge about data structures and simple
algorithms. Then I ask them to build something trivial in React, which is what
we use. If you can do those things, you're probably fine. The number of people
who can't is truly shocking.

~~~
fractionalhare
I would argue there are many well-qualified frontend engineers who won't
correctly solve the two sum problem on their first time encountering it.

~~~
user5994461
This one? [https://leetcode.com/problems/two-
sum/](https://leetcode.com/problems/two-sum/)

>>> Given an array of integers nums and an integer target, return indices of
the two numbers such that they add up to target. You may assume that each
input would have exactly one solution, and you may not use the same element
twice.

Seems trivial enough to me... except if the interviewer forgets the hard
constraint that there is exactly one solution, then that's a shitstorm of edge
cases.

I'd criticize the problem for asking for the positions of the numbers rather
than the numbers. That's just super annoying for no reason.

~~~
fractionalhare
Does the problem actually have that constraint? If so then yeah it's
significantly easier. I thought the reason you'd have to use a clever
algorithm is because a brute-force solution to find all index pairs would
require n^2 operations, where n is the size of the input array, because you
can't stop after you find a single pair.

~~~
user5994461
Yes it does, you can open the leetcode and see for yourself. That also
explains the "easy" difficulty rating.

I guess you've been giving candidates a more hardcode version of the problem,
not having that constraint?

edit: nevermind, it's the other poster who was giving that problem, not you.
No idea how they formulate it in their interviews.

~~~
fractionalhare
I don't ask candidates these kinds of questions in my interviews. For a coding
interview, I'd normally ask them to implement something like backend rate
limiting logic for an authentication service, and continually ratchet up the
complexity on each successful implementation until the end of the interview.

I was asked the two sum problem in an interview once, but I forget if it had
this constraint or not. This seems much more reasonable.

~~~
zebnyc
Forgive me for my ignorance, but are you looking for anything more complex
than a leaky bucket algorithm + gossip protocol solution?

------
rsweeney21
Work sample tests have been proven repeatedly to be the best predictor of
future job success.[1] The next best predictor is general mental ability.

It's not unreasonable to ask someone to demonstrate their capabilities. Just
make it interesting, relevant to the job and most importantly: short. Whatever
time work sample testing requires should replace interview time, not add on to
it. 2 hours is a reasonable ask. Oh, and you can't ask people to invest time
in a work sample test unless you've already invested a significant amount of
YOUR time on in-person interviews. [2]

screening interview -> coding assignment -> maybe more interviews? = not cool

screening interview -> first round with hiring manager -> coding assignment ->
review assignment with candidate -> maybe more interviews? = cool

Sources:

[1]
[https://www.researchgate.net/publication/232564809_The_Valid...](https://www.researchgate.net/publication/232564809_The_Validity_and_Utility_of_Selection_Methods_in_Personnel_Psychology)

[2] Me. I'm a ex-Netflix software engineer, now run a tech recruiting company
(www.facet.net). I've seen hundreds of technical interview processes across
many industries.

~~~
lapcatsoftware
Tech Sector Job Interviews Assess Anxiety, Not Software Skills
[https://news.ycombinator.com/item?id=23848039](https://news.ycombinator.com/item?id=23848039)

~~~
rsweeney21
The sample size in that study was pretty small.

------
syspec
The proposed solution to me, is much worse.

> Ask them to build something – anything!

> Instead of a coding challenge, ask them to spend a short time building
> something they enjoy, and talk about what they did and why.

To me this would be a MUCH more difficult task. A blank canvas is much harder
to work with, and downright frightening. Constraints foster creativity.

Having everyone code the same thing helps the interviewer (who is also very
busy and has many other things happening in their work life) gauge the
different levels of the people applying easily by comparing them on the same
task.

~~~
cosmotic
The difference is the interviewer is being paid for their time, the
interviewee is not.

~~~
nhooyr
That's a problem with the company. We at @cdr pay interviewee's $200 for their
take home challenges.

~~~
jordan801
This is awesome. I have taken a number of code challenges and walking away
with neither, compensation nor explanation is rough.

------
cosmotic
I've done 5 coding challenges, I deemed each one a success on my end, none
resulted in a job. A few resulted in a third interview which revealed numerous
additional red flags.

At this point I consider a coding challenge a deal breaker. I'm not doing one,
and if you ask, there's a near certain chance I wouldn't want to work in an
environment that thinks they are a good idea.

If you're interested in my abilities, I'd be happy to spend an hour walking
through something I've already worked on in the past.

------
dhairya
I agree that code challenges aren't ideal. But we've been struggling with
parsing resumes and titles to identify the competency of developers. Our
current coding challenge isn't super hard and based on the type of code you'd
see in our product. It asks you to read a simple javascript function, explain
it, and then implement new functionality that can built by refactoring the
existing method. It's about 20 lines of code and 50 lines of documentation.
You can use any IDE that you like.

We've had many candidates that look strong on paper (3+ years of experience,
senior titles, etc) come in and struggle. Struggles ranged from basic code
literacy (think for loop to traverse a nested json object) to basic
programming like writing a function. We've especially noticed this more with
coders coming from purely a javascript and front-end background
(React/Angular, etc). They understand control structures like if/else but
struggle with loops, setting variables, and basic higher level concepts like
breaking a problem into smaller functions.

My philosophy is for junior candidates, any level of competency is ok. Strong
mentoring and experience on job usually can allow anyone to thrive and so you
can prioritize soft skills and culture. But for more advanced roles, I don't
know, it's hard to parse out the quality candidates without having some sort
of technical interview. Definitely would love to hear how other's learning and
experiences.

~~~
geebee
I've heard a variant of this repeatedly. A company justifies technical exam
style interviews on the grounds that many people who look good on paper "can't
code". Meaning, can't program fizz buzz. Can't write a method or function.
Can't write a loop, or an if/else conditional.

But I can do all these things. I've gotten bounced from my interviews because
(this was the official reason, anyway) I didn't get far enough with the coding
in finding all matching subtrees in a binary tree, in 45 minutes, at the
whiteboard.

Companies should feel free to hire based on my ability to do this, they should
not say they were just testing basic things like lists, loops, and
conditionals, or even basic data structures and algorithms like binary trees
or hash maps. These exams go way beyond that.

This may not be the case for all, and it sounds like it is not the case for
your process. But in the broader industry practice, I smell a motte-and-bailey
fallacy here.

~~~
dhairya
In our case our its based on our actual interview experience with candidates.
We've been actively evolving our process and calibrating expectation based on
the candidates that have come in. We've actually simplified the interview
question considerably (as I mentioned the solution doesn't even require you
write new logic, you can refactor existing logic that's provided). But we
still see candidates struggle with the basics.

To be fair this could also be a reflection on our ability to read resumes and
experiences and our initial phone screen. But it is hard. My first job was at
fortune 50 company, you could have the title of senior software engineer and
not write a single line of code as part of your job.

That being said i don't won't diminish your experiences. This is just our
experience from the other side of the table. Also we don't have an HR
department (we're a small startup). The interviews are conducted by engineers
in the company and we try our best to empathize with candidates and be
conscious of creating an interview process that we'd feel comfortable being a
part of as well.

~~~
wendyshu
I don't see how this addresses geebee's point -- what makes you so sure
struggling on programming puzzles implies incompetence on the job?

~~~
dhairya
we're not asking programming puzzles. i described our process above.
struggling to define a function and basic code comprehension (e.g. tracing a
for loop that traverses a json object in candidate's preferred language) is a
strong signal that candidate is not a good fit a mid to senior level for us.
If it was a junior level position, sure you can learn on the job.

~~~
dhairya
in our case, the problem is a highly simplified version of functionality in
our code base and is close to being representative of work they'd be doing if
hired.

i actually don't disagree with the prior poster. Technical interviews are
highly variable and it's frustrating to go through poor interview processes.
I've got bad interview stories as well. Being on the other side of table now,
we're always interested in learning about better approaches hiring. Would love
hear what has worked well for others.

------
JackC
I like the coding challenge we designed for hiring where I work. A few things
about it that work:

\- It's designed to take about the same time as the round of interviews it
replaces (half a day), and we clearly communicate how polished and complete
we're expecting it to (not) be in that time.

\- It's a lot like the actual work; if you enjoy it / are good at it, there's
a good chance you'll enjoy / be good at the job. It helps make sure (on both
sides) that the job is a good fit.

\- But at the same time it's designed to be obviously not actually work we're
going to use; we're not exploiting unpaid labor.

\- There aren't gotchas to it. We review it with an eye toward "if my coworker
showed me something they'd been working on for about this long to address this
problem statement, how would I feel about their work," and do our best to
express that.

\- The rest of the application process takes the challenge into account in a
positive way. I might have a conversation with you later to understand how you
think about the problem you solved, but none of the interviews have to be
gotchas or on-the-fly skills tests because I've already seen the kind of work
you do.

\- Everyone takes the same challenge, and it feels way more fair to discuss
candidates based on reviewing how they do the kind of work that we do,
compared to "X person has a cool open source repo; Y person gave a good
interview answer to this technical question; Z person worked at an interesting
place in the past." There's still some apples to oranges in comparing coding
challenges, but much less than comparing one person's bootcamp group project
open source repo with another person's reason that their best code is closed
source but it sounds cool.

With a well-designed challenge the benefits on the hiring side are really
obvious (we actually have a basis for comparing applicants that feels somewhat
related to the work they're going to do), but also (I hope) we've managed to
make a better process for applicants without expanding the time they're
spending.

~~~
zebnyc
a) Do you compensate folks who take these challenges. Otherwise it is half a
day of unpaid labor. Also most take home tests take way longer even though
they are advertised as "only a couple of hours". Do you have empirical
evidence that it can be completed in the given time slot? Have you given the
test to your own colleagues who may not know the background / domain knowledge
/ environment setup required?

b) Do you make it clear what you consider as "good design"? OOP/Imperative or
Functional coding style? Even in OOP, is it sufficient if the candidate just
does SOLID or do they have to implement GoF patterns? This is very subjective
and never made clear in these tests.

c) Is there a guarantee that an actual person will review the submitted code
and provide feedback? AFAIK, most companies won't give candidates any feedback
/ validation of submitted work

~~~
ProZsolt
Not OP, just a job seeker who like coding interview.

> Otherwise it is half a day of unpaid labor.

The same true for an interview

> Do you have empirical evidence that it can be completed in the given time
> slot?

As a candidate once you see the specification and you think it's not worth it
you can easily can say no to it.

> Is there a guarantee that an actual person will review the submitted code
> and provide feedback? AFAIK, most companies won't give candidates any
> feedback / validation of submitted work

That is why I only willing to do these kind of challenges once I had the first
round of technical interview and I know I would like to work there

~~~
wakawaka1
> Otherwise it is half a day of unpaid labor.

>> The same true for an interview

Who does half day interviews? In my 3 years as a professional software dev,
I've perhaps spent a cumulative 2 hours in interviews with a company. I know
that some companies have extensive interviews. But they aren't as laborious as
intensely grinding on a mentally challenging project in an industry such as
software.

------
ijidak
What I love (sarcasm) is companies that just need basic line of business apps,
but want you to complete a coding challenge navigating graphs and trees in
constant, nlogn time, etc.

I find it hilarious and often ask, "Can you explain to me how solving this
challenge applies to what you do day to day?"

They say.... "That's a really good question..."

Then I watch them squirm as they have no idea how to explain a real world
application beyond a generic, sometimes hard problems come up...

Sure... Then give me an example.

I don't mind taking your test, but if your team doesn't need those skills
you're wasting your time and mine by cargo-culting this time-consuming style
of recruitment.

~~~
cyrux004
how about "we found a strong correlation between who can complete coding
challenge do well on the job. We understand that correlation doesny imply
causation; but we and the majority of the industry havent found anything
better yet. We also understand that we are potentially missing out on good
candidates who dont generally fare well in coding challenge; but thats a trade
off we are ok with"

~~~
pseudalopex
How did you find that correlation?

~~~
cyrux004
Majority of companies including FAANG (not sure about Netflix) do these type
of challenges

------
dataminded
I require them because candidates lie, not always intentionally.

The unfortunate reality is that it can be really tough to fire low-performers.
I NEED to know that a candidate can do the work. We go out of our way to make
our ask reasonable, relevant to the role, not spec-work, not time consuming,
and well defined. It's not uncommon for us to learn that the candidate can't
actually do what their resume says they can or for the candidate to learn that
they grossly overestimate their own skills.

I recently talked to a Python/JS expert that led a project at a major agency
to scrape a network of websites, find and extract specific data, and deliver
game changing competitive intelligence. The candidate ended up admitting that
their role was limited to copying and pasting a pre-built code snippet into
the dev tools console and that they couldn't actually read or write any code.
The proof is in the coding challenge.

~~~
coffeefirst
I find these people reveal themselves almost immediately when we start talking
about their projects in any depth.

------
user5994461
Funny how he starts saying he never had a whiteboard interview and he never
gave an interview, yet he has such strong opinions on everything that's wrong
with it.

edit: read to the end, a lot of the points are absurd, easy to realize after a
couple interviews.

------
jasoneckert
Hiring a bad developer can be a costly mistake. In addition to the costs for
the developer, there are often other costs and productivity lost.

Basically a good coder is not the same as a good developer. Coding is
relatively easy - if you can visualize and solve problems using code, then
you're a good developer. It's the thought process that makes you a good
developer.

Coding challenges are often a good way to test this thought process. I often
require candidates walk me through their code and explain their reasoning
behind everything to see if they'll be valuable on my team.

However, coding challenges are just one way to ascertain someone's thought
process. Watching people work on code during a game jam or hackathon often
gives me an idea of their thought process, as does the advice of other people
I trust who vouch for them.

So, no - coding challenges aren't always necessary. But unless there is a
better way for me to learn whether you're going to be a good developer, then
I'll give you one.

~~~
capkutay
The author's suggestion of a 'trial period' of employment might also be one of
the impractical, costly, infeasible ideas I've ever seen proposed.

So the candidate doesn't want to spend 1 hour on a coding interview because
'they don't have time.' The solution?

Spend a month on-boarding the candidate to your company (taking time from
multiple team members), give them an implicitly high stakes work project while
they get used to the new working environment and production codebase.

Meanwhile there's tension/friction because the company wants to quickly
validate the temporary hire. If it's successful, okay proceed as an employee.
If it's unsuccessful, it's a huge waste of everyone's time, a costly
experiment for the company/team, and likely a very unpleasant 6 week long
working engagement. Then the candidate will have to explain why they only
lasted at their previous employer for 6 weeks in their next set of interviews.

~~~
dvtrn
_The author 's suggestion of a 'trial period' of employment might also be one
of the impractical, costly, infeasible ideas I've ever seen proposed._

Then the world of 1099 IT “technician staffing” and ‘contingency technical
recruiting’ will absolutely horrify you because an entire cottage industry
unto itself is built around this employment model.

It’s especially popular in call-center workforce management.

------
opportune
This person has admittedly never even done a whiteboard interview or given an
interview. Why are we upvoting this drivel to the front page?

Boohoo, you have to spend a couple hours proving you know data structures to
get a new job. Give me a break.

~~~
zebnyc
Let us assume a random candidate Mary who is batting at 20%, i.e., she passes
to the next stage on every 5th attempt. Now if we follow the typical interview
loop

a) Take home test b) Phone screen c) Onsite d) Offer

How many take home tests does Mary have to take to get 1 offer? The answer is
125 and if each is 2 hours then 250 hours. So a single test in isolation may
not seem like a big deal but if every company had their own criteria and take
home exams as a pre-qualifier, the candidate would face a uphill battle to
find work.

~~~
opportune
I mean, my takeaway from that is that Mary is not a very good candidate, not
that there is something broken with the interview process. She only needs so
many interviews because she has a low success rate. Most people aren't doing
nearly that many interviews in an actual job search.

------
lxe
> Have a probationary period

That seems very taxing on the company. I'd rather screen the candidate before
committing to anything via interview/coding challenge, etc... The take-home
coding challenge seems like a good idea -- less pressure than coding during
the interview and allows the interviewer to assess the "real life"
performance.

> Ask them to build something – anything!

That's great, but a big part of working at a company is building something
that you don't like or don't understand well -- talking to stakeholders,
customers, figuring out specs, etc -- something that a good take-home exercise
can assess

~~~
Nbox9
The probationary period seems incredibly stressful for the employee. If I am
currently employed I would never switch to a role that uses a probationary
period as a significant evaluation step because of the risks of leaving my
stable employment, and not passing your probationary period. As an employer I
wouldn’t want to limit my selection to people that either are unemployed or
have a higher personal risk tolerance to handle such situations.

~~~
Lt_Riza_Hawkeye
Exactly. Not to mention younger engineers will probably work 24/7 for 12 weeks
while constantly worrying they could be fired tomorrow because they didn't fix
some bug fast enough.

~~~
ryandrake
Not to mention it eliminates anyone who already has a job from the candidate
pool. No company I know would be OK with you also working full time at another
company simultaneously.

------
djsumdog
I usually tell interviewers I don't do per-interview assignments. I'll often
e-mail them a list of current open source taks I'm working on, a paragraph
with good requirements or a linked issue from an issue tracker. I'll list the
programing language and framework and ask them to select from the list. I'll
complete my task, with tests, and do a full presentation.

Universally I get turned down. "You have to do our assignment." Oh and I'll
usually offer to do their assignment for $300. That doesn't go well either.

Only one company took me up on this offer, and it's the one I work for. (They
didn't even ask me to complete one of my tasks, they just looked at the
project I authored and said that was fine; and scheduled a full interview).

The few times I have actually done these assignments, I've never gotten the
job.

~~~
wendyshu
Their loss.

------
edoceo
This sentiment is too real. And too many folks in "charge" of hiring play this
game.

When I'm hiring, I give applicants a real-code task, something they'd really
do if they were hired - and I pay for their time too.

This method has allowed me to skip a lot of time-suck-bullshit while finding
candidates, and their process with me is easier/faster too.

~~~
syspec
> When I'm hiring, I give applicants a real-code task, something they'd really
> do if they were hired - and I pay for their time too.

Most real code task require a lot of ramp up time to gain context.

------
shock
I think one can be creative about it. Applying the principle "nobody wants to
buy a 2 inch drill bit; what they want is a 2 inch round hole", the people in
the company do not want to give you a coding test, they want to hire a
competent candidate. So convince them you are competent for the job in other
ways if you do not want to spend the time doing the coding challenge.

One way of going about about it is to find former colleagues that work for the
company you are applying to, and ask them to provide references on your
behalf.

------
KevinAiken
I interviewed somewhere that offered 3 options for the technical part of the
interview. The options were a take home assignment, whiteboarding, and walking
the interviewer through a non-proprietary project. I thought that was a great
way to make the interview process more fair.

------
not_real_acct
Time is money.

If you make about $100 an hour, a six hour coding challenge costs you about
$600.

If a potential employer asked you to spend $600 to fly out and see them, _on
your dime,_ would you do it?

I would do it __IF __I desperately needed a job. I did it back during the dot
com crash; I needed a job badly and I was willing to roll the dice.

In 2020? Oh hell no. There's a million companies who are hiring, and an
employer would have to be exceptionally special for me to waste $600 on the
chance they'll hire me.

~~~
autarch
Companies fly people out all the time (well, pre-COVID). They pay for the
travel expenses, but not your time. I personally find this much more of an
imposition than spending a few hours writing some code in the comfort of my
home.

------
60secz
And I don't have time to hire you. You wouldn't hire a visual artist without
seeing their portfolio. I don't hire a software developer until I they can
quickly write a program that compiles read and follow a spec, name variables
well, take feedback and ask relevant questions. To not test candidates for
these skills would be recklessly negligent for my employer.

------
TheCoelacanth
I would never work somewhere that didn't make me write code as part of the
interview process.

I don't want to work with people who are good at bullshitting their way
through interviews, but can't actually write code.

~~~
wool_gather
This is definitely something to consider. I actually once turned down an offer
because I thought their process was too perfunctory. (Along with some other
signs.) I didn't like what it implied about how they saw me as an
employee/resource nor what it implied about my potential teammates. (And since
the process was so minimal I also didn't get much chance to vet the
team/working environment.)

------
wrnr
I freelance, and if asked to do a coding test I'll tell them to pay for my
time, usually they drop the test and contract me right away.

------
dr_orpheus
I think that the coding challenges can be helpful if done correctly. If the
challenge is clearly communicated on how complete they are expecting it to be
and how it might be judged. But I did have an experience with a "homework
assignment" that hit on most of the bad points outlined in the author's
article.

This was not specifically a coding challenge as I was applying for a Systems
Engineering role at a software company. The homework assignment was basically
here is a fake product, please provide a requirements spec, user manual, and
test procedure associated with the product.

My first problem was with the notion of doing the systems engineering
backwards and creating requirements specs from a product.

The second was with the conflicting communication about how much time and
effort should be put in. The actual homework assignment itself said "We
anticipate that this exercise should take no more than a few hours". Whereas
the email I got from the recruiter said "They are looking for extreme detail
here, and the ‘it should only take a few hours’ instruction is kind of BS.
It’s OK if you don’t get it back for a week or so. Winning submissions from my
candidates have been 7 and 11 pages long, I believe. They really want someone
to go overboard with the exercise".

So after putting a lot of work in (because I could, and did not have a family
at the time), the only response I got was basically "Nope, you didn't get the
job". And I know that employers have a lot of candidates and there is a
disproportionate time spent by the employee versus the employer, but it would
have been nice to at least receive 1 or 2 sentences of feedback that may have
helped me in the future.

To a point made by someone further down in the comments, the exercise may be a
good way to judge if you would be a good fit at the company. So based on my
experience I am probably glad I didn't get that job.

------
paledot
My employer carved out a standalone PHP script from a dark corner of a legacy
application years ago. We show it to candidates and talk through what they'd
do differently. I like it because I can judge not just the candidate's
technical competence, but their level as well. If you're a junior, I can see
if you have an eye for detail and pick up on the database query with a syntax
error or mistyped variable name. If you're more senior, you'll tell me about
job queues and workers. I had one candidate start with "the problem is the
management structure that allowed this to happen in the first place". I have
plenty of leading questions for candidates who are hesitant to criticize our
code, and will tear it to pieces in front of them if necessary.

And no, most importantly, it's not a take-home exam.

------
thelazydogsback
As someone who has been programming for 40 years and had a decently successful
career but is struggling with these challenges now, I can empathize.

It's not so much what the challenge is -- it's _how_ one is asked to
accomplish it.

Sitting in front of my laptop for 6 hours while people ask me random
programming tasks while they watch me on camera and see every keystroke on
screen while I'm editing is not how I work. I work by choosing from active
tasks that fit the "space" I'm in, by multi-tasking, etc. - if I get stuck on
something in the "real world" I'll go work on something else that needs to get
done, etc. You'd be amazed at how many interviewers simply _refuse_ to ask you
another question in lieu of or even in addition to the one the first wanted to
ask, for example.

------
quicklime
> Have a probationary period

As someone who's done a lot of interviews, my rule is that letting someone go
during their probationary period is an absolute last resort. It'll never be
used as an excuse to take risks during the interview stage - except in extreme
situations, everything should be decided up front.

This is purely for the benefit of the candidate. Many people quit their old
jobs only after they've received an offer for a new one. Some even have to
uproot their lives (and that of their families) and relocate. Firing someone
during their probationary period for a preventable reason seems negligent. I'd
rather put them under a bit more stress up front during the interview.

~~~
wendyshu
Why not just ask the candidate if they're willing to do a probationary period
rather than deciding for them?

~~~
quicklime
I suspect the type of people I'd need to fire during their probationary period
are the ones who would be desperate enough to say yes to anything during the
pre-offer stage.

Also, firing people isn't something I really enjoy, so even just for selfish
reasons I'd rather avoid it. If it's preventable, I'd rather just get it done
property at the start, rather than take these risks later.

And if it got to it, HR would make my life difficult.

------
hpen
Without having a degree, I feel coding challenges are the only way I can truly
compete.

------
SpicyLemonZest
Many of the author's suggested alternatives clearly fail on the stated reasons
why coding challenges are bad. Asking pertinent questions is clearly
arbitrary; probationary periods are non-inclusive to candidates who are
relocating or need a visa; asking candidates to "build something - anything"
would be substantially more time consuming for engineers in many specialties.
(How am I supposed to build a small demo app to show off my systems
programming ability?)

It's hard for me to escape the conclusion that the author's just trying to
universalize their personal preferences.

------
soneca
I think the best hiring process would give the candidate options. Choose among
pair-programming a live coding challenge or a new feature creation,
whiteboard, take-home coding challenges, or going through some open-source
project from the candidate.

I happen to prefer take-home challenges more than any of the alternatives.
It’s much less stressful than any live assessment. And I have the time.

But I understand people that hate it. You evaluate the candidate how they
think they are best evaluated. And I don’t think it is that much more trouble
or time investment by the company.

------
Karupan
I get the general feeling that people on both sides of an interview want it to
be _exactly_ what they want it to be. That never happens. There are problems
with the way tech interviews are conducted now, and we should aim to fix it.
But human biases will always apply just like every other thing in life.

My rule for interviews (whether as an interviewer or interviewee) is simple:

1\. Explain/ask for the exact process and stages during the first call.

2\. Raise any concerns as soon as possible.

3\. Be ready for either outcome - if your concerns are reasonable and
addressed, go ahead. If not, don’t.

------
secondcoming
I've been on both sides of the interview process and I don't agree. If you
were a chef applying for job it wouldn't be unreasonable if an interviewer
actually asked you to cook something (one famous chef would ask candidates to
fry an egg).

I do, however, not expect any candidate to do anything we haven't had to write
ourselves. I also let them look up Google/StackOverflow etc during the
interview. They're also offered a beer but nobody ever takes me up on that.

------
microtherion
I have my own misgivings about asking interviewees to write code for
interviews. But some of what the author considers weaknesses of this are
actually strengths:

> A disproportionate amount of time is often spent trying to deduce the
> requirements of the challenge.

Deducing requirements is a job skill at least as valuable as the actual
coding! There's nothing worse than perfectly polished code that solves
entirely the wrong problem.

And the author's proposed alternatives seem even worse:

> Ask pertinent questions.

OK, but that selects for people who can build a compelling narrative around
their work. This is not the worst skill to have, but it's not entirely aligned
with the actual work requirements, and subject to cultural and sometimes
gender biases.

> Have a probationary period

I strongly dislike that. At-will employment is a reality in many places, and
probationary periods are a reality in even more places, but they should be
seen as a last resort, rather than a routine filter. I don't want co-workers
to show up and be kicked out within a few weeks. I don't want to move 8 time
zones, enroll my kids in new schools, sell my house, to be told after two
weeks "Hmm, this does not seem to be working out".

> Walk through their existing projects

As has been mentioned numerous times on HN, that's at least as discriminatory
as take-home exams, if not more so. You may spend your free time with your
kids, or welding kinetic sculptures instead of programming. That's a perfectly
valid choice. People who interview forensic pathologists don't expect them to
cut up bodies at home in their spare time.

And generally, showing existing projects from previous employment should be,
and is, grounds for immediate disqualification.

> Ask them to build something – anything!

That strikes me as considerably harder and considerably more subjective to
evaluate than a standard take home exam.

> Pair program / Focus on their ability to learn

That's reminiscent of one technique I used to like: Show the candidate a piece
of product-like code, and ask them questions about various pieces in it
(programming language constructs, algorithms used).

------
simplyinfinity
I'm currently in the interview process with few companies, here's my
experience with them:

Company 1:

1 hour HR interview

Coding task spend about 4 hours on it, at first i implemented basic but
correct implementation, no OOD & design patters or anything fancy. They said i
should redo it but with SOLID OOD and design patterns + unit tests, so i threw
in the most convoluted code i could think of for a console app. That did the
job and got to the next part.

3 hour technical interview, ~2 hours of HR talk & getting to know me, then a
set of 5 algorithms tasks. I failed at some point, as i'm not fan of
algorithms tasks and i don't have CS education, so my algorithms knowledge
isn't strong.

Result : Not qualified enough no offer

Company 2:

1 hour HR interview

After which they sent me a task that would have taken me about 8-10 hours to
do. I politely Declined.

Company 3: 1 HR interview 2 x 1hr technical interviews,

First technical interview : extend a very very simple code (2-3 classes) with
couple of functionalities and write tests. All in all it took an hour and was
pretty straightforward. With no hidden gotchas

Second technical interview : you are given task details, and have 20 minutes
to come up with overall system design. after which we spend about 30 minutes
going trough that and asking why i choose X or Y, or what if the requirements
changed to X or Y.

then 1 hour final "culture fit" interview. Result: waiting for offer.

Company 4: 2 x 1 hour interviews with the CTO & CEO. Tech talk mostly, but no
deep algo questions. What challenges I've had and how I've solved them. Result
: waiting for offer.

Company 5: one 1 hour HR interview, and i have to do a 5 hours long fixed time
(i.e. they sent tasks at 12:00 i have to be done by 5 and send results).

And i'm debating if i should do it at all.

I've had the most pleasant experience with companies 3 & 4\. From their HR
staff to their Interviewers.

About about me for context: I'm a backend/full stack engineer with about 10
years of experience. I've coded professionally in PHP, C# and JavaScript. I've
led few interviews, but never used spend-a-day-doing-it code challenges.

~~~
Kuraj
Company 3 is very close to the interview process that led me to my current
job. They also gave me a choice between a "waterfall" approach, or pair
programming where we talk about the solution as we go.

Most pleasant interview experience I've ever had.

------
ausjke
Don't know what to say, but I think this is one way to iron out senior folks
who don't do daily coding and most of the time was on designing, diagnosis or
debugging.

When you go to interview,you may be interviewed by a fresh graduate who throw
you a trick leetcode question that is, pretty much, requiring you come up with
code in 30 minutes. Without a few months careful practice, it's hard to get it
right under stress.

Coding challenges are like driving, you drive at normal speed in real life so
you can drive everyday safely, but for interview, your brain has to be speed
up the max speed under pressure, not everyone, not even the brightest guy who
can do this well, again without months preparation.

I got interviews at Amazon etc but I never had time to practice leetcode etc,
there is no way I can pass its whiteboard process without at least 3 months
preparation I feel, and I absolutely have no time for that.

How about hiring senior folks as a contractor for 1 or 2 months then to decide
the level and pay and such? nobody wastes anytime and no obligation either.

------
hello_asdf
I disagree with the author. A coding challenge is a good way to judge how a
candidate approaches a problem. The ability to walk through what you’re
thinking while you’re doing it is a great judge of ability.

It also helps to weed out people who can’t actually program, this comes up
annoyingly often.

I agree that having intentional errors in a starter repository is bad though.

~~~
dylan604
You can also have a discussion one how one would approach the problem vs
actually doing the coding. The discussion alone would give great insight into
how the applicant understands the whole concept, and any potential pitfalls
that can be anticipated, etc.

------
ipnon
The prevailing opinion in this thread is that coding challenges are fair and
equitable. HN was singing a different tune on the same subject just a few
months ago. What changed? The economy collapsed. The labor market is no longer
in favor of those selling their time and energy. So perceptions of this
practice have changed.

------
JMTQp8lwXL
Instead of a data structure and algorithms problem, give someone a broken
webpack and/or babel configs and 30 minutes to figure it out. Will let you
know if they understand bundlers and transpilers, which is probably more
useful than an esoteric tree traversal question, at least with respect to
front-end engineering.

------
Tade0
Ugh, so many points I would like to address, but can't without turning this
into a lengthy essay.

Anyway I'm currently interviewing and have been on both sides of the
recruitment process.

I don't mind homework, but I know that more often than not it's never read or
taken into account.

I discovered this by accident when I published my solution through a service
that sends a notification when somebody downloads. Eventually they did, but
only after I passed all the other steps - even though the task was given early
in the process.

I've been publishing them like this ever since and this is my experience so
far.

So yeah, coding challenges apparently are just a way to gauge your level of
commitment, not a way to test your skills.

Personally I'm turning this around by asking to see a piece of code before we
discuss compensation in detail. Dodged at least one bullet this way.

------
dizzle90210
The fact is, that without some demonstration of a candidate’s usefulness
(their code) I cannot hire them. We used to use HR, now it is the head of
engineering who runs our technical hiring. The process is very simple,
complete a task, and if it is done correctly we start looking at soft skills.
If you can’t do it in a manner that suggests you can hit the ground running,
you are cut.

Reality is harsh, and unpleasant. In an environment where resources are
tightened by rapid growth, we cannot afford the trappings of these supposedly
“superior and modern” hiring techniques. We need talent, not mediocrity.

------
joeax
I've been on both sides of the table and I'll tell you a coding challenge is a
much better solution than the whiteboard/leetcode/code-on-the-fly during the
interview. Just keep it short i.e. 2-4 hours max.

As far as alternatives to a coding challenge, the OP did suggest walking
through a prior project on GitHub. I think that's a great idea (in addition to
a coding challenge though); an open source project on GitHub is a bonus for a
candidate, and will in many cases steer the interviewer to ask questions about
your project in lieu of abstract concepts.

------
aantix
It's a tough problem, but eventually you have to demonstrate some sort of
competency. White board, open source contributions, homework. There has to be
some way of demonstrating you know what you are doing.

I'm a consultant so I've been through tons of interviews at this point in my
career (21+ years).

If I had my choice? I'd pair program with my potential teammates on a
bug/feature for the product I'd be working on.

Give me something real that's been in the backlog for a while, and we'll pair
on it for the allotted time.

~~~
avrionov
This sounds good, but it will not work for many jobs. Fixing a bug in a code
base that you don't recognize is more difficult that a well defined coding
problem. Candidates will be limited to the technologies and problems which
they are already familiar.

This approach has some value, but it can't be the only way to evaluate
candidates.

------
nihil75
Yea, it's meant to be a waste of your time.

More accurately, if you need to learn new things to complete it - it will be
very time consuming.

Someone experienced, or that uses relevant tech/skills on a daily basis should
complete it in less than the time allotted.

Therefore "homework" coding challenges are useful for discerning if a
candidate has relevant, current experience.

See the article on college professor solving a 30+ of CS problems in one day.

Whiteboard challenges, on the other hand, evaluate a candidates thinking
process & presentation skills.

Whiteboard challenges

------
Glyptodon
I don't like coding challenges, but on the hiring side it turns out even
really basic ones can filter out a huge chunk of people who can't code their
way out of a paper bag. But for most jobs they don't really need to be
anything crazy. It turns out that plenty of applicants have a hard time with
things that are surprisingly simple and that's really all you need.

------
pknerd
I got chance to appear in a couple of coding challenges while applied for
jobs. In one test I failed. It was a typical hacker rank riddle. The other I
passed as I see my test ran properly yet I got a rejection letter. Another HN
based job interview I was asked for a challenge but I simply refused.

------
andrewstuart
Recruiting is mostly about finding reasons to say no.

And nothing gives more open ended reasons than the coding test.

------
jariel
Crossing concerns here:

Assignments can be helpful, but they can also be time consuming which is
unfair.

Do the code or whiteboard 'on the day' \- enough with the take home tests, or,
pay people to do the tests.

------
bdcravens
What other industries do something similar in their hiring process?

~~~
andy99
A family member is a chef, and for new jobs you have to "stage" [0] where you
come and cook for a (unpaid) shift to see if you are a fit, have the skills,
etc. To me this is exactly the same thing, and I expect this is very common
across different kinds of jobs.

[0]
[https://en.wikipedia.org/wiki/Stage_(cooking)](https://en.wikipedia.org/wiki/Stage_\(cooking\))

------
egsmi
One thing I always wonder, how do other professions do it? Do civil engineers
have to make a building? Do chemists have to assay a sample? What makes
programming so unique?

~~~
non-entity
Well for one you wont see Chemists or Civil Engineers from the variety of
backgrounds developers come from. It's near impossible to become one without
the degree.

------
odomojuli
I've been through so many puzzle dungeons that I immediately just exit a
process if it involves another technical interview. I've done technical
interviews with FAANG and the like and those processes actually tend to be
much nicer at more mature companies because they're actually well designed
problems with people who actually understand their significance. You at least
get to ask questions and not just get told to jump through the hoop like a
dolphin. For the rest, you end up with interviewers who google some esoteric
Python problem they think is particularly clever.

I'll stop here to state that I think any adherence to being overtly clever is
my first and only red flag.

It's so pathetically obvious because the number of times I've done the exact
same problem for multiple companies because it happens to be the 2nd or 3rd
search result.

I once had someone disqualify my answer for using a DFA because it wasn't
"real code".

To be honest, I think the technical interview actually IS important, and I've
had numerous experiences enjoying it if only to showcase a lot of the more
necessarily toxic behaviors of a company up front. Let's be honest with
ourselves, is any employer going to necessarily have the best practices with
respecting your time, money and effort? It's best to lay out those cards up
front. Literally every red flag will demonstrate itself through the
interviewer in most scenarios. Like any test, you get out of it what you give.

For example:

How many times do I feel this?

"We take an extra time-slot / day / email chain in what is already a
hypercompetitive market just to suss you out. We wait until the last stage of
the interview process to do this because we still don't totally trust you or
understand anything you've done. We waste a lot of time creating elaborate
puzzles that don't really matter. We're not going to pay you because our
finances are already horribly mismanaged that it's complicated to contract you
out for the day and also we feel like you should be gladly externalizing your
labor costs for our shiny position if you really love us. Drink the kool-aid."

Sometimes the technical interview surprises me. I always use it as a
motivating example of myself as a candidates to work through a problem, show
grit and also demonstrate when to ask for help. Ego and pride on both sides of
the equation come into play and that's always a worthwhile exercise before
engaging it any longterm commitment. A good test accommodates and informs
through failure. I learned this from administering the Putnam. Never got a
decent score on it, but it was a worthwhile experience to fail. Interview
tests are on the other hand, are not designed to teach anything except that
you are unworthy.

My best roles have never asked for it. The company knew what they were looking
for, were willing to trust me, were able to move along the interview process
without losing me to a competitor and everyone was happy and they always pay
competitively. Usually if there's a technical interview involved at all, they
have no idea what I can actually do. If they're willing to waste time, effort
and money on extra steps and are taking "necessary precautions" to subject you
to what are essentially just litmus tests, then I'm sorry, that speaks to me a
sense of your culture of mediocrity and dogmatic orthodoxy towards process.

Goodhart's law. When a measure becomes a target, it stops being a good
measure. When I was in school, we had other students take a year off to study
for the Google interview. These were all affluent white men. At the same time,
I had recruiters complaining to me that there were no decent black/brown
candidates in the pipeline. I remember hearing the same thing except as a
child. Uhhh, there's been plenty of time to invest into the local community.
Recruiters would do well do understand to the history of the SAT as systemic
racism, or literacy tests as systemic racism, or like any actual statistics as
systemic racism. Everything that reduces candidates to numbers and quizzes
feels rife for abuse. Who has the privilege to study an extra game on top of
performing in a society that is already stacked against them? That's not a
question.

To wit, there's the issue with a large number of candidates with junk resumes.
There's the outstanding issue of "authenticity" in professional acumen.
There's the whole problem with the industries underlying predatory behavior
with regards to labor externalization and laundering numerical metrics, be it
the rate of inclusion and diversity or the amount of hours actually demanded
by management. What is so fundamentally wrong with the technical interview is
that it's just the cherry on top for what is already a miserable process. I'd
so much rather just do free work for a potential client and just give it to
them so it actually means something and is useful than waste any more time
solving pointless puzzles, and this is from someone who specifically enjoyed
studying hard pointless puzzles in school.

No, you can't just show side projects. You should not be showing your work
portfolio to anyone who isn't paying you. If they were interested in open
source, they'd already be paying you.

The technical interview is dead. Long live the technical interview.

------
mden
Most of the alternate approaches have their own severe failings:

Ask pertinent questions - a lot of candidates are bad at immediate summation
and dissemination of information. There are many good engineers who have not
learned how to sell their work, themselves, or in general communicate to the
intent of a question. This is an invaluable skill, largely orthogonal to
writing code, but it's a skill that's often learned with experience. Learning
to ask level appropriate questions is hard and evaluating answers consistently
(if not objectively) even harder. It is also largely insufficient in gauging
programming ability. I've had co-workers who can talk about advanced
architecture-y topics seemingly competently but struggle to write even
relatively simple code.

Probationary period - I've never seen this implemented (excluding internships
which sort of fall into this category) and it certainly sounds like a nice
option to have available but I would bet many candidates would be afraid of a
short probationary period (say 3 mo) especially if they have to move their
family for the job. Being a professional and being told you are on a
probationary period is stressful. At many large companies it can easily take
more than 6wks to get up to any sort of productivity.

Walk through existing projects - most people (vast majority) do not have any
sizable or clean or even "interesting" side project they would want to walk an
interviewer through. Unless you worked on open-source for your previous
employer (again minority of people) or on your spare time, this is not
something you can get a strong signal out of.

Ask them to build something - err, I don't see how this is that different than
a coding challenge. And again, not everyone has personal projects ready to be
shown to an interviewer. For example, the game I'm coding some nights after
work does not look anything like code I write for my employer; there are no
tests, there's a lot of experimental and often dead code, functions are not
neatly factored and thought out with an eye for collaboration, etc. I would
not want to be judged by this code for an interview.

Pair programming - this sounds like a coding challenge but with a more
empathetic interviewer. I don't think this is an alternative, just a mild
augmentation of a coding challenge.

Focus on ability to learn - companies do this but it's usually considered
supplementary to coding ability. Some companies explain their product and try
to see if the candidate understands where the value of the product exists or
at least where some of the challenges are. This could be spun out into a
product type interview or a system design interview depending on intent.

Alternatives to white-boarding or do-at-home project interviews: \- Provide a
small existing but functional code base and ask the candidate to implement
additional functionality. Downside is this takes a lot more effort to prepare
and are limiting the candidate in regards to language they want to use. \-
Provide multiple options for a coding project or question and let the
candidate choose which one they want to solve. This would hopefully reduce
some of the luck factor of getting a question you know how to solve. \- I
can't think of any others, but I'm sure they exist

One of the big desirable goals of interviews are evaluating candidates in a
consistent manner. All interviewers have biases and these biases vary between
the interviewers. Trying to account for that is, I believe, important but also
very hard. Using the proposed alternatives would make it even much harder.

------
hnrodey
so much complaining

