
Ask HN: Is it now common to ask for “full” applications as part of interviewing? - Futurebot
Three companies (out of ten or so) I&#x27;ve interviewed with recently have all asked for something similar to the following:<p>- code<p>- integration with a third-party API<p>- installation of a number of third-party libraries (and the reading of their documentation)<p>- complete documentation for the code<p>- a test suite<p>- deployment instructions<p>The companies in question vary in their industry, tech stack, and focus.<p>Most of the time, take home coding challenges consist of a fairly well-understood problem and are basically souped up versions of fizzbuzz to gauge a) basic ability and b) abstraction&#x2F;organizational skills c) style<p>Is this more common now? The interview process has become more stringent over the past 10-15 years in my experience, but this is the first time I&#x27;m being asked for things this complete and specific.<p>(As an aside: are we finally near the point where companies should consider paying developers to interview if they&#x27;re going to be asked to spend the day coding, writing tests, and writing documentation? I.e., do free work)
======
falcolas
It's not yet ubiquitous, but it isn't uncommon either.

I had application go through such a coding test in lieu of a "biased interview
process", but wouldn't pay. They also had integration with two third party
services, and for a Go programming position they also wanted a REST interface
implemented on RoR.

It's a great test for "passion", however; if your definition of "passion" is
"unpaid overtime".

~~~
paulgb
I've heard the same thing, that it's an alternative to "biased" whiteboard
interviews. Which is a commendable goal, but it just ends up biasing the
process against people who don't have the free time. I passed on that one.

I actually don't mind the 45 minute automated screens that are outsourced to a
code screening vendor -- my experience is that when the in-person interviewers
see the results of that they are able to jump into more meaty questions
instead of FizzBuzz. It's a net improvement for everyone's time.

------
vorpalhex
I've stopped interviewing with companies that do this.

Take home interview "challenges" take up a lot of time and resources. Most of
the ones I've gotten have been prototypes/MVP type deals.

\+ You're asking me to spend almost a week of my time, for free

\+ I have similar examples on my Github

\+ I'm not usually allowed to share the solution

Sorry, but if you can't look at my significant github profile and figure out
if I can code or not, then we probably aren't a good match. I'm not going to
work for free because you're bad at interviewing.

To put this another way, flip the question. Would you give me your product for
free for a week? (Probably not...)

That being said, I think paying for the interview is probably acceptable.

~~~
posixplz
What if it's a coding challenge that is purposely timeboxed to 4-6 hours?

At my previous job, we asked applicants to write a piece of software that
would model the org chart for any given employee, enumerating their
hierarchical relationships as well as their peer relationships. We may have
thrown in an additional complexity or two, but we also removed a lot of
requirements (no i/o or database, no user interface; we only sought
application logic). Candidates were required to solve the problem in the
language of their choice, spending between 4-6 hours on the exercise. The
instructions were otherwise intentionally ambiguous.

By specifically calling out an amount of time, and requesting that candidates
not spend more or less time, we drew conclusions about:

* Candidate's ability to derive features from imperfect 'business requirements'

* Ability to know when something is 'done' given time restrictions

* Understanding/handling of implied but not explicit edge cases

* Creative thinking

* Tendency for writing testable code

As one can imagine, this weeds out lots of individuals who exhibit tendencies
deemed "undesirable" for this role. Scope creep, missed requirements,
untestable code, code that doesn't actually work, solutions written in
unsuitable languages (Django? Really?) and the list goes on. You'd be amazed
what people return when asked to perform a 4-6 hour coding exercise.

~~~
rhizome
I recently had a 4hr test app to model a particular set of scheduling
requirements over a calendar year. I could not finish it satisfactorily in
time, which told me that either I was a crap programmer (possible) or that
there was some common algo for this purpose that I didn't know. Of course
these two reasons may be the same one: crap programmer.

~~~
uffjedn
There is a third one where the deadline is knowingly set too low to see how
you deal with time trouble.

~~~
rhizome
That thought did occur to me, but they denied me anyway, so :shrug:.

------
derekp7
This sounds like a good startup idea: A certification agency where they put
you through the works, measuring your ability to write code, solve various
challenges, complete complex projects, etc. Then they can issue a certificate
to those that pass their examinations.

