According to the HN gestalt, you shouldn't do a whiteboard interview because that's too unrealistic because nobody programs on a whiteboard, you shouldn't expect programmers to code with their laptop in an interview because that's too much pressure and also unrealistic, you shouldn't expect programmers to be willing to do a take home exam because that's too much work without money (and if people did pay, the complaint would smoothly shift to it not being enough money and still being too much work), and you shouldn't just hire people with the intention of rapidly firing them if they don't work out because that's cruel to uproot them like that if you're just going to fire them. Recruiters are also out because they suck and also drain money out of the transaction for no gain since they bring no value to the process.

Apparently the approved HN method is to arrange the resumes on a dartboard, throw darts at it, and commit up front to hiring whoever you hit unconditionally for at least two years without no possibility of having to fire them. Or something like that.

Setting limits on what you will do is good, and ghosting is bad, certainly.

But in the end, you're going to have to do something unfun to get hired. There's no way around it. I know we'd all love to live in a world where Google one day just logs on to LinkedIn and is so impressed by the sheer brilliance of our awesomeness which just somehow oozes through our listing despite the fact we didn't have to do anything to demonstrate it, as it's also unrealistic to expect programmers to have a lot of publicly-available demonstrations of their skill such as open source projects (forgot to mention that one!), that instead of hitting you with a job interview they just lead with a job offer for their best position, but that's just not going to happen.

The tactic I’ve employed at my company when vetting a candidate is to give them a link to a small code sample (usually a single class or service for backend, some JS/CSS for front end) to review the day before the interview. The code itself will include some obvious issues, some less obvious issues, some language specific opportunities for improvement, etc.

We then walk through their notes (if they made any), and the code sample itself together. I have them make any observations, critiques, suggestions, or other thoughts together with me. This gives me an idea of how they think, what issues they saw, how they would improve things, how familiar they are with the specific language, and coding in general. It also gives an opportunity for some light “conflict” resolution , if I push back on their thoughts.

This has worked really well. Those that don’t do well on the spot can make notes ahead of time (but aren’t expected to spend time coding for hours) and those that are confident can walk through it live.

I've had the same experience. Submitted a working code test and crickets. I left it up on my GitHub named "{company name} coding test" and a couple of months later they asked me to take it down beacuse other people were plagiarizing it. Like them, I was concerned with the legal ramifications of providing any sort of contact, so I took no action and didn't respond.
First, Ghosting is a shit move. No reason HR can't send a standard lawyer approved boiler plate rejection mail.

2nd aspect is unpaid take homes. It's complicated. Companies do pay a lot to fly candidates, put them in hotels and feed them for onsite interview. So financially company can afford to pay something. But it adds a moral hazard as you are paying cash irrespective of any expected quality or commitment.

Other thing I would like to highlight is that unlike any other industry, tech. allows people to enter at ease irrespective of the pedigree and credentials. No hospital would hire a physician who has read a lot on the Internet and did some pro-bono help to the neighbourhood kids. So what is the best way to hire isn't very well defined. It could be Leetcode, puzzle problems, take home tests or something else.

We let the candidates decide: Take-home assignment, pair-programming, or we go through an existing project of theirs, discuss it, and extend it together.

The take-home assignment is short. It shouldn't take more than an hour if you really really want it to be polished, which we heavily insist we do not care about. The overall process is a bit longer, because we then discuss it together.

For the pair programming session, the exercise is picked by a developer that isn't involved in the process, to put candidates and interviewers on equal footing.

Our goal is to be able to give an offer within 48 hours starting at the first contact, and give a feedback, positive or negative, maximum one hour after each stage.

It's a candidates' market. A long and complicated process only ensures you weed out the candidates who have plenty of options. I'd almost be tempted to give a long assignment and consider everything but a firm "Not even in your dreams" as a failure.

For a 2015 ML job I applied for:

    | We are wondering if you would like to attempt our code challenge (C/C++ or
    | Python). It is a Computer Vision problem which we think can be solved in
    | about 8 hours.
    I'm afraid I wouldn't, 8 hours is far too much for a interview
    However, thanks for considering my application.
To me, there are three tests to figure out if a home assignment is reasonable…

1. Is it actually giving the employer more confidence or information about your candidacy?

2. Is it within the normal bounds of an interview? If someone asked you to do another 60 minute technical interview, would you?

3. Is the company clearly not trying to use the product of your code challenge?

To be honest, there are a lot of people who can look impressive but turn out to be totally under-skilled at coding. I’m sympathetic to hiring managers who feel like they need to test for that. As long as it’s not a super long exercise, they’re not just hazing you, and they’re not trying to use the results, I think it’s fine.

I do a lot of interviews for my company. We do coding assignments OR let you bring some code. We just want to talk with you about code that you are very familiar with and confident to talk about.

Almost everyone chooses to do the small coding assignment, because they don't have code to bring.

