Hacker News Reader

Comment by maxaf | Hacker News Reader

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.

View on HN

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

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

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

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

At least an onsite interview typically includes expense reporting lunch, if not dinner, and maybe an opportunity to visit a city or a part of city you are less familiar with and possibly even sight-see a bit.

I don't think a phone screen is productive beyond a half-hour to an hour and anyone asking technical implementations over the phone is likely a worse interview than trying to whiteboard things (and that's still far and removed from actual programming).

Yes. The onsite means the company is investing just as much time and effort into the process as the candidate.

It's not just the investment. In a 4 hour take-home I learn close to nothing about the company I am applying for. In a 4 hour on-site I see the workspace, talk to employees, etc.

So if they do well in the take-home test, you give them an offer? Or do they still have to do the all-day on-site after that?

Do well in the take-home test? Come in, meet the team, do the culture-fit thing. Then you get an offer. And this doesn't need to be an all-day thing. Who wants to keep selling the company to a candidate all day long? :)

People usually have a coffee date first, before doing dinner. Here, you're doing dinner first, and then lunch. The first pass should be minimal in commitment, and give both sides a chance to get to know each other. They pass fizzbuzz or something doable in 15-30 minutes, you have a short convo about the company, and then you move on to the second pass.

Those other things being unpalatable doesn't change code tests being unpalatable.

As someone currently preparing to interview with Google I'd take 4 hours implementing real code over a (recommended) 2 weeks of basic algorithms, data structures, math, etc. revision.

You strike me as the type who would also balk at fizzbuzz and other 'typical' interview questions. What do you propose? Say you have to interview a candidate for your own startup? How would you go about it?

I agree with the parent that take home projects (as the initial filter) are a non-starter. It's because they're flat out abusive. The employer uses their position to offload the cost of their hiring onto job seekers. The fact that our first interaction is exploitative couldn't be a bigger red flag.

However I am completely fine with fizzbuzz tests, even take home fizzbuzz. But this literally needs to be something that will take no more than 10 minutes, and for most people a couple of minutes tops. And in the question have a disclaimer: if this takes you more than 10 minutes to do, this won't be a good fit, so save yourself the trouble.

I actually don't mind the idea of take home projects, but only after significant investment on the part of the company. They need to have something on the line as well if I'm to devote significant time to it. Paying a good hourly rate for the time to complete it is the most straightforward way.

I actually like fizzbuzz and stuff like that. My most recent and best coding challenge experience was one from Cloudera. It was 2 questions and I had 70 minutes time in total. The difficulty was not something crazy. To me it felt like something you would get as a homework in Uni, but slightly more complex. I was able to finish it in 40 or so minutes and even had fun doing it, because I did not get frustrated by lack of details in the problem description.

But when a company sends me 2 hours on some weird platform that tells me 3 out of 10 test cases work, but doesn't tell me why or what even the input is, I just get frustrated. One of the worst coding challenges was asking me to implement the cd (change directory) functionality. But the details were so bad that I had no idea if I have to invest time or not into edge cases etc. I basically had to guess the test cases, but eventually failed the test since I ran out of time.

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

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

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

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

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

I assumed it was boilerplate. For the record I've also never had an employer have a problem when I notified them of outside work.

That might be different if the outside work in question was an interview for a new jib though...

In my experience this hasn't been the case. The closest I've come was an employment contract that required me to notify my employer of any work on the side. This has happened only once over more than a decade of work in this industry.

GitLab has an employment offer example up on their website¹.

Here's the part that's relevant to the discussion:

> While you render services to the Company, you will not engage in any other gainful employment, business or activity without the written consent of the Company. While you render services to the Company, you also will not assist any person or organization in competing with the Company, in preparing to compete with the Company or in hiring any employees of the Company.

I'm sure we can have both charitable and strict interpretations of "while you render services to the Company" but only a lawyer can probably tell what that means. Did you not have such a clause?

¹ https://about.gitlab.com/handbook/contracts/

I do not think we would make a problem if people did a paid technical interview somewhere else, it doesn't make sense to me. On the other hand it is hard to write an exception for this, but merge requests are welcome.

Are technical interviews work on real world problems, the work is not paid and the code is open source. You can opt for an alternative if you want, see https://about.gitlab.com/jobs/

"During your Employment, you shall devote your full business efforts and time to the Company. During your Employment, without written permission from the Chief Executive officer, or one of his direct reports, you shall not render services in any capacity for any other person or entity and shall not act as sole proprietor or parter of any other person or entity..."