Maybe in addition, they can offer training in various topics, include periodic
assignments during those training periods, then have several days of monster
examinations at the end of it. After which, you then finally get this
certification. Of course, if this is done properly, it may take about 4 - 6
years of full time work to get through all the training and examination
sessions.

~~~
thesehands
Whilst I appreciate the tongue in cheek nature of this post, if merely having
a degree was the answer, these types of application would not exist.

~~~
WorldMaker
If a degree isn't sufficient, then what is sufficient?

A Lawyer needs to pass a BAR exam in the state in which they expect to work,
then maintain that certification (annual training requirements, etc).

Software throws around the term "engineer" a bit willy nilly, but if you look
to other engineering disciplines there is a distinct certification meaning to
Engineer as a title:

1\. You have graduated with an ABET-accredited degree

2\. You have passed the NCEES Fundamentals of Engineering exam

3\. You have apprenticed for the necessary Engineer-In-Training period

4\. You have passed your discipline's NCEES Professional Engineer exam

5\. You maintain your Professional Engineer certification (annual training
requirements, etc)

That certainly sounds like a good baseline. NCEES has a Software Engineering
Professional Engineering exam today and can certify Professional Engineers in
Software. If I never again had to do another whiteboard interview or take home
programming assignment, I'd start working on my PE tomorrow.

What stops the Software Industry from recognizing distinctions such as a
accredited degrees and PE certifications?

The software industry doesn't want to stop talented software _developers_ from
entering the market without a need for degrees and certifications, because
that drives down labor costs. But that doesn't have to stop the industry from
at least acknowledging the existence of degreed and/or certified _engineers_
and eliminating some of the BS.

------
kcorbitt
My frustration with this type of interview is that their costs are entirely
asymmetric. The company puts together a set of requirements once, and then
forces every applicant to spend 5-10 generally unpaid hours completing it. If
that were the bulk of the interview and the only further step was coming into
the office for a couple of softball "culture fit" interviews it would be
acceptable, but from what I've been told if you do great on the sample
application you're just rewarded with a full day of technical interviews
anyway.

This biases the companies towards their sample application at everybody in
their funnel, even if they have far too many applicants, are not that
motivated to fill the position, or potentially if they don't actually have an
open position at all! This wastes a great deal of candidates' time without any
real chance of an offer.

~~~
JosephLark
> but from what I've been told if you do great on the sample application
> you're just rewarded with a full day of technical interviews anyway.

Happened to me even though the recruiter roped me into the take home coding
challenge by saying "We don't do whiteboard technical interviews here".

Bonus points to this company for having the second interviewer of the day so
uninterested in interviewing me that he literally watched his watch near the
end of the interview and bolted out the door the second he was allowed to.

------
bogomipz
My experience lately has been that yes "full" is expected even though its not
specified as such.

What I mean is some recruiter will say "we would like you to complete a coding
challenge it shouldn't take any more than 2 hours to complete.' Then the feed
back will come back that "the team was disappointed that you didn't implement
features x, y and z."

The whole homework/project/coding challenge requirement has really become
disrespectful in my opinion. Extremely vague requirements, arbitrary or
unrealistic time constraints and then you are judged but not allowed to
participate in any discussion about the code you produced.

And perhaps the height of absurdity is recruiters asking via email if you will
complete a coding assignment. This is even before speaking to a human being to
see if there might even be a fit.

The hiring process just seems to be becoming more broken all the time. Just
refuse and say "No."

I think companies might really benefit from smoke testing their own hiring
process in some blind fashion.

------
giobox
It's been a while since I last interviewed, but I've wanted something like
this for interviewing applicants at my own workplace. It strikes me as fairer
to all parties, especially compared to whiteboard coding exercises.

I've heard of some companies doing exactly what you suggest - paying an
appropriate amount to cover the few hours spent on the interview project.

I get that some will criticise this saying it takes up your free time, but I'd
argue the common practice of memorising algorithm solutions for interviews is
often an equally unproductive use of the interviewee's own time.

~~~
ardit33
Maybe for recent grads that have never build something worthwhile, but it is
not reasonable for experienced people. If you are talking to 10 different
places, then having to do all these pointless exercises (which are a waste of
time and productivity), for all of them becomes unsustainable.

Most senior devs. (people with 5 years or more of experience), have their own
projects or productive lives (either hobbies, or families) going on.