Counterpoint: as a self-taught SWE with only a degree in economics, I wouldn't have been able to get my first job in the industry without a take-home assignment. It was the only possible way to demonstrate that I was qualified to take the job.
I just don't do them at all. It sets bad terms for the employer / employee relationship IMHO. I realize some devs just aren't that in demand yet and may have to subject themselves to this, but you should do your damndest once you get the job to build the skills not to have to stand for it in your next one.
They are much better than livecoding. I take 8 hour home assignment over 1 hour livecode torture.
You encountered 2 problems and neither of them was the take home assignment. The first is that the company ghosted you. That is unacceptable regardless of what your hiring filter is. You’d be just as aggravated if they’d brought you in for 6 hours of interviews and then ghosted you.

The second is they didn’t set expectations (or at least you didn’t tell us if they did). Should you have spent 6 hours on this? How long does it normally take? After the assignment would you be brought in for 6 more hours of interviews or is the assignment the major filter?

At the end of the day, take home assignments are the best filter, the most equitable and the most efficient way to do hiring consideration. Companies (usually the middle managers within them) just don’t have the courage to use them correctly and don’t spend the resources to make them a good filter (they also don’t spend resources on the other job filters so those aren’t good either).

I have 25+ years of open source software and contributions. If that isn't enough to convince them that I know how to design and write software, then homework won't be enough.
I've been in both sides, and what they did to you was horrible. Just last week I had a call with someone who did the take home assigment very badly, but I wanted to give him some feedback and showed him a better solution.

Nonetheless, I can't think of a better solution for this. Hiring someone is a big commitment (for both parts), so I want to be completely sure that I am hiring the right person. How do you that? How do you measure the quality of the other person in an area such as IT where it's so easy to lie about knowledge and experience?

I agree completely. These things are ways for companies to waste your time in the interview, and make it harder. Job interviews used to be 1 hour and a handshake. Then a reference check.

Let me tell you why that was better than the current hiring meta.

1) I can learn everything I need to know in an hour with someone. 2 will likely not drastically give me a better idea. 8 hours with someone is not 8 times better, it just doesn't scale like that. So the idea that the more work you give a candidate, or the more interviews, or whatever, the better your hiring practice, it's just not true.

2) People can be very nervous in interviews. It's an intimidating, adversarial environment that has no relation at all to the job or work. It's almost the beginning of the way for the company to treat you as lesser, and they will take advantage of that to screw you these days. As you say, they will just ghost you. They didn't used to do this nearly so much. They'd at least send you a letter, or give you a call.

3) Even if 1 and 2 weren't true, the questions asked in interviews have no relationship with the real job. You just can't ramp up in time, etc. There's too much learning. Picture an intern. They do nothing except take everyone's time for the first month, but it's the rest that matters. Will they get something useful done before they leave? Maybe. But it does take a while to ramp up. So interview questions don't judge job performance.

But we still do it, because people like that tinge of power I guess. That feeling of control in that you can say yes or no to someone, they have to placate you for the job, etc. A lot of interviewers I know act very strange in interviews too, and they don't act that normally.

For the interviewee, it's even worse. You waste your time, you spend a lot of emotional energy, you don't know if you like the people you'd be working with, you don't know really what you'll work on, and no matter what you have to do what your boss says anyway, which can change at any time. Oh and it's "right-to-work" so they can fire you any time for any reason.

It's much more useful to talk to their previous boss or friends or references. Even if they are biased, you can usually tell pretty quick again who is telling you nonsense. At least then you can hear real stories about real situations in the past, rather than useless hypotheticals. But we don't do that anymore because of liability from lawsuits in hiring. Because a lot of companies are actively discriminating. Some are passively doing it, some are trying to do better but are hopeless. So everyone is just covering their ass.

Sounds like a great deal!

I prefer them to whiteboarding. Preparing for whiteboard interviews takes a lot more time.

I will however not accept a take-home coding test before I spoke with the engineering team and saw that they're seriously considering my application (i.e. it looks like I will be a good fit, and they just want to make sure I'm not some fraud who can somehow talk the talk, but can't walk the walk).

I actually like take homes as they feel like the best way for me to demonstrate I can code vs a Leetcode question which determines I have grinded or am amazing at mental pretzel puzzles.

What I DO HATE about take homes, is if you complete one, clearly put time into it, and then are refused feedback when you are rejected. If I put 2-10 hours into writing something for you, I at least deserve three sentences on why it wasn't accepted. I know these people are busy, but so am I. Most of us also have jobs, and even if we don't we want to know how to improve.

6 hours of work is too much and ghosting is never acceptable, but I'd much rather do a take home assignment that takes a few hours than any sort of in person whiteboard or a screen share coding session. I struggle with where the line is drawn here. If throughout the interview process you spend over an hour talking to various individuals at the company should you also be compensated for that time?

That being said, I've seen cases where the take home assignment is actual company work, in which case I 100% agree you should be paid.

I did a home assignment that required far more than 6h. The feedback was atrocious, as they just said "not fit". Not a single comment on what they disliked or how could I improve.

Actually, the assignment was "take this shitty service and make it production-ready". It had some pitfalls that I avoided, and I introduced monitoring, automated deployment, API documentation, etc.

There was a bug - a minor misunderstanding that was simple to fix if they gave the feedback and allowed to do a quick fix - but the rest was production-ready.

I had fun doing it, that's why I didn't mind taking time. What I didn't expect was the poor binary feedback with zero content.

