
Show HN: Interviews can be stressful – give take-home projects instead - asadlionpk
https://www.remoteinterview.io/takehome
======
jbob2000
This is taking interviewing and hiring in the wrong direction. At my company,
we have a relatively short interview process, followed by a 3 month full
salary probation period.

The interview is used to weed out "red flaggers" and identify high-level
strengths and weaknesses. It is completely non-technical. We assume that the
person applying for the job has the technical requirements. (We also make
judicious use of references, something people seem to have forgotten about.
Quick phone call to previous employers can save you tons of money!)

The 3 month probation period is the real "test" and the applicant will be put
on a small project with another employee mentoring. If someone lacks technical
ability, it will be evident in the first few days and we can move on to the
next applicant. If the person doesn't like the work environment, they can walk
away no questions asked (maybe the commute is too long or they don't like the
office space, etc. etc.).

This is cheaper than having directors and executives try to plan around all
sorts of interview stages. It is much less stressful, as the applicant, once
into the probation period, is treated like a regular employee and has much
more opportunity to "prove their worth". Stop adding more shit to the
interview! Don't make it longer, do the opposite!

~~~
tptacek
Why would I ever accept a job at a company who treated the first 3 months of
my employment as an extended interview, after which I could be released
without penalty?

When a software accepts a full-time position, they are taking a _mammoth_ pay
cut from what they could make 1099 contracting. They do that because the full-
time position comes with a commitment to continued employment, so even though
they could be making 2x-3x more per day consulting, they don't have to hustle
to keep their utilization up.

The "3 month probation" thing is essentially a temp-to-perm contacting
position. Do you pay people 2x-3x more during that period?

~~~
dang
> _The "3 month probation" thing is essentially a temp-to-perm contacting
> position. Do you pay people 2x-3x more during that period?_

What about paying people the 2x-3x more in the event you decide not to keep
the hire? Then the mechanism becomes a 3-month option to make the job either
full time or a fairly compensated contract.

~~~
atomicUpdate
> What about paying people the 2x-3x more in the event you decide not to keep
> the hire?

This could be pretty easily abused, since it doesn't sound hard to get through
the door if they are assuming you're qualified technically. So all you have to
do is know just enough to fake it a little bit, then coast for as long as you
can to get a big payout at the end.

~~~
tptacek
If you're running easy-in, fast-fire, then you should pay 2x-3x _continuously_
during the trial period, just like you would to a freelance consultant doing
the same work.

But if you're running a real hiring process with accuracy as a goal, as you
probably should be, then the 2x-3x payout at the end of the trial program at
least fixes some of the incentive problems, and, if you're running that
program in good faith, you're doing it because you expect most people you
extend offers to will pan out --- so you'll rarely pay that bonus.

------
pamelafox
I've always liked take-home projects for 2 reasons: 1) I get extremely anxious
during interviews, so I don't perform well in them (to the point of crying
sometimes - [http://blog.pamelafox.org/2013/09/technical-interviews-
make-...](http://blog.pamelafox.org/2013/09/technical-interviews-make-me-
cry.html)) 2) I like getting to see what it'd be like to do the sort of work
that the company would be asking me to do for my job - it's a good taste to
see if the company would be a good fit for me. The best take-homes are the
ones that _very closely_ approximate the actual job.

However, not everyone likes take-home projects or has the time to do them. So
it seems that companies should ideally offer each candidate multiple paths,
and develop consistent rubrics to evaluate how each candidate does across
paths.

I also do like the idea of probation, as it once again seems like it could be
both good for the company and good for the employer, to give them both a sense
of fit. Jobs are such big decisions, it's stressful for both the employer and
employee to figure out if it's the right path for them.

~~~
Domenic_S
I like them too, but if and only if they come with a review after turn-in. If
I botched it in your eyes I want to know why!

------
Mikeb85
This is silly. First of all, are interviews stressful, yes. That's not a bad
thing. The real world is stressful. Soft skills matter. Interviews are useful
to see how candidates react.

Second, most people aren't born with the perfect skill set for a job. Most
don't even acquire it in university, or at a previous job. Most important is
the ability to learn and grow.

Third, in this day and age, you may send hundreds of resumes, and have
multiple interviews. Are you going to do 2 weeks of take-home projects? What
if you have multiple interviews in one day, and both places expect you to
finish take-home projects. What then?

This just seems like another hoop to make candidates jump through, with no
good outcomes.

~~~
a_c_s
Interviews, for many people, are stressful in a way that jobs are not.

Personally, the most stressful things I've had to do as a developer (including
speaking in meetings large and small) are an order of magnitude less stressful
than even the best interviews.