As I understand it, this is pretty much the nature of being salaried (as opposed to hourly).

Wow, all I can say is that sucks to be you.

I work in higher ed now, and I can do whatever I want outside of normal hours, as long as it doesn't interfere with the work I was hired to do.

One benefit of having firmly rejected Silicon Valley is that I'm no longer at the whim of jealous employers who know I could find another job across the bay at any time and keep my home and social circles.

Most jobs at tech companies will have a clause in your contract about owning everything that you do or think of while employed.

This is true of work you do on company equipment during work hours. If things were as you describe, no one would ever be able to do open source, let alone sign standard FOSS CLAs or the like.

Don't over-generalize, both of the big tech companies I've worked at in the last 10 years have this clause and require _explicit_ specific approval for any outside work, open source or not. Otherwise, yes, according to the contract it is their property. The enforceability of this debatable, but it is most definitely something that happens.

Not in sane states (read: California).

Well, sane in this thing, at least.

I believe those clauses are completely unethical in the first place, so I wouldn't have a problem.

But you sign them and take money from the people offering them?

So? For one, I live in California, where those clauses are not enforceable. If they want to put illegal stuff in their contracts, that's not my fault.

Saying they are not enforceable & saying that they are completely risk free for a potential hirer who wants to pay a nominal payment for coding exercises are 2 different things, especially considering that conflict of interest laws are enforceable.

As for the ethics of it, I find it odd that you are fine with working for someone who uses something you are vehemently against, but hey to each their own.

What's the difference between Option B and onsite whiteboard coding? Aren't you violating your employment contract all the same?

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

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

In addition, Take-home test is better because it is more flexible than an in-person or even phone interview.

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

I love interviewing. Like, I'd do it as a hobby if I could. That said, my own preferences are not likely to be salient to the greater community of potential hires. So, I have to put them aside when designing hiring pipelines.

Having given this problem a lot of thought and experimentation, I've come to realize that designing good work sample based hiring pipelines is very difficult. Designing hiring pipelines based on something else is impossible.

Are you paying as well as these top tech companies? Do candidates know it?

Are you providing as many career opportunities and growth as Google/Facebook/etc? Do candidates know it?

These big companies get away with it because their hiring funnel is jam packed with top talent.

Rejecting a lot of top talent is no big deal for these companies. There is still tons of top talent who will jump through the hoops.

But a big hint: they won't jump through the hoops to work at your company!

I have one major disagreement with you:

> I have a Github profile with more than enough stuff on it

Based on my experience only, you're in the minority here. Most candidates I've interviewed have barely anything on GitHub. Some UI/UX-ish people will have a portfolio, which involves a lot of "view source" and isn't too rewarding. Lots of perfectly good working programmers have no active open source participation, not even a "dump of code" type of GH profile, making it difficult to tell wheat from chaff. Having them do code tests is pretty much the only way that doesn't involve talking to every single one.

Look at the other side, too: I've gone through hiring processes in the past as a candidate that started with a 30-45 minute conversation with the hiring manager, and proceeded to the onsite interview stage. This inevitably ended up being the classic 6-hour beatdown, with both sides muddling through without truly understanding what either is doing. These are usually so inconclusive (especially at bigger companies) that no one can make a decision, so they end up saying "no". Now both sides are 6+ hours in the hole. This could have been a simple 2-4 hour asynchronous code test, which would have provided hard information to the hiring team instead of the usual inconclusive bullshit.

> Having them do code tests is pretty much the only way that doesn't involve talking to every single one.

I get where you're coming from. But to me that's still a very, very selfish way of approaching this. You are asking for a blind burn of four hours of their time just to consider talking to them. Four hours is a lot of time. It's half a workday. You're asking for a hell of a lot just to not-a-culture-fit them out afterwards. And from a practical perspective, somebody who's good and employed is unlikely to expend the effort unless you're a very special company, too, which complicates the search.

> I've gone through hiring processes in the past as a candidate that started with a 30-45 minute conversation with the hiring manager, and proceeded to the onsite interview stage. This inevitably ended up being the classic 6-hour beatdown, with both sides muddling through without truly understanding what either is doing.

