6 ms·
Ask HN: Is it now common to ask for “full” applications as part of interviewing?
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)
- kcorbitt 9y agoMy 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.
- lj3 9y ago> then forces every applicant to spend 5-10 generally unpaid hours completing it. Multiply that by 4.
- JosephLark 9y ago> 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.
- Bahamut 9y agoThis 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.
- davidbanham 9y agoTake home challenges without an enforced time limit are awful. You need confidence as a candidate that you're competing on a level playing field.
- turc1656 9y agocompeting 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.
- falcolas 9y agoIt'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 9y agoI'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.
- thegreatco 9y agoThis 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.
- codys 9y agoI have not seen this while interviewing in the Northeast US.
- giobox 9y agoIt'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 9y agoMaybe 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.
- majormajor 9y ago> 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.
- _dark_matter_ 9y agoThere 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/are_technical_tests_like_this_one_common_or_just/ https://www.reddit.com/r/cscareerquestions/comments/6bvmpf/a...
- borplk 9y agoI 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.
- swalsh 9y agoThese 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.
- alaskamiller 9y ago3 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.
- zebraflask 9y agoThey want free work. Simple as that.
- rrix2 9y agoWhen the coding sample isn't integrated at all in to their stack and is a standalone toy application? Come on.
- zebraflask 9y agoWhat 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.
- kafkaesq 9y agoYup, 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".
- dboreham 9y agoThere 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.
- vorpalhex 9y agoI'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 9y agoWhat 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.
- deleted 9y ago[deleted]
- hartator 9y ago
- sidlls 9y agoI'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.
- latchkey 9y agoThis 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?
- pluc 9y agoIt'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.
- majormajor 9y agoThere'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 9y agoI 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.
- tracker1 9y agoI 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 9y agoCurious: 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 9y agoWell, 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.
- josephorjoe 9y agoYeah, 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.
- jorgemf 9y agoI 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.
- mmcconnell1618 9y agoI 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.
- derekp7 9y agoThis 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 9y agoWhilst 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 9y agoIf 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.
- yladiz 9y agoAs 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 9y agoI 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.
- mfrisbie 9y agoTake 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-chamber#takehome https://alwaystrending.io/articles/tech-interview-torture-ch...
- ctogden 9y agoI 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.
- orbitingpluto 9y agoI 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.
- latortuga 9y agoAsk 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 9y agoYes! Exactly how I feel.
- rgbrgb 9y agoI 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).
- tuxidomasx 9y agoWhen 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).
- Tinyforebrain 9y agoCompanies 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 9y agoIf 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 9y agoThere 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.
- 20years 9y agoI 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.
- bogomipz 9y agoMy 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.
- mnm1 9y agoIs 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.)
- julik 9y agoIt 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.