Ask HN: Is it now common to ask for “full” applications as part of interviewing? | Hacker News Reader

Ask HN: Is it now common to ask for “full” applications as part of interviewing?

39 pointsFuturebot73 comments

Three companies (out of ten or so) I've interviewed with recently have all asked for something similar to the following:

- code

- integration with a third-party API

- installation of a number of third-party libraries (and the reading of their documentation)

- complete documentation for the code

- a test suite

- deployment instructions

The companies in question vary in their industry, tech stack, and focus.

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/organizational skills c) style

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'm being asked for things this complete and specific.

(As an aside: are we finally near the point where companies should consider paying developers to interview if they're going to be asked to spend the day coding, writing tests, and writing documentation? I.e., do free work)

View on HN

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".

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.

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.

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.

I've done several of those. I think there is a luck factor involved. One company asked to pick a language I didn't know before end, it was just okay - because I truly didn't know the language before. Another picked a maze puzzle that I thought was fun, and I did it well. Anyway 4-6 hours is still a lot of time, specially when you have a resume + github that is showing you should already know your shit. You can false positives and false negatives very easily with a test like this. I think the best approach is to select 3 candidates based on feeling/resume/github/etc, give them a true piece of code to wrote that will be used for real. Give them a week, but pay them real money. Hire the best.

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.

Similarly, I've had a couple of these where my response is a detailed discussion of why the problem given was at least NP-Hard, and here's a good academic paper on the trade-offs of the most popular algorithm, which would take me a good several days to implement correctly (or even better here's this trusted open source implementation of it). To me, that feels like that research was a better use of my 4 hour block of time, but yet I've gotten feedback that I must be a crap programmer if I'm not going to waste 4 hours brute forcing my way to an unsatisfactory answer.

I don't know how some of those companies work, but I'd much rather work smarter than harder and step 1 in the real world, to my judgment, is often "research the problem and see how other people solved it", whether that's via academic algorithm research papers or StackOverflow depends on the type of problem.

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

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

4-6 hours is still half to two-thirds of a business day. If I'm actively employed, I have to schedule a vacation day for that or lose precious work/life balance time. Even if I'm not actively employed at the time, I know the ancient wisdom is to spend your job search as if it were a full time job, but that isn't advice meant to mandate individual candidate employers independently force you into an unpaid, overworked internship of an endless stream of variations of building useless applications.

Such a company is also selecting for the sort of candidates who have 4-6 hours free, either those who have no responsibilities at home and are willing to spend an evening or weekend on it, or those who have enough ability to take a vacation day and tell their boss "I'm going to be at home doing nothing." You basically need to do that for the in-person anyway, and there's a limit on how often you can do that.

How many candidates with small children do you think these companies are hiring?

This works --- really well! --- when the homework meaningfully offsets both the in-person interview and phone screens. When it doesn't, and is just a ceremony the hiring team performs on most (it's never all in these cases), it's abusive.

The problem is that a lot of the teams assigning these projects don't really believe in the projects and haven't put the effort in to deriving a rubric they can use to reliably condense candidate responses into hiring signals. Without that work, and without a process built in good faith to use that work, this is just cargo cult management.

This works very well. We use it throughout the company, more so in some places. I have done this with security engineers, and to my pleasant surprise, with compliance candidates as well. It has exceeded my expectations.

This seems fair; the last time I did a take home I was asked to build a complete application (full stack) in 2-3 hours. At the time I viewed this as a failing on my part. In retrospect, I feel this is unreasonable on its face. Through the grapevine I've heard that the position has not been filled more than a year later, so I can't be the only one.

I designed two of those challenges. We're successfully using it for international hires for quite some time now. We hand those out after you made it through two telephone interviews, which should assure mutual interest in actually making hiring happen. We base our hiring decision on the outcome of the challenge. If you do good, we relocate you and your family, care for everything you need. Our success rate is around 30%. So I wouldn't say we ask you to work for free. We designed the challenge to be without example on github by giving extreme amounts of individual freedom in the task. Also, you're allowed to share the solution - but without mentioning the company name, so that other candidates cannot just google and find your stuff.

Not everyone has a "significant" github profile. Actually the minority of people has such a thing. So many reasons for not having one. Current employer's policy, having a family, having non-IT hobbies, etc pp. Also just having such a profile doesn't necessary proof that you can solve the company's problems, because just looking at solutions of arbitrary problems doesn't give you any information about the constraints of the problem, how you solved them and it also doesn't put your solution to this problem next to solution of the guy sitting one desk away that solved the same problem in the same amount of time under the same conditions.

(removed a stupid passive aggressive statement here, sorry folks)

> Would you give me your product for free for a week? (Probably not...)

This is a good response. If they won't pay for your time, ask if they'll let you hang around their offices and teams, observing, for the same amount of time you've spent coding.

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.

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.

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.

We live in a time of dissonance between the two attitudes of "university is for learning how to learn first principles; if you want practical industry-relevant knowledge then go to a community college, you vocational student" and "businesses need to be fast and agile so we're not going to provide training; schools should be pumping out employees ready to be interviewed."

This is essentially what TripleByte is doing. It doesn't have a certification, but they put you through a general software engineering interview (with multiple parts). If you pass it, then they work with their partner companies to by-pass the initial screens and straight to the on-site.

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.

> then forces every applicant to spend 5-10 generally unpaid hours completing it.

Multiply that by 4.

> 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.

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.

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.

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.

> 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.

At least in the algorithm case once you've got enough (whatever your own definition of that happens to be) you can ramp down the studying and just go off of memory, and they'll apply to multiple different interviews. Here you're putting in a bunch of time for just one opportunity that you're not even sure you want yet - the interview is as much about the candidate interviewing the company as it is the reverse, which is where I'm inclined to say "no thanks" to a process like this as long as there are companies out there not doing it. Especially as one's career progresses and you have people who would trust you to refer you and so on.

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.

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.

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.

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.

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.

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.

Take home challenges without an enforced time limit are awful. You need confidence as a candidate that you're competing on a level playing field.

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.

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...

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.

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?

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.

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?

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".

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.

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.

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.

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.

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.

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.

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.

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?

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?

Yes! Exactly how I feel.

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.)

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.

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.

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.

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.

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).

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.

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

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

MA (near Boston), NH, CT.

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

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.

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.

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.

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.

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.

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.

They want free work. Simple as that.

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

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.

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).

Reply on news.ycombinator.com