See...this I don't get. I know within an hour or so of talking to somebody if I want to work with them, and past that literally everything else, aside from compensation, is belaboring the point. And I mean "an hour"; if I'm not enjoying the process at that point, I'll usually suggest we end the interview. But on the flip side, because I am a good community member and I network heavily, I might in those situations go "hey, I think this isn't a good fit, but I want to introduce you to my friend who I think might be a better fit." I've done this before, and I can't do that (and wouldn't be inclined to do it) after you've burned half a workday on a monkey-work project.

I think there are reasonable ways to get a demonstration of work, but they involve investment and give-a-shit that I think most companies are way too happy to be bad cultural citizens to consider. Like, here's a coding test I'd be happy to do: "add this feature to this open-source project you probably use every day", well, that'd be different. I'd be getting something for my time, too, both in terms of feature and in terms of public recognition for open-source contribution. But one-way, dance-monkey-dance, throw-it-away-after stuff? That's very selfish, and I think we should be better than that.

I wish there was a way to scale the "add feature to FOSS project we use" thing. Scale is a concern here because I see this exercise being doled out more than a few times, which means that every instance must involve someone deciding what features should be added. There's also a limit to how much can be added to the same handful of projects over time.

Can't ask all candidates to add the same feature over and over, or else this becomes throwaway code as well, which doesn't address any of the valid negatives you've raised.

> I know within an hour or so of talking to somebody if I want to work with them

Ha ha! I've had an HR department at a BigCorp tell me that there was a minimum duration to each interview (30 minutes for phone screen, at least 45 but preferably an hour for in-person), regardless of how they were doing. Their thinking was that more time spent by us would cause the candidate to consider us a more desirable employer. You can imagine my anguish at having to speak endlessly with people who would clearly never cut it on my team.

"But you can't just walk them out after an hour!"

> Can't ask all candidates to add the same feature over and over

Ehh. Make a list of, say, ten features across the stuff you use. You really think that's not going to be enough for fifty candidates, if the state of the industry is as apocalyptic as everyone says it is?

I don't know, I personally consider an all-day onsite interview to be a bigger waste of my time. With two or four hours spent on a take-home test, those can be any time during the day, probably time that I would have been wasting anyway. An interview has to happen during business hours, which means I have to take one of my scarce and therefore precious vacation days, and then actually go somewhere which is likely to take two hours round trip anyway, and that commuting time is entirely wasted. At least a work sample test can be an opportunity to practice my skills and an interesting challenge in itself. Then again, I actually used to do programming contests back in school so maybe that's just my personal preference.

Nearly all of the work I do for my employer is on public github. I always wonder though because if you just went to my personal github page it's not necessarily obvious that my Day Job is just a click or two away as these are contributions to another public repo, not one of my own. My own personal repo collection has close to nothing related to any job I'd ever want.

Well, there's a pretty big difference between 2 hrs and 4 hrs. Most people are applying to multiple places when they are looking for a job. So let's say 3 places a week. Now this is the difference between 6 hrs (already a lot) vs. 12 hrs (practically insane) per week on this stuff.

And at the end of all that work, the candidate receives a binary yes/no. 1 bit of information. On the other hand, the 6 hour 'beatdown', as you term it, gives the candidate an incredible wealth of information. They see what their prospective coworkers are like, what the office is like, how people interact with each other, maybe what people talk about over lunch. So 3 interviews with 1 bit of information (12 hrs) each or 2 on-site interviews (12 hrs) with a hell of a lot? What's the rational choice?

And I'm not against programming assignments, but 4 hrs each?

At my company, we use take-home problems to answer: "is this person worth interviewing?" Can you take a simple problem and code us an equally simple solution? It's basically FizzBuzz.

I rarely have people balk at doing this, but when they do, I'm happy to look at other code samples. I just need to know if they can write code.

Totally. And I mean, I don't think I'm unreasonable. If it's the kind of thing I can reel off the top of my head or open `pry` and bang out in a couple minutes, I'll usually indulge. It's the multi-hour odysseys that are a big nope.

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

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

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

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

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

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

Poor execution doesn't invalidate the idea but it does hurt its effectiveness by making candidates gun-shy.

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

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

I 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

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

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

The 90%+ rejection rate was at a BigCorp that refused to give people code tests ahead of a technical phone screening and onsite interview.

Yep, 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!

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

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

You need to verify that the candidate actually did the take home test, and didn't hand it to their more talented friend.

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

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

We 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

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

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

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

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

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

But have you ever had to reimplement merge sort from scratch in any real-world scenario? Of course it's good to understand, but actually doing extra work again seems pointless to me.

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

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

Reply on news.ycombinator.com