I advise my friends to skip this step, and move on to other companies that
don't introduce these useless hoops. Usually 80% of the time the companies
come back and decide to skip this "homework" stage and go for a traditional
interview.

If this happens after an interview, just refuse to do it and move on to other
companies. I have almost never heard good outcomes from it as usually the task
is given if the interview didn't go well and they are not convinced of you. If
you have a choice, you don't want to join a company that doesn't fully like
having you.

------
dboreham
There is unfortunately a fairly high probability that a given interview
candidate for a coding job can't actually code (at all, not just poorly or
slowly). So hiring people try to come up with processes and tests to avoid
being the idiot who hired someone who couldn't code.

Obviously requesting that the candidate actually produce new code is a fairly
good way to ensure success in this goal.

otoh it is likely to irritate and inconvenience the candidate and probably
remove some proportion of the better applications from the pool.

I prefer to ask candidates to talk about a project they found interesting or
challenging or noteworthy, and go from there asking questions, specifically
what was their individual contribution and so on.

Personal references are also useful.

Ultimately I suppose though if I had no available candidates where I could get
a first-hand trusted reference, nor any recent project to discuss, about the
only option I'd have left would be to ask them to write code. I don't recall
it ever coming to that though.

Faced with this situation you could try suggesting that you prefer not to
spend significant time working on an apprentice-piece project and would the
interviewer accept your hobby project instead or some recent work project if
disclosure restrictions allow you to talk about it and show code.

------
mmcconnell1618
I spent a weekend working on one of these interview projects only to find the
company didn't like the Apple libraries I selected to use. They needed someone
with very specific knowledge but failed to list that as part of the project
requirements. The result? No job offer, my time wasted and I have a very poor
opinion of both the company and recruiter to this day. if you're going to do
an interview project, make sure you ask lots of questions up front before
investing your time.

------
thegreatco
This seems over the top. It reminds me of the graphic design work companies
often ask of graphic designers. Extremely specific work that could easily be
reused by the company, obtained, essentially, for free.

------
swalsh
These tests infuriate me. I was given one once, thought I did well, received
feedback from the recruiter that the employer "was unimpressed". I pressed for
details (I did spend something like 2 hours on it after all!) and received
none.

Struck me as extremely rude.

------
mfrisbie
Take home projects strike me as an overcorrection for the perceived problems
with whiteboard interviews. Drawing from a recent sample of interviews,
companies that ask for them still seem to be in the minority.

I hope this remains the case, as 1) they are an enormous time suck for the
applicant, and 2) demonstrate abilities that a qualified applicant could
become proficient at quickly. Qualification for a position requiring these
abilities can be assessed in a way that is not so one-sided against the
applicant.