From now on, I'm only taking these assignments if they agree to have a feedback session. If not, I won't do anything. I'm close to 20 years of experience and it feels like they treat me like an undergrad (although I have a full Github profile).

Long ago, I had a candidate in an interview for a short term project. The person had an important hole in his knowledge, but seemed OK apart from that. I was afraid learning the knowledge required to fill the hole would take too much time from the short term project.

So I decided to mail a take home assignment. I took about an hour myself to prepare it, the assignment was not work related, it was a completely fictional task. I think it was creating a HTML page of ~50 lines demonstrating the hole could be filled if the person had access to internet and all relevant docs. The person delivered the next work day, did well, and we hired.

I've thought long and hard about this, and decided the assignment was a mistake and I would not do it again (sorry to the person in question). Why? In practice, when listening an hour to a candidate and let them write a minimum of code, you know if you have a complete weirdo who never touched a computer, or someone who is at least basically OK. In this case, it was a short term job, so the blast radius was pretty small even if candidate was bad. For longer term engagements, there is generally a test period and better vetting available. Meanwhile, I was in a position of power over someone else, and while the whole thing seemed minor to me at the time, I later heard the (junior) candidate was worried sick and spent way to much time on the assignment.

An underlying cause for my mistake was the interview situation, which was very bad. Basically, I was in the middle of something else, and a project lead I had never heard of for a project I had never head of asked me to do a technical interview while the candidate I had never heard of was already sitting in a meeting room. Needless to say, I was completely unprepared. There wasn't even a whiteboard in the meeting room. So I basically adjusted by always being prepared for surprise candidates: A list of questions for most common technologies and a template for technically grading candidates were always stashed away in my locker from then on, and the people starting projects would keep us interviewers in the loop when a job would open.

I have a rule that I refuse to participate in hiring processes that require unequal investment (of time/money) from me and the company.

If the hiring process requires 2 minutes of the company's time for every 1 hour of yours they are pretty much guaranteed to waste your time.

I've made exceptions to this rule before for what I thought were good reasons and deeply regretted it every single time. I no longer believe there are exceptions.

I don't think coding exercises are going away any time soon. There is something to be said to be able to solve a problem without having interviewers staring at you over video, and being able to use your preferred tools and language.

That being said, if you want to avoid having a large imbalance in risk/reward, I would suggest talking compensation before agreeing to submit yourself to a large time investment. At least that way you know why you are putting in the time investment that comes with take home assignments. There's nothing worse that putting in a significant effort into the interview process only to discover your compensation expectations would never be met.

> I will not do take home assignments for free if they take more than 1h of my time.

Even then, if something can be done in 1 hour, it can probably be done better in 2-3 hours or more. It takes time to show your best work. That's why many companies that do take-homes claim that their process takes only a couple of hours (but in reality it doesn't).

It’s odd to me how people complain so much about being asked to write code (whiteboard, take-home, leetcode puzzles) in order to land a coding job.

Is a prospective employer supposed to suss this out entirely through verbal questions?

The ghosting is what’s not OK. Ghosting a candidate after receiving unpaid take-home interview work from them is doubly bad, that makes them grifters in my book. Tell us who it was so we can avoid them.

There’s nothing inherently wrong with unpaid take-home interview work. Don’t do it if you don’t want to do it, but don’t declare that it’s “not OK” in a general sense, as if it’s somehow immoral. If both sides are clear on the arrangement, and it ends with either acceptance or rejection with feedback, there is nothing wrong with it. It’s my favourite format as an interviewee.

I wrote an article about this same thing. Stop interviewing with ad-hoc code quizzes, live or take-home.

I've interviewed maybe 500 engineers in my career. I'm an early engineer of Instacart, 3rd engineer of Eventbrite, founding engineer of Reforge. Started 3 companies myself.

My interview is always the same:

1. Bring code you've written

2. Share your screen

3. Explain what it does and I will casually ask questions about it

You get so much information from this:

- How they think about code

- If they think it could be better

- Who they blame if the code isn't the best

- Personality

- Product dev glimpses

- Comms

- Sentiment

All industries and professions have the same problem - how do you know your new hire is right for you?

So you think that a 6 hour unpaid assignment is unfair. What do you think the alternative should be?

Many of the posts here point out that 'take-home-tests' aren't common in other professions, but completely miss how many free hours other professionals have to do to prove their suitability for potential employers.

Here are some examples:

- Designers, photographers and writers spent countless hours putting together and updating portfolios.

- Anyone part of a professional association (doctors, nurses, pharmacists, engineers, architects, pilots, etc...) spend many hours studying for and writing exams (for free), and then every other year spend hours documenting all of the professional development they have done to maintain their credentials (also for free).

- Many higher responsibility jobs, especially in public institutions and government, require months-long application processes complete with multiple interviews, essay questions, and personality tests.

- Consultants can spend 40 hours or more crafting proposals for every new contract they go after.

- Academics and researchers require regular publications and often do regular peer reviews for free.

I doubt anyone gets a job of any importance based on a resume and a quick coffee unless of course there's nepotism or greek letters involved.

