Ask HN: Is it now common to ask for “full” applications as part of interviewing?
- 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)
76 comments
[ 288 ms ] story [ 1783 ms ] threadDoesn'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.
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 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 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.
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.
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.
[0] https://www.reddit.com/r/cscareerquestions/comments/6bvmpf/a...
Struck me as extremely rude.
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".
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.
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.
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 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.
How many candidates with small children do you think these companies are hiring?
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.
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)
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.
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?
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.
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.
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.
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.
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.
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.
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.
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.
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...
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.