Related: [https://alwaystrending.io/articles/tech-interview-torture-
ch...](https://alwaystrending.io/articles/tech-interview-torture-
chamber#takehome)

------
Bahamut
This is why I oftentimes dislike take home projects for interviews - they're
extremely time consuming, or are biased towards those who can cobble things
together quickly. I can do that too, but it's not without stress or time
spent, and I know I would be competing against others probably willing to sink
more time.

~~~
turc1656
_competing against others probably willing to sink more time_

Doesn't that kind of go towards the "who wants it more" mentality? What's
wrong with that? Maybe you and someone else are equally good coders, or maybe
one of you is clearly better. Either way, the only thing the company should
care about with a salaried position is the finished product, not whether or
not someone put more hours into it. I think people all too frequently discount
effort and desire when interviewing. People focus on who has some very
specific skill set and experience rather than "does this person really want to
work here in this position"? Or "is this the type of person we want to work
with"?

You can work hard. You can work smart. You can be successful doing either,
generally speaking. Do both, and you will usually be more successful than most
others.

Plus, if it was a position that you really wanted, I would think/hope that it
would be something that you would find yourself spending more time than
expected, on. I know I would if I was in that position. If I didn't really
care about the position or the company, I would not try overly hard, and I
assume that would show. Which is yet another reason I think companies probably
should do more of this if anything, not less.

------
_dark_matter_
There was some discussion of this recently on r/cscareerquestions [0]. The
general consensus there was this is too much, though a few people had seen it.
Myself, I would have to really _really_ love the company to consider doing it.

[0]
[https://www.reddit.com/r/cscareerquestions/comments/6bvmpf/a...](https://www.reddit.com/r/cscareerquestions/comments/6bvmpf/are_technical_tests_like_this_one_common_or_just/)

------
Tinyforebrain
Companies use these to save time. Interviews take hours of time for multiple
people. They are also soul-crushing for the interviewers to be forced to sit
while watching people flounder at the whiteboard. At several companies I have
been with, they had a basic 20 question skills test. It was enough to cut the
number of time-wasting interviews massively. I assume that the "Full
application" process is there for a similar reason. It shows them up front
that you know the basics, or know how to Google the basics. At every company I
have worked at that had a pre-test or code submission application, people who
submitted the test/sample would have an enormous leg up. With interviews it
was like 10-20:1 interview:hire ratio. With the test/sample it was more like
3:1. It is a massive time/effort saving filter on the company's part.

Companies are NOT trying to get free work out of you. If they wanted to hook
to a third-party API, it would be easier to use the API sample code. They are
trying to save themselves hundreds of dollars in staff salaries and lost
productivity, to interview a person who can't function in a realistic
programming environment.

These are EXACTLY the sort of companies you should apply to if you really want
a job.

~~~
geofft
If a company thinks that their time is about 20 times more valuable than my
time, why would they stop thinking that once I start working there? If a
company thinks that the interview process is "soul-crushing", why wouldn't
they also think that of code review, mentoring employees, etc.?

Isn't it also true that one-on-ones are a bunch of time that the manager is
spent with lesser coders, and it's a time-saving measure to cancel one-on-ones
so the manager can write more code?

~~~
Tinyforebrain
There is usually a few HR hours put into every interview, plus you are adding
1-6 more people at various levels of the company who might be a part of the
interview. Most of the people doing the interview don't have any real training
in it, and don't do it as part of their job. They may do ten full interviews
to hire one person(Or more). So yes, their time is more valuable because more
people and more hours are involved. The cost for hiring a person, in time and
resources, is the sum of the costs of all 10 of the interviews.

~~~
geofft
Isn't the point of interviewing that you gain an entirely new person on your
team, who is contributing some 2000 hours per year to your team and hopefully
staying for at least a few years?

Even if you measure in hours and assume all hours are equal (i.e., you're
hiring people equal to you, not people better / more skilled in certain areas
than you), the cost of hiring a person is about three orders of magnitude
_smaller_ than the expected benefit. Interviewing (and doing a good job of it)
is roughly the most impactful thing you can do at a job.

If your company doesn't believe this, doesn't train people in interviews, and
doesn't define interviewing to be part of people's jobs, I really have no idea
why I should think you're well-managed. (I'm entirely serious. I don't know
where you work, but you should get out before it breaks your brain further.
I'm still recovering from the ways my previous employer broke my brain in
regards to how software shops should work, and it's been a long while since I
worked there.)

If your company doesn't define interviewing to be a part of the job
description, do they define code review? Training? Mentorship? Management? Or
is everyone expected to just write code?

------
kafkaesq
Yup, it's become common enough, sadly.

And the fun part is that it's more than common (i.e. it happens at least 50%
of the time) that they _significantly_ botch either (or both!) of the written
work scope, or the platform configuration / test data -- or simply don't
budget (quite) enough time to get the thing done, given the ambiguities --
such that you, in turn, either: (1) burn significantly more time, energy and
adrenaline to slap something halfway reasonable together on their insane
timelines (knowing full well that it would never be up the quality standards
either of you would prefer for an actual, real business project); or (2) find
out at the end that you just can't deliver (because what they wanted was
physically or logically impossible to begin with.

And if you happen "fail" because of (1) or (2) well then.. so be it. I mean,
you'd think they could have simply dogfooded these assignments on their own
people first, before asking strangers to, in effect, dogfood these project
descriptions for them (on their presumably worthless time). But if you think
about it from their perspective, the second option (using the first few
candidates as free dogfooding labor!) is obviously much more attractive.

In theory, these projects _can_ work as intended -- if designed properly. The
problem is that (being human beings) the people who come up with these "tests"
tend to greatly overestimate their ability to do that. And if they burn out /
egregiously annoy a few candidates in the process -- leaving them with a
permanently negative view of their company (or at least the hiring manager
that sent them on that wild goose chase) -- well "so be it".