So how should programmers prove themselves to a potential employer? Would you rather have a professional association? or standardize on coding portfolios? Or perhaps you want to go back to the days of three essay questions and a personality test?

I have been on both sides of this and I have a rule I try to always follow: I don't ghost people, no matter who. (Unless they are belligerent.) I always send some type of polite response. Even in unpleasant circumstances.
I really think these unpaid home assignments are just to rule out people with kids. You are expecting people wake up, get kids ready, work a 8+ hour day, commute (?), pick up kids, feed kids, and then after all of this be functional for some assignment that realistically has nothing to do the job I am applying for since it has been water down to fit into a "small" time frame.
But you confirmed to the company that it is okay, by completing the assignment. That's why companies assign this kind of homework - because you and thousands of others gladly do the work.
I once did an interview with a company that wanted me to do a homework assignment. It was obvious from the problem that it wasn't just a way to find out if you could code, but was a real problem the company was facing.

I spent a couple hours on it, but I realized that in order to get it working and tested, it would require many more hours of work. I started peppering the code with comments like /* here I would verify the validity of the data by doing X */ to show them I knew what needed to be done without doing all the grunt work.

I sent the code, but the manager got back to me and said he expected finished code that actually worked and not just pseudo code. I politely told him that I would gladly do the work if he wanted to pay me my fee I usually charge for contract work.

He declined so the company did not get a bunch of free consulting work, which I think was the point of the exercise. Too many companies get away with this.

I’ve been on both sides of the table, big company and small. The common interview practices, and the one brought up by OP, stem from a desire to have a system that doesn’t rely on trusting the candidate.

I think this is a bad place to start. But how do you weed out people misrepresenting their ability? I think it’s a lot easier than most realize: first you need _something_ to talk about, have the candidate bring something they worked on. Then ask a ton of questions. Not just technical questions, questions about motivation, interest, reasoning, and taste.

The argument against this is that not everyone has time to make something on their own time and it just shifts the privilege to those with a greater share of free time. I think there is something to that, BUT: the power to choose the subject is in the hands of the candidate not the interviewer, that to eliminate all the test-like processes seems like a fair trade.

I don't mind doing home assignments as long as they're interesting. Make learn about some technology or some design pattern or whatever. Something that improves my skill. If I am going to dedicate some of my own time to a project, at least, push my skills to the limit and "help me" grow.

I refuse to do basic projects that make me learn nothing and feel like a wasting of time. Most of the time if the assignment is "not interesting" the future offer would be lower than I expect and the daily job is going to be boring.

I think that my point of view is going to be unique here, maybe is because I need a "push" to improve my skills (I'd rather not to be fair), but although I have been rejected from some processes after a long and hard assignment, I have learn something and I'm happy (almost grateful) about that.

An unintended consequence of these coding assignments is that it creates a pervasive labor market that optimizes for finding candidates that already know things. Historically, joining the labor force, and a company, required training. Letting this behavior continue permeates the expectation that corporations can shirk on their duty to train and build employees. Instead, they have the luxury of finding cogs ready to go, out of the box.

I think we need to stand up and advocate for the expectation that corporations should provide more value to society than just print money. They should be held accountable to creating a strong, and healthy labor force.

I'd be okay with "homework" if either 1) it's truly time bounded via programmatic cutoffs or 2) it's paid.

For time bounding, I love the time estimates they give you for a decent sized problem. A major company told me that a feature extraction problem + report should only take 4 hours. They provided me with some large CSVs representing DB tables (which contained some malformed data) and wanted a brief report back.

That's unrealistic in 4 hours even for a great performer. Then you spend the weekend on it and they won't give you feedback on it because of the suits in legal.

It's disrespectful.

I've never been asked to hand in any home assignment for a job interview, but I have been asked to do some "live coding" while their employees sat and watched; that was somewhat unpleasant as well. But I guess it beats a huge (unpaid) home assignment.

Home assignments should be short and sweet, it does not take a huge complicated task to see who can and cannot write programs. There are differences in ability of course even among "good" programmers, but the main difference is between those who truly cannot do anything, and those who can.

I have found the following strategy to work well: pick your battles. Some employers use test tasks to keep you busy so that you can't apply elsewhere. Other employers genuinely test your skills, but even among them there are some with unrealistic expectations. You can't be doing all the test tasks, period. But you can avoid most of them without walking away.

I am assuming an active job search where you have more than one potential employers.

If the test task is simple and you have the time: do it. If the test task is interesting and you really want into this company: do it perfectly. If the test task is simple, but you don't have the time: write an email explaining how you have a full time job with lots of interviews, tell them your CV clearly demonstrates you have enough experience, ask to forgo the test task. If the test task is hard and you don't have the time: explain how you would do the task, ask to forgo the task as above, walk away if they don't agree.

