9 ms·
Take home tests FTW. The thinking goes as follows: 1. If the candidate can't be bothered to complete a 2-4 hour (depending on claimed seniority) code test in t
by maxaf 11y ago
Take home tests FTW. The thinking goes as follows:
1. If the candidate can't be bothered to complete a 2-4 hour (depending on claimed seniority) code test in the language of their choice, we can't be bothered to talk to them.
2. If the candidate does reasonably well by completing the code test somewhat on time (with a fat margin allowed for them, well, having a life) and within parameters of the task, they're invited for a mostly non-technical onsite meet-and-greet.
3. During the meet-and-greet we make sure that the candidate isn't an axe murderer, is able to hold a quasi-technical conversation, and that both sides aren't immediately scared of each other.
4. The meet-and-greet can also include some low-key architecture discussion. Any nerds worth their salt will be able to conduct this line of questioning without making it obvious that an interview is taking place. Hopefully this isn't a critical step, as a good take-home code test will require the candidate to spend a little time designing or architecting their solution.
After the above has taken place, it should be pretty clear whether the candidate in question is a fit or not. Note that this process is by design missing the useless traditional CS questioning component, contrived problem solving exercises, or a whiteboard code beatdown.
- kafkaesq 11y ago4 hours is a lot of time out of someone's day, and a near-dealbreaker for anyone gainfully employed and having some semblance of a life. Do you not realize this? Meanwhile, it really doesn't take long to find out if someone is "worth talking to." Ask them to provide a code sample, and talk to them about for 10 minutes or so. Or if you must use a coding exercise, really, just keep it short and sweet. A good coder can show you a lot about their sensibilities in their solution to even just a slightly non-standard sorting problem.
- tiglionabbit 11y agoYou need to verify that the candidate actually did the take home test, and didn't hand it to their more talented friend.
- Peroni 11y agoThat's why you get them to talk you through their process during the face-to-face interview. It'll be immediately apparent if they didn't do the work themselves.
- maxaf 11y agoOne of the best interviews I've had as a candidate (didn't get that job - it's the one that got away) involved me explaining design choices I made while implementing my solution to the take-home test. That was a great discussion, and didn't feel like the traditional interview-style questioning.
- jghn 11y agoWe ask candidates to submit code samples of their own choosing, or if they have nothing that they can supply for whatever reason we give them a short challenge which is only used for generating code to review. We bring them onsite and review the code and have them walk through what's going on. If they just blatantly copied stuff or handed in someone else's code they won't be able to stand up to scrutiny. And if they really do know it inside and out they probably could have written it anyways. We've had a small number of candidates who tried to pull a fast one but very very few
- maxaf 11y agoThat has always been a concern, but in practice I've never seen this happen. Even for common-ish problems (Dijkstra's algorithm, GCD, chess) I've seen many, many diverse solutions that were obviously hand-coded by the candidate. I recall once we've suspected plagiarism based on a Google search. If my memory serves me right, we rejected the candidate and moved on.
- t0mbstone 11y ago"plagiarism based on a Google search" Uh... If the solution is readily available on Google, and they can solve the problem effectively with that solution, then they didn't plagiarize. They operated exactly the way they should work in a real world scenario. The worst kind of employees are the ones who insist on re-inventing the wheel every chance they get, instead of using industry standard libraries.
- maxaf 11y agoIt was worse than what you describe. It was literally a wholesale copy/paste of a related but not-quite-right solution. The code test involved designing a data model for chess, but the candidate took an implementation from elsewhere that didn't give us the opportunity to evaluate their modeling skills (i.e. "I will create these classes with these fields and connect them like so").
- elliotec 11y agoThat sounds like an excessive test. What kind of code are you guys writing? Why is it not okay for him to use implementations from elsewhere? Should he really reinvent the wheel to try and impress you? Reminds me of the time I got asked to write a merge sort algorithm in Ruby. I wrote array.sort! on the board, the interviewer told me I have to rewrite it from scratch, and I was done with the interview. Because we create abstractions and reusable implementations for a reason.
- tiglionabbit 11y agoUnderstanding how mergesort is implemented can be useful. I've had interviewers ask me to sort a data set that is too large for a single hard disk to contain. Mergesort is like map/reduce; it can be distributed.
- kanwisher 11y agoI assume the take home test is after you have talked to them? I wouldn't spend multiple hours unless it was already clear there was some desire to move further
- maxaf 11y agoThis kind of depends on where the candidate is coming from. Those who're applying directly are obviously already expressing some desire to work with us. Recruiters should be instructed to give a consistent narrative, too. Good recruiters will also pitch the code test as a sign that we're a serious employer and take people seriously. I don't like phone conversations that serve as the first line of candidate triage. Many big-company HR departments will have engineers phone screen anyone who sounds marginally suitable. This is soul-crushing, pointless busy work. My personal rejection rate of such candidates is somewhere in the 90-95% range. These are cold leads, not candidates. They should be taking the code test before talking to anyone in engineering.
- Retric 11y agoA 4h test when your still rejecting 90+% of people is ridiculous. You are basically rejecting anyone that is talented ahead of time. I personally know two programmers that did not create a resume for 20 years and still got jobs offers. Remember anything more complex than a phone screen is going to start turning people away.
- maxaf 11y agoThe 90%+ rejection rate was at a BigCorp that refused to give people code tests ahead of a technical phone screening and onsite interview.
- sheepmullet 11y agoYep, I have gotten my last three jobs simply by strong recommendations. A 4 hour test and 90% rejection rate? I better know you are paying at least double market rates before I start it!
- leeny 11y agoThese can be great. Provided that they're not used as a first-pass filter and provided they give some insight into the work the person will actually be doing. Because otherwise you're going to lose a lot of talented people who can't be bothered, especially in this market.
- ffumarola 11y agoIn a recent job hunt, I found cases were used as an excuse for the company to invest 0 time in the process. It was so bad that with one company (a unicorn, if it matters) I replied with a bunch of questions that I had to fill out the gaping holes in the case, and they instead opted for an in person to avoid investing the time in the replies! In two other cases, they requested 4-6 hours for a time commitment. I told them I was incredibly busy and was more than happy to put 1-2 hours into the case and return it as a work in progress. Both company's said to put as much time as I wanted into it, but then decided that the case wasn't complete enough to continue. This last round taught me that I won't do cases as a first pass filter as a matter of principle. If you want me to do a case, invest time in me first so that I know we both have skin in the game. These cases are really just optimizing for people with more time than others.
- eropple 11y ago> 1. If the candidate can't be bothered to complete a 2-4 hour (depending on claimed seniority) code test in the language of their choice, we can't be bothered to talk to them. The approach you describe strikes me as shortsighted as well as to no small degree selfish. I don't do take-home tests, as a rule, for one overriding reason: my time is too valuable, and I have so much less of it to expend in discretionary fashion than any potential client or employer, to spend it on a one-way interaction such as a coding test. I have a Github profile with more than enough stuff on it to demonstrate proficiency in some areas and mastery in others, and I learn nothing about your company by completing your test that will help me better understand if I want to work for you. If I really want the gig, maybe then I'll do a little additional work to demonstrate, in good faith and after you have likewise established that you are acting in good faith and aren't just cattle-calling me, that yes, I'm interested. But before? No way. Your company is just not special. Conversing with a potential client or employer, on the other hand, is a two-way street. I learn things useful to me both in terms of deciding on a gig and things that are more generally useful, like the war stories that inevitably get swapped during those conversations. It helps me decide whether your company is worth it to me and, right now and in this market (for clued-in people), that's the biggest question: not "do we want this person to work for me?", but "do I want to work for this company?". Not operating with that in mind seems like a very, very poor idea to me.
- darryl42 11y agoHow do you feel about the all day interview process some large companies are currently using? Keep in mind you probably had 1-3 phone + computer interviews before the in person interview. A take home test seems like a less time intensive process as you at least don't need to take time off from your normal job to do it.
- dannyr 11y agoIn addition, Take-home test is better because it is more flexible than an in-person or even phone interview.
- eropple 11y ago> How do you feel about the all day interview process some large companies are currently using? I don't go for the all-day ones (I just decline; after my last Google interview I'm done putting myself through the wringer for a whateverjob), but I really do enjoy in-person interviews. Like, last time I was looking for a FT gig I did at least a phone interview at 35 places and an in-person at 20. I enjoy interacting with people. I get a great lay of the land of what the market looks like, what's not just "cutting edge" but what is, in practice, the leading edge of what people are actually trying to use in anger. This is, in addition to just learning about a given company, why I view in-person interviews as a two-way street. After my last FT company shuttered, I moved into consulting largely because I have a better view of the world than most people working for individual companies. I've learned, from talking to a ton of people, many things that might even seem like offhand facts from idle conversation that have helped me. Like, I happened to remember that D3 instances exist in AWS from a chat with somebody on one of those interviews and in the process I saved a client $20K/month in EBS costs. Maybe it's a Shockingly Minority Viewpoint, but I think that, in a healthy business relationship (and it's important to realize that employer/employee is a business relationship), both sides get something, even if it's the short relationship of an interview.
- CryoLogic 11y agoI was bummed out recently when I did a take home test for a local start-up, which asked me to build a full web app. I spent 4-6 hours on it making sure it was perfect - just to turn it and and get told I did a great job but they decided they didn't really want to hire any non-senior engineers and where just testing the waters. This is happening a lot in Seattle recently - the job market is here is terrible for anyone except senior devs (which it is great for!).
- maxaf 11y agoPoor execution doesn't invalidate the idea. Happened to me too, although on a smaller scale. 4-6 hours is a bit much for a take-home evaluation project. If it can't be reasonably done by a distracted person in 4 hours, it's too hard/too long for a take-home test. Hopefully people will learn to do this right over time. Or, someone might solidify a common platform for doing this, a-la HackerRank or any of the other similar services.
- robryan 11y agoI would be surprised if a well constructed 2 hour test wasn't able to give you enough information on their structure and approach. 4-6 hours probably results in the candidate filling in a lot of basic details to get something to actually work that will tell the interviewer little more than the 1-2 hours spent implementing the core parts of the task.
- vonmoltke 11y agoPoor execution doesn't invalidate the idea but it does hurt its effectiveness by making candidates gun-shy.
- chrisper 11y ago>1. If the candidate can't be bothered to complete a 2-4 hour (depending on claimed seniority) code test in the language of their choice, we can't be bothered to talk to them. A good reason not to work at your company. Why would I want to invest 4(!) unpaid hours into something where I am not even considered seriously yet? I recently had a coding challenge, which was not only vague, but also took up two hours of my time. The end result was... nothing. Not even a "thank you, but we chose someone else." Since every then, I chose to not bother with long coding challenges anymore.
- deleted 11y ago[deleted]
- maxaf 11y agoWould you have preferred to spend a whole day on an inconclusive onsite interview? Or perhaps a phone screen during which you're asked to implement a hashtable for the umpteenth time? As I said in another comment somewhere in this thread, one day people will learn to do this right. Hopefully this will happen before programmers as a profession have decided to never take code tests again.
- chrisper 11y agoYou are right with that a whole day onsite interview is more time consuming.But personally, I think I can do better in a face-to-face evaluation than on a coding challenge where I have to guess the test cases from some vague description. In fact, face-to-face can show the interviewer how I think and what kind of questions I ask to figure out the way to solve an issue. Maybe it is my lack of interview experience, since I only had like 3 or 4 so far, but I only 1 out of them left me with a good experience after the coding challenge (even if I did not get an offer yet).
- hire_charts 11y agoPresumably you (the employer) have less time to do on-site interviews than to assign take-home projects, so landing a real interview is a much better indicator that my (the job-seeker) time will be well-spent. (Hiring is a two way street.)
- rm_-rf_slash 11y agoStartup A asked me to do a take-home programming challenge to prove my skills, as well as a general algorithm test to give them ideas how to run their core architecture. This took hours, I felt I was being asked to do their job for free (on the second test), and the results were pathetic. Startup B gave me an assignment to add a feature to their API and have my work merged with their active code base. I was compensated $300 for my time. The feature worked, although I don't know if they still use my code from 3 years ago. In the end, I worked for neither. But if I were forced to choose between them, I know my answer in a heartbeat. Will name companies if requested.
- superuser2 11y agoOption B is explicitly prohibited in your employment agreement for most salary workers. I would never consider working for a company that required me to violate a contract just for a chance to work there.
- eropple 11y ago"Most"? Anecdotally and all that, but I never signed a contract that stated that, across ~5 jobs. One tried and I got it redlined out before I started.
- kasey_junk 11y agoAnecdote to add, I've never across 20 years experience (and many jobs) not had a moonlighting clause in my employment agreement. As someone who hires, I'd be worried about the IP implications of even suggesting I pay them for outside work prior to them leaving their prior commitments.
- eropple 11y agoHuh, interesting. I think I'd just walk if presented with a firm one. I constantly have other things going on, even when FT employed, and honestly no employer is going to pay me enough to constrain my options.
- adregan 11y agoI have been interviewing quite a bit lately, and I have found that my favorite interviews are take home tests that are representative of the kind of work I would be doing at said company. I am more comfortable with that style and I perform better. More than that though: it gives me an idea about what it will be like to work at the company. If my only experience is studying algorithms and coding on a white board, I have a hard time knowing whether or not I will enjoy working at this company for years of my life. A promise that you can work on "interesting problems" is hardly enough. I'm curious why more companies don't take the opportunity to sell themselves. Anyhow, I've hung a whiteboard in my room and try to practice for interviews as much as possible. It's incredibly draining and produces a feeling completely opposite to how much fun I have building things. This feels like getting started on the wrong foot.
- WorldMaker 11y agoI honestly feel like take home tests are "busy work" and just as volatile as any other sort of technical interview for showing actual skills versus a real world environment. 2-4 hours is a lot of time to ask of somebody, regardless of their circumstances. Would you pay a contractor's salary rate for that work? Are these take home tests results worth $100/hour? $40? Every take home test I've encountered I've wished someone would pay me for that time, based on the opportunity costs of what I could have been doing, but maybe I'm cynical and pessimistic.
- accraze 11y agoDuring my last job hunt, I had an 8 hour take-home assignment that could be finished over the course of a week. They paid me $400 to do it and all I did was send a PR with some refactoring on an overgrown controller. I wound up not taking the job, but I remember being really impressed with this process and wish more companies would value a potential new employee's time like that.
- kasey_junk 11y agoAs a huge proponent of work sample hiring, if it were at all feasible in the jurisdictions I hire in, paying someone a couple hundred dollars on completion of a take home test, I'd do it. But the vast majority of the developers I want to hire are encumbered by moonlighting clauses that would likely cause them major personal issues if we violated them. Seems a bad way to get on the appropriate footing with a potential new hire.
- ChemicalWarfare 11y agoI do agree that "homework" type tests are the way to go. The only caveat is - someone needs to be REALLY interested in working for you to do this as a first step. A 15 - 20 min conversation with a hiring manager or an HR person if you have HR :) to cover things like the specifics of the position, candidate's 5 min summary of their career, approximate compensation, etc as a first step. Then you decide whether you like what you've heard and the only thing standing between the applicant and the offer is the completed assignment.
- deciplex 11y agoDespite what others are saying here I think take-home tests are a great idea. What is a terrible idea however is requiring that a candidate complete your take-home test, that you wrote and will administer. It is simply not reasonable to expect a candidate to complete such an exam for every company he applies to, oftentimes before he even talks to a human being and usually before he has a face-to-face or a phone interview with an engineer. There simply aren't enough hours in the day, even if you're unemployed. And there aren't, to my knowledge, any really good and widely-used sites that a prospective job-seeker could use to establish his skills, which any random company likely will look at and accept as canon. And so we're all in a bit of a bind.