------
josephorjoe
Yeah, I've seen these. I had one that involved essentially creating a front
end app to retrieve data from a 3rd party api, parse the data, and display it
on an html page with interactive controls to let the user filter the data.

So, an HTML/CSS/Javascript test proving that you know how to make an api
request, play with data, and set up event handlers.

Which is fine, I suppose, except it was with a 2 hour limit and you had to
code everything via a web interface (hackerrank maybe?).

I found it super annoying to work outside of my editing environment without
any of the linting tools that I'm use to working with and without even source
control to record good commits to jump back to if things went wrong.

The task itself was not particularly hard, but I had to work very fast, didn't
finish the last filtering options, and had no time for design -- everything
was default html with a few primary colors thrown in here and there.

I don't mind a time-limited coding challenge, but not letting me use the tools
I use every single time I code (and would use if I were hired to work there)
was very frustrating.

------
yladiz
As some other commenters mention, and I feel the same way: if a company asks
you to do this, they're asking for too much and I think it's fair to tell them
that that is an unacceptable amount of work for an interview. I can kind of
see this as fair only if you are going in as a more experienced dev but with
no work examples, but in that case, it's simple enough to contact references
to verify previous work and positions. The only reason I would do this during
an interview is if they paid me for my time, essentially treating me as a
contractor for some period of time, and the time frame was large enough if I
was currently working. If a company asked for this without offering to pay, I
would decline the interview.

One additional thing to consider is that if you do work like this for an
interview, you should explicitly request to keep the copyright to the work in
case they don't give you the job, so you can showcase to other prospective
employers. A simple way to do this would be to request them to review it on
Github or Gitlab.

~~~
turc1656
I understand what you're getting at here - the request/requirement to jump
through hoops. But I don't think it's unreasonable for a potential employer to
want to gauge technical ability, especially given the amount of people who
graduate from degree factories without any ability to actually code or do any
sort of technical work.

Usually these positions, and this field in general, pay well so I would think
that people would want to go the extra mile to get the job. Also, you need to
remember that employers take a risk with every hire. The cost of hiring and
onboarding (and firing, too) are not insignificant.

If I was involved in the hiring process and someone expected to get paid as a
contractor for their time spent as part of the interview process, I would not
be calling that person back. If, however, a person expressed their displeasure
at the amount of time it would take to complete the request given their
current workload and schedule, I would probably be willing to work with them
and try to figure out some middle ground that would serve both sides
reasonably well. Of course, you also always have the ability to tell them that
you think it's too much to request as part of the interview process and do not
wish to continue the interview process as it would be a waste of everyone's
time.

Given the hiring risk(s) and costs associated with it, I think it's extremely
distasteful to seek to be paid as part of that process.

~~~
yladiz
If I'm asked to do more than a few hours of work for an interview, I expect to
be paid for my time. It's unfair and disrespectful that an employer would ask
for a large amount of time (like the requirements in the post) without paying
for that time. Of course there are ways to be tactful about it, without
directly stating it, but it's not unreasonable to get paid for a large amount
of work.

------
tracker1
I once designed a fairly simple code test as part of interviewing, requesting
that the code in question be added to a public github repository. The code in
question needed to be in node/javascript, read an xml file as a stream, and
output a json file (newline separated json)... I then did the challenge
myself, it took a couple hours.

To me, it represented enough of a system that I could see how a problem was
broken up. I also wanted to see some insight as to using npm, determining a
package(s) to use and then that they used streaming not read it all into
memory... as this can cause issues with really big files.

Only 3 people actually returned any code, and only 1 half worked. Amazing how
many people will label themselves "expert" and can't figure out how to read in
a file, as a stream or otherwise.

\---

Edit: Additionally, we were not trying to outsource interview work, but the
task itself was something we were doing similar things with as we were
actively migrating to a new database, and there was a lot of conversion tasks
underway in support of this.

~~~
bbcbasic
Curious: Why do you use JS for such things? Seems like a job better suited for
a workhorse like Java or C#. It would be much easier and I think C# or Java
devs would find it easier by virtue of that being a typical back end app that
they would have developed before.

~~~
tracker1
Well, the new software was being developed in JS... the front end/back are
easier to tightly couple with less disconnect when working on the system as a
whole. The benefits and cons of such a system can be argued, but that was the
direction that was being taken.