You would be surprised how often people will skip steps of the interview process if you ask nicely. This way I skipped tedious home assignments, psych tests and leetcode home assignment (not even hard, just told the company I don't want to rehearse dynamic programming with so many interviews lined up).

In my recent job search I had two good offers and incidentally both were the ones where I did the test tasks 150% because they were interesting. So do them if they are worth it.

A few weeks back I was sent a home assignment by a company and it was a full blown production level program. If someone asked me to do it, I would charge them a minimum of $10,000. And it required I pay for an API, complete testing, caching, Dockerized, and a laundry list of other requirements. And it certainly would take a lot longer than a few hours.

The most reasonable company I have dealt with was Trip Ninja, an Amazon gift card for my time. Regrettably I tripped up, and messed up the test, timed tests are my Achilles heel.

Isn’t the root of this need to make developers code stuff to prove their skills because we don’t have an accredited body giving people meaningful certification?

A dr would not do a quick surgery and a power plant engineer won’t build “just a quick test reactor” because they have credentials and the hiring bodies trust those creds.

In software is the problem that we don’t trust what the resume implies? Where does the deep distrust come from? Why don’t we have an equivalent to a medical, legal, or engineering accreditation?

(I’ll state the obvious ghosting was wrong)

I’d be annoyed about being ghosted too, but my takeaway from all the chat about recruitment is that there is no single process which is clearly and significantly better than all the others and they all suck in some way.

“Home assignments” suck because they can be unbounded and tend to disadvantage people who might not have a lot of time.

“Pair on a feature/bug” sucks because it’s quite hard to many people to demonstrate their skills in that stressful environment with someone they don’t know.

“Whiteboard Code Golf” sucks because it hands an advantage to people people who have the time and energy to grind shit they won’t use in their roles.

“Paid trials” suck because they’re not something that everyone can contractually participate in.

I honestly don’t know what the best approach is, from either side. I have stuck with a single take-home for devs on the basis that we can establish a clear rubric for evaluating them and try to be at least somewhat objective with what we are looking for. Maybe a better approach would be to let the candidate guide it a bit, and offer a selection of different evaluations that they can participate in?

At least I agree it’s important to maintain a clear line of communication and respond to everyone. I know it’s easy to let people fall through the cracks as you scale; I hope I’ve never done it myself but I can definitely advise that a robust ATS helps to make sure every application is tracked.

I had a similar experience, did go through:

- initial interview with HR

- technical interview with devs

- home assignment ( you can find it on my GitHub with the name 2048 )

- discussion of the assignment with the same devs of the technical

After every step they said they were very impressed, I did reach the step where they were scheduling the final interview with the CTO then they weren't able to schedule it and they disappeared for months with the excuse of hiring freeze. Apparently they hired someone else and they decided to put me on hold indefinitely

Sorry you got ghosted like that - it happens way too often and it sucks. But I think you're using your understandable frustration with this company to dismiss a highly-effective interview technique.

Programming is largely solo work punctuated by a high-bandwidth communication (presenting your solution to the team, review, etc.) A take home assignment with a follow up simulates the actual job environment, especially for remote work. No other coding interview technique comes close - portfolio review doesn't show how you worked only that you've worked, in-person coding challenges and whiteboard interviews are so far removed from the daily experience.

2kloc / 6hrs does seem excessive though. My advice to interviewers - keep the exercise time-boxed to 2 hours (And actually have some developers work through it internally to confirm this!) "How far can this candidate get on the problem in 2 hours" is a better signal than "Can they build the perfect solution with unlimited time". And time boxing the assignment gives you lots to talk about - "If you have more time, what would you add or change?" is a prompt that should yield another high-value signal.

I've had this before from a big company in the Go space. They constantly still sent me job ads and requested for me to interview and repeatably ghosted me. Wasn't until I direct messaged the CTO on a public Slack community to find out that I had not passed and that was why they wouldn't consider me and why I had been repeatably ghosted. No feedback as to why I failed the test or anything
Absolutely. The worst thing is they start small and assign to you increasingly complex tasks the more you progress, with wild excuses to justify it. The sunk cost fallacy is real.

Happened to me once. The best thing is I explicitly told them beforehand I had little time to spare for home assignments. I got rejected after almost a week worth of work total. I should have billed them...

That sort of thing happens —- try and be really clear what you expect back if you do an assignment. Put it on an email.

Otherwise I’d write to them and tell them that you have an issue. Chase a bit, presumably you don’t know the reason for the ghosting.

Having said that they could be ghosting you because they are assholes. There are unfortunately a lot of inconsiderate assholes in tech.

I applied for a QA position at a company that uses time-of-flight cameras with industrial robots. I researched their solution, got a sense for its architecture, and started toying around with building a Flatland-style version of their product. I figured that a demo like that would stand out much better than anything on my resume.

They rejected my application before I got too far with the demo, which would have taken me a lot more than six hours to finish. Although it might have been an interesting addition to my Github repo, it was kind of tailored to this one company.

I'm not disagreeing with the OP, because I probably wouldn't find an interview project nearly as fun. I wonder, though, whether anyone has been successful with a one-off, company-specific project like this, as opposed to a general portfolio of projects that you've made over the years.

In the event that I’m responsible for assigning these sorts of things, my rough metric is to come up with a task that I, fully spun up on the task and already thinking about it, would be able to do in about 30 minutes.

I then time myself doing it.

I figure that means the applicant time commitment is under 2 hours, which seems not too bad.

I am not too sure getting paid for them honestly makes much difference. For an average job hunt the amount you would be paid is small compared to the hopeful raise you get. Plus tax complications.

Before doing an assignment just work out the “pot odds” and see if you want to raise or fold. Yes it is basically poker!

It's only fair that a company asking you to do this should pay you because they should only be doing it once they are far down the funnel and perhaps deciding whether you are go/no-go in which case, paying somebody a few hundred dollars is neither here or there.

If you are doing it because you don't believe someone's ability, you should either pay them or be honest and say you don't believe their experience, in which case it is up to you whether you want to do it for free or not.

I find the ghosting unforgiveable though, I can't understand somebody being in contact and you simply not replying even if to say "sorry, we aren't taking you". Are people so insecure, they don't know how to reply without sounding aggressive/opening themselves up to lawsuits or something?

You get a lot of signals with the approach described below that are highly indicative of how the candidate is going to perform on the job. With a take-home assignment, you get no signals that can predict their on the job performance.


For engineering roles where the person is expected to write copious amounts of code to ship functional features everyday, a 2.5-hour machine coding round to assess coding competency (as part of an interview loop that also has other rounds for problem-solving, data-structures/algorithms, high-level systems design and low-level design) is standard in multiple companies I have seen (and advocated for). While coding round is a strong filter, it is important to assess the interaction of the candidate in these other rounds that are non-coding but designing/problem-solving rounds, especially in high functional domain complexity industry like e-commerce or payments etc.

In the machine coding round, the candidate should be given a well-defined written problem statement (from an internal question bank of well-calibrated problem statements) along with test inputs and a few test outputs, and in the first 5 minutes ask them to read the problem and ask any clarifying questions. Then leave them be with a dev machine for next hour. If they choose to, 10 minutes in, they can discuss the approach they are going to take with you. Then after an hour, you can discuss if they have a working code that passes the test inputs. If yes, you can give them an enhancement/modification to make. and leave them be for another 45 minutes. Then, take the last 30 minutes to discuss the solution they have come up with and understand their thinking style w.r.t coding conventions, style etc. If they couldn't complete the enhancement, discuss a potential solution (give a hint) with them and see if they can tackle it. Write calibrated/standardized evaluation notes for your interaction so that others (hiring panel) can understand and decide. Existing engineers inside the company should have tried the problem statements themselves and calibrated to see if the problem is meaningfully solvable in the allotted time.

Ghosting really sucks.

I don't understand the practice. Maybe someone here can fill me in on why it is considered OK from the recruiter perspective. Too many folks asking for feedback post-rejection? If that is the case - automate the message with a generic rejection.

If you're giving someone 6h worth of tasks, you really need to:

a) be 100% absolutely certain that you definitely need this to evaluate the candidate (you most likely don't)

b) if you do then you owe it to them to study their submission, run it, test it and provide clear feedback and honestly if they've broadly met the requirements you should interview them. The submission could form part of the interview process - maybe you pair program some changes together, or discuss part of the implementation. Basically if someone delivers six hours of work, you use it.