edit: typo

~~~
seansmccullough
During my last job search I did a take-home project, spent far more time on it
then was specified, and then was rejected without an explanation. What a
wonderfully productive use of 40 hours.

I'd much rather study for interviews.

~~~
bm1362
I always end up enjoying the projects and learning a lot about a new domain in
the process. I think for me, I see them as an opportunity to write code
outside of my current role or comfort zone. I have been rejected once, the
team really liked the project and I spent a considerable amount of time on it,
but they found a more experienced engineer.

------
sirtastic
As someone who has had "8 hour" take home projects with requirements like
"build a responsive site for this fictitious product and include creative UX
features as well as a full summary of thought process during the project" I
think this idea is horrible. I refuse to do take home tests, they are a waste
of my time.

I've been to 50+ interviews on both sides of the table and can tell you there
is always a few questions you can ask to determine someones development
competency.

Not to mention I have literally thousands of hours of work I can send you from
PSDs to code if you want to dive into my work.

------
kelashbatra
I'm not a fan of take-home projects. But comparing that to mumbling at a
white-board, give me take home interviews any day of my life.

~~~
asadlionpk
Agreed, ideally there should be a choice between the two because some actually
prefer whiteboard type interviews.

This is a good post discussing both: [http://blog.triplebyte.com/take-home-
interviews](http://blog.triplebyte.com/take-home-interviews)

------
chad_strategic
Best interview I have had was an interview, then it was followed up by a paid
"side-project". I got paid to do some work for them and everybody was happy.
Eventually, I figured out there where some politics/business practices that I
didn't care for and I politely declined the position. It just wasn't a fit,
not the end of the world, nobodies feelings where hurt. (it also helps having
a job, when looking for one.)

The thought of 3 month probation period is just silly, the author clear
doesn't understand the concept of risk.

I know when I walk into an interview and someone asks me the difference
between php 5.6 and 5.7, that's when I walk out. (true story)

~~~
mahyarm
You cannot legally do paid side jobs with visa holders.

~~~
dragonwriter
> You cannot legally do paid side jobs with visa holders.

An alien admitted under a visa can do paid side jobs if the visa they have
permits work in the United States (unless the visa only allows restricted work
not compatible with the particular paid side job.)

~~~
mahyarm
H1-B & TN visa holders can only do work for their specified employer(s) in
their visas. I would be pleasantly surprised if this was actually not the
case.

If you have a green card or general work permit then it doesn't matter of
course. To get a general work permit although, you're usually pretty close to
getting a green card.

~~~
dragonwriter
> H1-B & TN visa holders can only do work for their specified employer(s) in
> their visas

Right, and I'm not saying that that is inaccurate for those particular visas.
Just that the generalization to "visa holders" is overbroad.

~~~
mahyarm
The vast majority of people you could hire that have visas are those two
categories. L visas are even worse because I think you cannot transfer
employers with them. The few H1-B spouses, O-* holders and others are few and
far between.

------
collyw
Sure but expect to half your candidate pool.

Can't I talk you some code that I have already written instead of wasting half
a day doing some trival project in a rush?

~~~
asadlionpk
I think companies should optimize on giving options between all of the proven
methods. Some may like the classic interviews but some may have a good github
profile which is also a good signal on how the applicant is.

~~~
collyw
Proven methods? Are there any?

~~~
asadlionpk
As in the classic interview, discussion based on previous project, discussion
on take-home interview. I think there can be good results when candidate is
given the choice.

------
edw519
Disagree completely.

There are simply too many things that you learn in the interview that are too
difficult to learn any other way. Having someone code is NOT about seeing what
kind of code they produce (well maybe a little); it's about getting to know as
much as you can about them in as little time as possible.

I want to put the candidate under some amount of stress to see how they
respond. After all, responding to stress (deadlines, technical issues, people
issues, etc.) is a very important part of a programmers job.

Just a few of the things I usually learn with a short coding test in an
interview right away:

\- Did he understand the problem?

\- How did he approach the problem?

\- Does he appear as if he has any idea what he’s doing?

\- Can he explain what he has done?

\- Can he defend what he has done?

\- Does he understand the concepts of order, cleanness, iteration, branching,
recursion, etc., etc., etc...

\- Based on this small sample, do I think he can do the work we need done?

\- Do I like him? Will he fit in and be a good team member?

Of course, I share all of this with the candidate. There's no secret agenda.
We just want to make a fair assessment of fit. This is good for everyone.

All a take-home project does is separate those who can build superior code
from those who can build good code under ideal conditions. This is nice to
know, but not a very important metric in the real world.

Ideal conditions rarely happen on real projects. Why simulate them in the
screening process?

~~~
tptacek
The problem is that most interviewers _think_ they can assess these things,
but (a) really can't, and (b) are having their readings confounded by the
nervousness and discomfort of candidates.

Also: we banned "Do I like him? Will be fit in" at Matasano several years ago,
and were far better off for doing so.

Answer honestly: for _every bullet_ in this list, did your team have a
_standardized rubric_ by which you could mechanically evaluate candidates?
Matasano had a much smaller list of considerations for candidates, but
developing working rubrics for assessing them took _years_. If you really have
a working rubric for this ambitious list, you could be making a lot of money
with it.

Note also the pronoun you've chosen to use through your comment. I know it
isn't deliberate, but that choice also has an impact.

~~~
HeyLaughingBoy
This is an excellent point and it's one of the ways we tried to reduce the
interview subjectivity at my last employer.

Don't get me wrong: in the end, an interview is highly subjective, but when
five people are evaluating someone, you want to have some way of calibrating
their expectations so they are at least close to being on the same page.

It helped to even out the process. If Tim says the candidate was a 3 out of 5
on multithreading concepts, I know what questions he could have been asked
(there may be 6 to choose from on the list) and what quality of answers he
gave (typical candidate responses are shown, in increasing order of
"quality").

Did it help get us better developers? I don't think so. In the end we
concluded that our biggest problem wasn't screening good from bad candidates
-- we usually made pretty good hires. The problem was getting good candidates
to apply in the first place.

------
robgibbons
Take-home projects can be time consuming, give them Interviews instead

------
retube
Nope. I've had several of these, all were at least a full days work, which I
had to cram into late evenings etc on top of day job. And to top it all, they
weren't even discussed in the interview!

Never again.

------
oglo
Take-home projects are not the best way to judge skills (atleast in their
current form). In the future, there would be some centralized solution so we
don't waste time again and again.

~~~
zhang3r
create a commonapp style application process? one project, multiple companies,
and companies can add their supplementary challenges or something

~~~
asabjorn
That assumes that you know how to test and judge engineers. I think the larger
issue in engineering interviews these days is that we simply don't know how to
effectively separate good engineers from the bad, and given the nature of our
job there is a sometimes significant lasting negative impact of a bad/messy
programmer.

~~~
collyw
In addition people are better at different things. I joined a startup
recently. The code is well organised at the top level, and the logging was
superb. However the architecture was terrible, horriby overengineered. And it
looked like a Java programmer doing python - camel case instead of underscores
(well a mix just to be inconsitent). Joins done at the application level
rather than the database. And just doing way more work that was needed to
calculate something.

------
leepowers
Is there a mechanism for paying the test taker? A developer shouldn't be
expected to work for free. The outside chance he'd be the 1/100 applicant to
land the job isn't enough.

~~~
angelbob
Absolutely. Since a good dev can get somebody a job, he can just set up a
business gaming this system :-P

------
hyperchase
The best company I ever worked for did a two hour pair programming session on
a simple rails app (since they were a rails shop) with every candidate that
got passed the "chat over coffee" stage. You'd get to see the kind of code the
candidates write and how they work through problems, how they work with
another developer, and get a really good overall sense of how they would work
as part of the team.

~~~
dubroff
I like pair programming sessions a lot because both the candidate and the
employer are investing an equal amount of time. While the intention behind
take-home projects is good, the result is often that the candidate invests
several hours into a project just to be quickly passed over by the employer.

------
dominotw
Ain't nobody got time for that.

------
lukasm
Interesting I'll add it to [https://github.com/lukasz-madon/awesome-remote-
job](https://github.com/lukasz-madon/awesome-remote-job) could be especially
useful for companies that hire remote workers.

(shameless plug intensifies)

------
jsatk
Personality, communication skills, etc., all matter. A lot. There's more to
being a good software engineer than knowing how to code well. You have to be
able to back up your ideas, convince others of your ideas, hear others view
points and objections to your ideas, etc. Take home projects are great, but
they're not a substitute for a face-to-face interview.

~~~
duderific
We do both: \- A take-home project that takes a few hours \- We assess their
code; if it looks good, we bring them in for a few more interviews, both tech
and non-tech \- If it doesn't look good, we move on to the next candidate

~~~
orless
OMG. A few more interviews? Can't you handle everything in one or two
interviews?

Seriously, from my (quite senior) point of view - if you've seen my CV, done
research on me (StackOverflow, GitHub etc.), seen my code from the take-home
project, did a technical and non-technical interview and still unsure if I'm a
match or not, I'd really doubt your competence. I must be really so
exceptionally interested in the position to do a "few more interviews".

------
rpedela
bug report: The browser's back button goes into infinite loop.

1\. Click "CodePad".

2\. Click "Create New Pad".

3\. Press browser's back button.

4\. Repeat #3 to infinity.

Ubuntu 14.04, latest Chrome

------
dmarlow
I like it. Let the company decide what's best. This is just another tool they
can choose to use.

The term "take home project" is wrong. It's a take home "interview"! I keep my
interview challenges at a 1-2 hour time frame if you know what you're doing.
If you take longer, you may not be qualified.

------
ksk
I'm all for trying out new ways to interview people, but IMHO people should
err on the side of caution and be willing to let "good" candidates slip
through the cracks than risk hiring someone who is a dud. Personally, I think
it matters if someone can come up with a solution in 1 hour vs 15 hours.

~~~
lewisl9029
There's a difference between being able to come up with a solution in 1 hour
vs being able to come up with a solution in 1 hour on a whiteboard, with no
internet access, and with someone breathing down your neck the whole time.

If your company has a genuine need to screen candidates for their ability to
perform under the special conditions of the latter, then by all means, set up
your interviews with those special conditions. Otherwise, I feel you'd be
better served by an interview that more closely emulates the actual working
environment that your employees work under.

My ideal technical interview would be one where the candidate is assigned a
problem that is representative of the work that they're being hired for, and
then left alone to work on it for an hour or two in their own preferred
working environment, and _then_ the interviewer and candidate can meet up and
demo the solution and discuss implementation details.

~~~
ksk
>There's a difference between being able to come up with a solution in 1 hour
vs being able to come up with a solution in 1 hour on a whiteboard, with no
internet access, and with someone breathing down your neck the whole time.

You can usually fit about 15 lines of code on a whiteboard which tends to bias
questions to simple logic questions. Why do you need internet access? Also why
does someone have to breath down your neck? They could leave you alone for 45
minutes and come back.

>Otherwise, I feel you'd be better served by an interview that more closely
emulates the actual working environment that your employees work under.

Why do you feel this way?

I think that programmers should have as many programming related patterns
memorized as possible - For e.g. How to compose different kinds of programs
when given different resource restrictions, or having basic algorithmic
concepts in their head so they can quickly choose one over the other. A
programming test should immediately indicate if the candidate has such things
on the tip of their tongue or not.

In much the same way as you don't open a high school physics textbook when you
go about building an airplane, you don't want someone who has to google basic
programming knowledge that they should just have in their head.

IME, when you start with a very high level of intrinsic knowledge it's much
easier to make connections and come up with unique solutions, because your not
constantly 'searching' for things. Instead you're just 'picking' the right
building blocks. Or maybe trying to quickly eliminate obviously bad choices.
Ofcource there is much more nuance, but you can't state everything in a single
comment ! :")

~~~
lewisl9029
> Why do you feel this way?

For the same reason why I feel whiteboarding and having someone breathing down
your neck are generally not reasonable conditions to place on a candidate (and
you seem to agree with me for these two points, so I'll only expand on the
point about internet access): It doesn't make sense to place artificial limits
on candidates' abilities to perform their work, when that's exactly what
you're trying to gauge in a technical interview.

RE: internet access.

As with natural language, developers tend to have an active vocabulary
(concepts and APIs that they come across often and can recall on demand), a
passive vocabulary (concepts and APIs that they may be aware of and recognize,
but cannot apply immediately or without reference), and a set of completely
unknown vocabulary.

Yes, developers should strive to build and maintain our active vocabulary to
the greatest extent possible (i.e. memorize all the things) since it would
make us more productive. However, human active memory is severely limited
compared to the vast amount of knowledge developers often need to perform
their work, and as such the vast majority of most developers' knowledge tends
to reside in their passive vocabulary.

To force candidates to develop without internet access means limiting them to
their active vocabulary, when this is only a tiny subset of their total
vocabulary. This means you won't get an accurate picture of their ability to
perform their work, which is exactly what we're trying to gauge in a technical
interview.

------
masukomi
this is equivalent to asking math students to provide their answer but not
show their work. I interview people to figure out how they think and learn how
they solve problems. I don't actually care about the answer they give to the
technical question nearly as much as how they got there. No way in hell I'd do
this, nevermind pay for it.

~~~
asadlionpk
The idea is to then discuss the project in the interview. This closely relates
to what applicant will be actually doing at the job.

------
jaruche
Really interesting concept!