As to doing migration chores in JS, well, I actually would much prefer a
scripted environment for such tasks... in the end it will run several times
through testing, and one final time and thrown away. It's far more productive
to do this in a scripted environment than to have to write a bunch of
boilerplate that will just get tossed anyway.

JS specifically, as it's a very broadly supported language, the only/main
language in the browser and a heavy investment for modern web applications. As
stated above, leveraging a single language as far across a stack as possible
has benefits. As someone who has previously had to work with 5-6 languages in
3 stacks on a daily basis before (new and ongoing projects), JS everywhere is
much nicer.

------
latchkey
This trend is a bit over the top, but I can see why it came about. Other
industries have a way of evaluating talent. Artists can usually point at their
artwork. Some developers have taken to using Github as a public forum for
their work. How do we evaluate engineers in a consistent fashion?

In an effort to open a few minds to new possibilities, I wrote a medium piece
(picked up by HackerNoon) around my experiences with hiring software engineers
in San Francisco (you can find it if you look at my profile here). We tried to
rethink the process and use pair programming to help reduce interview stress,
properly evaluate candidates and make a generally more enjoyable experience.

At the end of the day, it is hard enough to hire good people in a competitive
market. Making candidates jump through hoops seems like it only creates more
frustration. Do you really want someone's first opinion of your company to be
less than positive?

------
latortuga
Ask an endless series of questions about algorithms and/or expect extensive
whiteboard coding -> developers complain about these not reflecting the real
world.

Ask a developer to write some actual code to prove that they can do the job
they're being hired to do -> developers complain about having to demonstrate
that they can do the job they're about to be hired to do.

There's a legitimate question here about how extensive of a project is
necessary to demonstrate that you can, in fact, write code effectively. But
this is basically what we've been clamoring for for years, companies
abandoning pressure cooker interview room gotcha-questions on whiteboards.

The work sample test is one of the most effective ways of evaluating a
candidate's fitness. What do you expect an prospective employer to do to
determine if you can do the job, if not write some code?

~~~
turc1656
Yes! Exactly how I feel.

------
mnm1
Is it more common? Probably. But you know what's also more common? Companies
asking for such work and then turning around and saying "sorry, we don't have
time to even look at your work."

Fuck these companies that ask for shit like that. Since we can't even hold
them to the most basic standards of decency, fuck them and fuck their
interview process. Seriously, there's no nice way to put this. Either pay for
such work or fuck off. So in other words, pay or only fools will apply. (Yes,
I have been a fool myself in the past.)

------
majormajor
There's a big caveat to this story in that I already had another offer I was
considering, but I walked out of an onsite where they wanted me to do
something similar, but on top of a skeleton project in an IDE running on their
own laptop that they provided. But then, after sitting there for a full hour
watching their dev try to figure out why the environment wasn't reset properly
after the last candidate, and not being willing to have it run late and cause
my flight home to be at risk... I decided to just leave.

~~~
WorldMaker
I have a long story of an interview I regretted where they talked me into
spending far too much time building a skeleton application onsite, and in
retrospect I know I should have just walked away as soon they tried setting up
an IDE environment. I'm more likely to consider that a red flag in the future.

------
julik
It is ubiquitous, but we normally do a slightly different thing:

* The thing you do is a very narrow fix / feature * ...on our open-source library, so you get the credit and visibility * ...with a very defined scope * ...which will usually force you to Google/SO search quite a bit.

Since we are not remote, for way-overseas candidates it's pretty much the only
thing we could do. We use it to assess fizzbuzz as well as style and the
ability to contribute to an existing project, as well as communication and
accepting/giving critique.

It's not very easy to establish - the company needs to have open-source
presence in the first place. It's certainly harder than just having someone do
a throwaway full-stack app. But for us it did work very well. The best filter
was not even people doing something "not well enough" but people just agreeing
to take the assignment and then disappearing.

------
jorgemf
I don't mind to do any code test a company requires, but I expect the same
commitment on their side. They are looking for candidates and don't want to
waste time, but if I am looking for companies I don't want to waste time
either.

Usually they ask for a test to asses my skills, but if I am already in the
industry I have similar projects I did in my free time that we can use to
discuss. I dislike to repeat the same test other candidates have already done
if there isn't a good reason. Asses my skill by fulfilling your expectations
with your test is not the way go in my opinion. If you are looking for talent
to bring new skills to your team, definitely you cannot get them if you are
looking for the skills you know. It is better to have an open conversation
about something the candidate has done that have some impact.