c) No matter what, you communicate with the candidate throughout this process. There is absolutely no excuse for ghosting candidates. None

Seeking actual code that you made is totally reasonable for the realm we're in. It's literally what you're being hired for.

1. set up a good GitHub (or other) profile; convince potential employers to look at that rather than test you (I've done this - it can work) 2. if a company still insists you "do the test", then either your GH is too sparse (spruce it up!) or they're full of shit - but you have another data point to work with 3. even the most trivial "toy project" test could be 1 hr for one person and 6hr for another, so what's unreasonable for you may be totally reasonable for the level they're aiming at

Our position on this has always been that if a candidate finishes our sample coding task, they are automatically granted a tech interview. It's the least you can do for someone who put in the time toward your position.
I love them, fun challenge, get to experiment with something new. (either by my choice or by requirements)

You also get an idea of what company cares about and if its a good match for you.

If you move to next step you did something right, if not then there are others that have done better.

Ghosting might be a problem like someone forgetting to process stuff, vacations, etc, just check with recruiter whats the status, dont be antisocial.

And if it took you 6 hours to do, you chose to do it, and hopefully you learned something. There is no implied obligation on other side to pursue you just because you took on challenge.

I still think that home assignments can be a good recruiting tool when you are trying to recruit junior, since they can have a very different skill range. For senior it really seems unnecessary.

In both case, if you are going to do home assignment, my question to you is: How good is your offer ? I refused several HA when interviewing with companies because their offers was just not good enough for me to take several hours, on top of the regular interview, to do it. If you do HA, make sure your candidate have a reason to want to take several hours for you.

Maybe you can put it on github/write a blog about it and refer to it on your next job interview, they might hire you on the spot instead of sending you home with another assignment.
Everyone's different, but I would happily take 6h of working at my own pace with full access to all of my normal tooling in a low pressure environment over 1-2h of high pressure speed coding using "tools" (web editors...ugh) I'm unfamiliar with. It sucks that you were ghosted, and I would view that more as an indictment on that company rather than the practice of a home assignment. To me there's no easier evaluation of skills you could ask for.
I have never been asked to do a home assignment, and I am a contractor who gets a new gig every year or more. Having said that, I have seen it used by good companies. It was a case where the person's background was, as I recall, a music degree, and I think they were wanting to make sure he could program (he could).

It's definitely a strike against a company, but it's something I would put on the scales against how good this job would be. Sometimes it might be worth it.

We pay for home assignments no matter if we like the result or not. First, it seems fair and it has never been a problem from a financial standpoint. Second, because we pay we can give less trivial and more realistic assignments that can take up to 10-15 hours of work. We look if the candidate uses the time to analyze the problem, ask more deep questions, write tests, annotate the code, and make it production-ready in other ways.

So far, this approach worked very well for us.

The headline is wrong. You should have said “Unpaid… are not ok for ME.”

Maybe someone else is more hungry, more ambitious, more game than you. They deserve their shot.

When I have given assignments like this, I said “the result of this work belongs to you. You can show it to any prospective employer. In fact, if you can show me a portfolio of your work, then you do not need to do this assignment.”

(I hire testers, and they rarely have examples of their testing work to show off.)

For Japanese companies, it seems to be common to ask candidates to complete coding assignments before any interview. These assignments are usually extremely complex, and would take maybe 2-3 days to complete, depending on the candidates experience.

Combine this with relatively low salaries even for experienced developers, I don't think it is something anyone should want to do, no matter how much you'd love to go there.

I'm not sure that an 10 x 8 hour job interviews every 2-5 years when you want to leave your old company and get a new one is particularly onerous.

My wife is a lawyer, she had to spend 2 years (in the US it's like 4 years at $80k+) and another 40 hours a year for life to maintain the qualifications that allow her to skip the equivalent of coding interviews.

I'd rather live in the world of none credentialed programmers to be honest.

The thing is that interviewing is hard; it is a full-time job, really, and one that could make or break the company. At the same time, interviewing is not something that current employees are remunerated for, materially or even in terms of time. It is very rare for deadlines to move because half the team is conducting interviews.

So, what ends up happening is that nearly everyone in the interviewing process ends up half-arsing it - from the recruiters who prefer to contact nearly everyone eligible based on some keyword searches - to the engineers who have no time to be thorough - to the hiring manager who usually has a bunch of fires to extinguish.

A few companies do tend to put quantifiable metrics around their processes but they're usually too reactive and inconsequential.

The interviewers have a vested interest in being more productive by hiring the best people, but at the same time, there is personal friction against hiring someone good/better when your own promotion is hanging barely by the 'meets expectations' thread.

Now the assignments - they're almost always totally useless. Like, build a new app based on a third party API and then make sure to test it. Useless because of multiple reasons - the API is nothing like what you use at work; your current product team has coalesced around some archaic architecture that no Greenfield app would use; it's the take home assignment of the month (like the favorite 'build a movie app using the OMDb API'). A better alternative would be to open up your own API and perhaps a module of your current production app and add something to it, create a PR, or even just fix a bug or two. I actually think asking candidates to document a module is much more useful than asking them to write code you would never use, even if you pay for such an assignment.

Onsite interviews are even more useless - it's usually the most vocal people asking esoteric questions about older technology or algorithms that they've had success with candidates stumbling upon. Again, almost none of the whiteboard exercises or questions are from real-world scenarios.

You could pay candidates for the interview process, but that doesn't even address why interviewing is so fundamentally broken. I bet we would have amazing software products if we just interviewed better, especially when companies have been able to lobby for right to work laws nearly everywhere.

I on the other hand would love, LOVE, a take home, I ask for them every time and companies won’t offer them. I don’t excel under the pressure of a 1hr interview and at the staff+ level they expect you to display all sorts of architectural skills that I fin much easier to display not under pressure and not in under 1hr. I wish somebody would compile a list of companies that offer take home even!
> It took me about 6h to develop and iron out the edge cases.

This is where you messed up. Set a hard limit of 1-2 hours, and mention edge cases in your comments and move on. It also depends on the stage of the interview. If you're in the early stages then they probably just want to see that you know what you're doing, and it should be fairly fast with the right frameworks, scaffolding, starters, etc.

I have found a large drop-off in time wasters after using Starblazer for my scheduling. Not to shill or anything, these recruiters are getting paid 10% to do jack-shit for you so I just send them my scheduling link with my hourly rate... you wanna talk to me? pay me (
Thats up to you. For technical jobs its much easier to judge a candidate with home assignments than just bullshit trick questions in interviews.
I recently went through an interview/exam with a takehome portion. The company indicated "this shouldn't take more than 2-3 hours". For me, it was 2.5 hours. And... I wouldn't want to do dozens of these, but doing one or two every couple of years isn't too much of a burden, imo. But I know everyone's tolerance is a bit different.
Up front, ghosting is not okay in general. But, a few counterpoints: It seems very unlikely they expected or wanted it to take you 6 hours. Possible, but certainly an outlier (and obviously bad actor) if so. If they expected you to spent 1.5-2 hours on it - a reasonable amount of time IMO - but when got it back you clearly spent an entire day working on it, that's enough to fail because you didn't follow the directions.

Additionally, software development seems to be the only area where the candidates get bent out of shape being expected to prove they know what they're doing. Take home tests are bad and have to be confined to an hour. Whiteboard interviews are bad and don't accurately model the day-to-day. Leetcode is bad because it's 10x harder than anything you'll work on. How exactly do we expect someone to get a sense of our skill at programming if we eschew every opportunity to... program for them to review? The exception might be extremely well-known people who have extensive public histories on GitHub or something similar, but by definition they're in the minority and 99.9% of companies don't need someone of that caliber.

I interviewed with a health tech startup and they had a good way to do it. We set up a time ahead of time when I'd be given access to the repo. 90 minutes later the interviewer was going to clone the repo and whatever was there was what he was going to look at. This was after a previous ~hour long interview where we did the "tell me about your experience" rigamarole that some developers seem to think should be enough to get them any job.

The best interview experience that I had, the interviewer asked me to bring in a laptop with some of my code. I did, we went through it talked about it, he asked me to add a simple feature, I did. Code I was familiar with (like in a day job). No gotchas. Symmetrical effort from both interviewer and candidate. Worked well for me at least.
Why draw the line at 1 hour? If companies want good talent, they should invest in their interview process, such that take homes are unnecessary.

The only companies that asked me to do a take home are ones with horrible, unprepared interviews where it was clear interviewers were just kinda talking and feeling around for... something.

Hint: you may now use this work as a sample of your code for at least a year of interviews with other companies.
Ghosting obviously sucks. But, I challenge the OP to post a link to their code here. Hardly anyone on this planet writes 2Kloc of fresh tested, error-free ("ironed out the edge cases") code in 6 hours.

Happy to do a free code review if it's in one of my native languages.

Ghosting whether it’s with jobs or women, always means one thing: You were not the top candidate.
Just open source the code in github. If you did not sign an NDA, add the data to the repo and send a pull request to a awesomedata repository in github. To add a cherry on the cake, write a blogpost in medium and promote it through LinkedIn and Twitter.
You can take any position you like with your career, but I suspect you’re gonna be limiting yourself on available companies with this stance. A better position would be to improve how you evaluate a company prior to engaging in a coding test.
Compared to odd requirements like paying to go to universities for 4+ years, take home assignments are nothing; both are insane waste of time, unless you’re learning something of value that will be of use regardless of the outcome.
I wonder if you’d have a small claims court case?

It seems like it was implied that you were a serious candidate if they asked you to do this. And the implied understanding is that they would at least review your work and provide feedback.

Send them an invoice!

Unpaid home assignments are fine, if:

- The work produced is not used in any way by the company other than to assess the candidate.

- The project has a time limit to prevent those with more time to dedicate to it being able to do better (reduces bias).

- The company puts time into reviewing the code that is commensurate with the time spent on it (a 3 hour test warrants at least 45 mins of thorough code review and feedback writing across a couple of engineers).

- The company provides options to take the test at a convenient time, or even on-site but unsupervised if desired by the candidate.

Asking for payment to take part in an interview isn't a great approach assuming the above are true (which they are often not). Companies don't pay for interviews as general rule, but conversely should be clear about the full time commitment so that candidates can make informed decisions about taking part.

I refuse to do take homes. You don’t ask doctors to treat patients before hiring them. You don’t have a carpenter build a house before you hire them. Insert mechanic, architect, author, etc..

Why should we be any different?

You can always publish the assignment on your GitHub and use it for future roles, explaining that you won't be doing any future assignments but they are welcome to look at the previous one.
It sucks to do these assignments but I can't whiteboard to save my life. I've gotten my best jobs by wowing the interviewers with my take-home assignment.
In order to get a $40k/year job, no. (This isn't your case) In order to get a $250k/yr job, probably yes.

Putting an hour limit on them makes sense.

> I will not do take home assignments for free if they take more than 1h of my time.

How is it possible to do anything meaningful in just an hour?

Home assignments are a great way to evaluate a candidate. A "one hour" project would not be sufficient for that, the problem would be too easy.

I find it weird that you guys don't want to spend some time to show your skills to the employer, without getting paid. These are not real projects. You're not benefiting the employer when you finish them. They also spend some time evaluating your project submission.

(I'm not talking about the companies trying to make people work free by giving them parts of the real projects in disguise)

Homework must be paired with an hour review session with interviewer. Company needs to have skin in the game.
Even worse, imagine being the grader of such assignments. It’s a useful tool for identifying noob companies.
Totally agree they are worse than DS&Algo(For those who consider them).
I think if you give someone a take home assignment, especially a junior, and they complete it you owe them the offer of a call to talk through some feedback or a detailed text breakdown of what they could improve and where you think they may be lacking in knowledge. If they don't know where they're going wrong it's going to be quite hard for them to figure out how to improve it.

As far as ghosting is concerned it's a bit baffling to me, seems far more in a company's interest to promote the notion of not ghosting so that they actually stand some chance at all of applicants letting them know when they've dropped out.

Next time demand compensation for your time.

This is what you need (friends’ startup).

So can you post the company name?
lessons learned the hard way
what company
6 hours is too little, Google will make you practice algorithms for months and still people will willingly do it.
Well did you do any research about the company before dedicating six hours of your life? At the end of the day you got more programming experience and avoided a toxic situation. Sounds like a win to me