------
tuxidomasx
When I interviewed with Toptal, once I made it through the preliminary
screenings, the final test was to build a simple web application over the
course of 2-3 days in a language of my choice, and commit the code to their
git repository, and demo it live.

I finished it in a day and a half; decided to use Meteor since I never used it
before and figured it'd be a good time to dabble in it.

It was by far the most enjoyable part of the application process. And I think
its the best indication of a developer's ability. Real-word application of the
knowledge that you will probably be using 90% of the time (as opposed to
theory and logic puzzles).

------
sidlls
I've never seen this. I would also simply ask if there were an alternative
interview process. If not, I'd politely decline to continue. This sort of
interview seems like it's better than algorithm bingo on the whiteboard. In
reality it's either an attempt to get free (or discounted) work or else
contrived and therefore still removed enough from the actual day-to-day of the
job as to be less than useful as a measure of fit and ability.

------
codys
I have not seen this while interviewing in the Northeast US.

~~~
lj3
Where in the northeast? Because NYC companies are absolutely doing this right
now.

~~~
codys
MA (near Boston), NH, CT.

~~~
lj3
Good to know. I've always been interested in New Hampshire.

------
20years
I personally think these types of coding projects are way more effective at
determining skills than whiteboard or fizzbuzz type stuff. It also opens up
opportunities for you to discuss the solutions you used with the hiring
manager.

Now if they are requiring you to spend more than 2 to 4 hours on a project,
that is unacceptable imo unless the hiring company is willing to pay contract
rates for the time.

------
ctogden
I don't mind this (provided the request is decently specified and scoped),
because I find interviews stressful and often pointless and work sample tests
are (or should be) higher signal, but if I'm going to do a work sample test, I
don't want to then have several phone or onsite interviews as a followup.

Ideally, when I'm given such a test I should be able to predict my success at
completing it well enough to know whether it is worth my time. There could, of
course, be unforeseen problems, but I should be able to judge the likelihood
that spending the time to complete the exercise will get me the job. This
means that cultural expectations are expressed up front. Do you expect the job
applicant to adhere to your company code style guide or expect unit tests? I'd
assume the latter is a frequent expectation but it doesn't hurt to mention;
practices vary greatly from company to company so a reminder could be useful.
Or maybe you write a lot of functional JavaScript on your team, and want to
know if a candidate is familiar with that style. If you reject a candidate
because they didn't match your preferred style but didn't ask for that, you're
likely wasting my time and yours.

------
alaskamiller
3 years ago, when I was hiring college-level hacker kids we would just ask the
to hack out a web app (with or without our API). This was when dev boot camps
were taking off and asking them to just build something was actually a much
better understanding of them than white board tests.

------
orbitingpluto
I applied at a company that I assumed had at least 40+ people (assuming normal
turnover) because of the frequency of job postings. Turned out they had 4
employees. And they wanted me to create a full application before I was given
a second interview. Nah.

------
pluc
It's been my experience - at least when it comes to remote positions and the
ones posted on HN's Hiring threads and all the remote boards.

------
borplk
I don't have that much experience but for what it's worth I have not heard of
or seen that. That seems a bit bizarre to me.

------
zebraflask
They want free work. Simple as that.

~~~
rrix2
When the coding sample isn't integrated at all in to their stack and is a
standalone toy application? Come on.

~~~
zebraflask
What can I tell you, it does happen. The idea is to farm out code that can be
lifted from the toy app with minimal modification. In any event, even if the
intent were benign, that's way too much to ask of an applicant without paying
something for the time.

------
rgbrgb
I think there's been enough rancor about whiteboard interviews that people are
looking for a better way. I personally was never very good at on-the-spot
whiteboarding even though I'm decent at building stuff, so my company's
interview process incorporates a take-home coding challenge. It's not as in
depth as deploying an app but it tends to take a couple hours.

I can't imagine paying someone to interview though. Both parties are spending
time (and money) on the interview already and if you don't want the job enough
to put in a day getting it, to me that's a signal that you wouldn't be very
interested in the problems we're working on.

I do sympathize though and agree that interviews still suck (for both sides).

