This experience left me embarrassed, honestly. I don't think it reflects well on me that I put up with it even once.

At this point, I will participate in tech interviews, but I won't do any more take-home assignments. I suppose this could change under different circumstances.

Gayle Laakmann McDowell, who wrote "Cracking the Coding Interview", wrote an insightful post her blog about this. It's titled "Companies who give candidates homework assignments: knock it off!"

http://www.gayle.com/blog/2013/09/18/companies-who-give-cand...

She mentions something I see as a problem as well - these tests allow the company to burn a lot of a candidate's time, but not the other way around. I may have burned 6+ hours interviewing unsuccessfully at google, but they parted with 6+ hours of developer time as well (though I did spend a lot of additional hours reviewing algorithms and doing sample problems). This creates a natural set of checks and balances that don't exist with homework assignments.

She does have some good suggestions about how to use a take home if a company is determined to do it. To me, a particularly insightful one was to have a high (she says 90%+) passage rate.

I agree. If you're going to ask a candidate to spend a day on a homework assignment, you should be very close to an offer. If you're using it as an early filter, you are wasting a tremendous amount of developer time.

https://news.ycombinator.com/item?id=9437516

My experience is that what you hear is true, that you shouldn't spend significant time on job listings. The problem is that every other technique available to me had long odds. Professional network? Non-existent. MeetUps? Most people I met there have similar problems. Lunchcruit or similar gimmicks? No response, not even a lunch. I feel like I just got lucky that mavelikara gave me a chance, and I intend not to waste it.

Firstly, the job application that Decade mentioned in that thread was not the coding assignment, but was a resume.

We will not ignore an answer submitted to our coding assignment. Also, we do give feedback to the candidate if we decide not to proceed. We have had candidates who sent in a revised submission which incorporated fixes to our earlier negative feedback and we have been glad to proceed[1].

This meme I see often on HN that people who do hiring are some antagonistic bastards out to get you is simply not true. I am as much a programer as any one of the candidates. I have tried to design the interview process - at least in my part of the organization - to be fair and humane ("Do unto others.." etc) But I also have the other constraint that I have to make the process scale - hence the coding assignment. We are not using the code sent in by candidates in production. We have spent significant time developing the assignments - say, an order of magnitude more man hours than it would take for a typical programer to code up a solution.

I honestly believe that the "interview problem" is an essential complexity caused by the way the industry is set up[2]. I also do believe that a solution to the problem will not be handed down to us from the heavens. Each one of us programers have to help with the solution. Every time we get a chance to conduct an interview show some empathy and respect. Also, teach the professional recruiters working on your hiring team to also show the same. Make it clear that ill-treating any fellow programmer, even one which is not fit for the current role, will permanently ban that recruiter from working with you ever in any capacity. I also welcome efforts like Starfighter, Triplebyte etc from more prominent members of this community.

Now, the aftermath. After that thread, Decade followed up with me and we ended up sending him the coding assignment. Decade completed it and send us back the result, and my colleague's assessment of it was "This is the best code I've seen for this assignment. Let's take the next step". Few days later Decade came in for an onsite interview where he met various members of the team. We made him an offer, which he accepted. I am delighted to report that he started on the job the week before last!

[1] This is very rare, though. We do not hear back from most candidates. Few argue with the feedback, of course.

[2] My thoughts on the topic are at https://news.ycombinator.com/item?id=1964932. The advantages of this set up, IMO, far out-weigh the negatives cause by "interview problem".

I recently interviewed at google, and while I can't talk specifically about questions, I would say that medium to difficult level questions from "Cracking the Coding Interview" are representative of what you must be able to do to a startling (in my opinion) level of efficiency and accuracy. A question like "find the sub matrix with the largest sum in an NxN matrix" is absolutely fair game, at a whiteboard, on the spot.

Think about what it takes to get to this level of competence, where you can pass an exam like this. Granted, google is notoriously tough, but it's pretty common in the industry. And as you point out in your comment, we have to do this over and over.

I read about a guy who passed the bar with 100 hours of study

http://blakemasters.com/post/37113468298/pass-the-ca-bar-exa...

The bar exam (in California) is considered one of those brutally difficult, high barriers to entry that at least you only have to do once (there are training requirements to remain active in the bar).

Now, think about how much time it takes to get up to speed with data structures and algorithms, operating systems, and combinatorics, to the level where you can solve tough problems in 45 minutes to a high level of accuracy with a dry market at a white board, under the additional pressure of an in-person interview. It's hard to even think under those conditions, in my opinion.

I really don't think it's too far off to say that if you do three interviews, at difficult tech companies, you've done something approaching passing the bar.

I've heard a few people here on HN say that while they aren't in favor of a formal barrier to entry like the bar exam, they would happily take an exam like this if it meant that they didn't have to keep doing it over and over. Where they could properly prepare for it, and take it, and pass it for once and for all[1], with a proper study path, under conditions that would be consistent and fair, and get the results back (rather than a mysterious "we don't see a match at this time").

[1] As with many formal credentials, I have no problem with further education requirements to stay up to speed. The problem here is the capriciousness of it all.

Oh yes the other way around. At a previous employer, two of us took 3 full time months to review over 100 qualified candidates (i.e. that returned the task) to make 10 offers.

We made an offer to anybody who met our standards - whilst management initially restricted our headcount, they allowed us to expand the team as great people got in touch and the main restriction ended up being the maximum salary we were allowed to offer (which had us have to give up on half a dozen candidates). (We offered people the chance to show us their FOSS contributions to skip the task, but even those with big reputation couldn't resist tackling the problem.)

That's 3 full time months of not doing ANY work, no output, just full time recruiting, for two people who were probably in the top 10% of the company in terms of compensation.

It's not just expensive in time but also politically, as the team has no output to show for the period.

Where McDowell is correct is in the context of a large company whose hiring needs are very different. But I think that if you are building a small team where every member counts, you have no alternative.

Ugh. I've been in a similar position, assisting with pouring over candidates. The worst part about salary being the limiting factor is you've quite literally wasted your time weeding through the poor candidates to find the honest-to-goodness best to hire - only to not be allowed to have the cream of the crop. It's ridiculous how much time some companies are willing to invest in finding the best talent, only to turn them down because of an extra $10-30k/year. If you're not willing to hire the talent, don't spend the time searching for them. Just post your job ads with your salary expectations, and accept the first people through the door if that's how you're going to operate.

If someone is very junior or has some other discount factor (in practice that's the only real one), you'll probably go lower than expected for a 30 year old with a PhD, freeing budget to bump up someone else.

And sometimes, you get a stellar CV with enough brand on it to make the staunchest McKinsey reconsider his limit policy, so whilst you can't put the number on the ad, you can warn the candidate, get his number, and take a punt on management in case it might work.

The strongest factor for flexibility is when you have a chance to affect the outcomes for the company, but need to prove it before you can claim the pay raises. Then, it makes sense to take somebody at under their market rate, and 3 months later have a chat with management and bump up.

Hiring is a really sensitive topic because HR is often the biggest budget. I once seriously weakened my political position by attempting to automate away "Excel blue collar workers" in another department, which would have lowered the budget and therefore relative power of their boss internally. Those with the most flexibility in hiring (startups, which have no established internal territory to worry about) also have the least resources...

Another strategy too commonly used by poorly run companies. If you feel someone will be worth $X more in only 3 months, they are worth paying that from the start. Kick the employee to the curb before their probation ends if they don't meet your expectations for the full salary. These games some companies will play ("we'll hire you at $x and then in 3 months we promise you'll get another $x") is despicable manipulation of employees' trust.

I worked for one company that did this to any new hire that was a pushover (they tried with me, I only accepted after constant back and forth for "HR approval" of my expected salary which was average market rate at the time). The gimmick is that nobody automatically got the promised raise at 3 months, and nearly everyone who went to fight for it never received it. An employee had to have already embedded themselves deeply enough into a product and be considered a "hero" in order to receive anything. The result was that the great developers would leave after being stabbed in the back, leaving the least talented people in play.

Suffice it to say, I don't even negotiate for salary or vacation time anymore. I request $x and X vacation days, and if the first offer comes back with anything less, I give them one chance to fix it. If the second offer is still shortchanged, I drop them. Unless you are desperate to find a position for financial reasons or you need your first job in the industry, these games being played during the hiring process are a strong indication as to the quality of the employer in general.

You might very well think that; I couldn't possibly comment ;)

I think your strategy makes sense and once one has enough experience and market value to make it work (after all, better be underpaid than unemployed), should be the default to adopt. It also shows strength and signals value to the prospective employer.

FWIW, most of those who came in got a raise later. I put my career on the line every time (and one too many, in the end). Didn't ingratiate me with management but it was my word (not HR's) and I stood by it. If I had one criticism to make to your otherwise accurate comment it is that it is not a company but a person you are going to work for, and one should align with people who share one's values.

Maybe another year or two and I'll have the balls to sign what I write.

Unfortunately, I don't have any much evidence for my next statement, other than bits and pieces, but I think you are not a common case here. I don't think that most companies do anything close to what you're doing with these take home exams. My defense for this statement without much data is that companies are deliberately secretive about this - I understand it is for legal reasons, but I have no idea, none, if anyone even looked at my project.

Remember, McDowell said that this approach allows the company to burn a lot of a candidate's time, but not the other way around", but it doesn't say that they necessarily do. It's just that the equivalence (a 1 hour interview necessarily involves one hour of the company's time) isn't built into the process, it leaves the door for this kind of time wasting and abuse open, and I'm pretty sure lots of companies do abuse it this way.

BTW, if an employer promised to spend 10 hours reviewing my 6-7 hour homework project, with feedback, I'd try to find a way to make the time available, because it would be beneficial to me regardless of whether I got the job. But if they brush me off with a one liner from a recruiter a full month later, and ask people not to post the project to github (even if it might lead to interesting and novel solutions), I'm going to guess that they aren't doing what you're doing with these projects.

  % python -mtimeit -s 'x=1' 'x<<3'
  10000000 loops, best of 3: 0.061 usec per loop
  % python -mtimeit -s 'x=1' 'x*8'
  10000000 loops, best of 3: 0.0602 usec per loop

  % pypy -mtimeit -s 'x=1' 'x<<3'
  1000000000 loops, best of 3: 0.00103 usec per loop
  % pypy -mtimeit -s 'x=1' 'x*8'
  1000000000 loops, best of 3: 0.00103 usec per loop

Some interviewers (not just the "homework") raise their bar by not allowing you to make any tiny mistake. And I just don't get it. If someone is good enough to write something like a lite version of Hacker New website in hours, I'm not going to turn him/her down because of such mistake.

I did interviews at a company for about 2 years and there was constant pressure from management to do trivial crap like that, it finally came to a head and I invited management and one of the "rockstars" to do a mock interview.

When it was evident that the person they thought of as a "rockstar" could not solve these tests(without prior knowledge of the problems), they immediately discounted them as a worthless and stopped bugging me (about that, of course not about everything else).

If I found bit shifting in an interview code sample as a replacement for basic multiplication, I would ask the developer why they chose to do it that way. They'll either a) calmly explain that their computer science classes taught it that way or it's a habit they've adopted after writing code for embedded systems or similar where the optimization actually made a difference, or b) their ego will make an appearance with a "because I'm so senior" attitude. The latter is not a good sign.

My company does 4 hour work-product tests, and we pay each of the candidates for their time. We're in Portland, not SV, so maybe there is a difference in environment.

It shows a level of thought about people that goes beyond ping-pong tables and free pizza and coke (and ironically probably costs less than those things).

Let me guess ... you are happy working there right?

  static const int eight = 8;

  x * eight;

    static const int days_per_week = 8;

When I interviewed at Apple years ago, they gave me a take home program to solve. It was interesting and I enjoyed it a lot. It required some good algo knowledge and had to be written in C. I was told in my face to face that few people ever solve it, and I enjoyed discussing it.

But the rest of the interview was unpleasant - your typical SV brain teaser riddled, algo whiteboard sessions for 4 hours, 2 days in a row. I wasn't really expecting it and wasn't prepared (my fault), so failed miserably. I think I suffered PTSD after that for a while :).

Now I feel preparing for that sort of interview is a huge waste of my own time. It has so little relevance to reality. I'd much rather put that time into building a product or learning some new PL or whatever. At least with a coding test I'm honing skills that I'll use day to day.

I talked to thumbtack for data science. They wanted a 10+ hour takehome project after just speaking to a recruiter because their data scientists were "too busy" to speak to candidates.

Yeah, I'm going to get right on that.

Bet they're bitching about a data scientist "shortage (^1)" as we speak.

(1) data scientist defined as experienced data scientists who want to waste a day's labor before even understanding what they'd be working on and/or speaking to their potential boss

edit: checked my email archive and fixed company name. Apologies...

the response from the recruiter was just "thanks, but the dev team said 'no', that's all the info i have for you"

Any company that does not realize that your time has value before hiring you will probably continue to waste it after hiring you.

There are naive ways to solve certain problems (finding primes), but there is a general guideline that tasks should finish in under one minute (I believe).

I've also soured on take-home test. I recently did a C/C++ one, I know I aced it, and I didn't even get a phone interview.

I figured out afterwards what they were doing. They were giving the take-home test to EVERYONE who applied. Then, after you submit a solution, they read your resume. After looking at my (correct) solution and my resume, they decided I wasn't worth a phone interview.

No more take home tests for me.

Personally I would given them a link to my github which has hundreds of hours of work put into projects. From my experience a homework problem that long doesn't really prove anything (I could have outsourced it) and you never get feedback (this isn't the employer's fault but of laws in the US[1]).

I think a take home quiz is the only appropriate quiz if it's a basic less than an hour quiz. Harder than fizzbuzz but easier than creating a blog from scratch.

Don't even get me started on IQ tests or personality tests.

[1] - http://humanresources.about.com/od/selectemployees/qt/must-e...

Maybe enough responses about never getting contact from employers would make them start treating people like human beings

The process right now seems focused on finding people who are the best at only coding. In the future, do you intend to also consider communication skills? Senior developers act as mentors for junior employees, and often need to coordinate projects across multiple teams.

The best way I can describe the difference in stress is with an analogy. When I visited the Grand Canyon and hiked around the mountain, my body literally froze. I couldn't move a muscle even though my mind knew I could do this and hike around. I knew it was irrational, but I was powerless. This is what interviewing feels like - a fear of heights. And with every rejection letter, the fear is reinforced.

Stress in the office is like playing competitive sports - it's a challenge rather than percieved harm to oneself.

Personally I don't have nervousness/stress issues in interviews, but I've found that conversation screws up the analytical mode that I use when I'm programming. It's like how people say they don't like having their managers interrupt them in the middle of the day because they get taken "out of the zone." I can program or I can converse, I can't do both without screwing up both of them.

That's just my particular conundrum. People probably have all sorts of reasons (besides the possibility of them being bad at programming) for why they may have trouble in interviews.

When I'm thinking about an abstract concept, trying to visualize how the pieces fit together, 'talking it through' is not helpful either. It's really goddamn distracting.

The feedback I got from my last 'cs 101 algorithms whiteboard quiz for a web dev job' was, "You need to talk more and explain what you're thinking." Ugh. Do you want the code or do you want me to talk, because you're not gonna get both.

Personally, I've spent hours working on a project or problem only to find that, be it the result of miscommunication, lack of critical thinking by a manager, or lack of understanding on my part, what I'd created contributed nothing to the bottom line success of our organization.

Anyone, what kind of resources are there to objectively assess a candidates communication skills, leadership ability, and teamwork? What is a constructive way to provide feedback and resources for interviewees about their performance?

Not exactly confrontational (though it could easily get that way if you aren't careful) but just as stressful.

Of course it's far better to avoid such situations, but they do happen.

On the other hand, the time constraints in an interview are immediate: you have a few minutes to come up with a solution to a problem (interviewer will put up with at most 10 minutes of silence or babbling), it's often a zero-to-one problem (usually there isn't a way to have a partial solution) and those factors combine into exponentially increasing sense of pressure: as time goes on you become less likely to solve the problem.

Finally, if this situation does happen at all and, contrary to my claim above, certain people do freeze up, it does so so infrequently as to be immaterial in a hiring decision in the vast majority of cases. Its practical importance is certainly disproportionate to the weight placed on it in interviews.

Person after person says they do fine in the job, yet have trouble with interviews.

I've presented in rooms where the lowest ranking officer was a colonel, and most were important people at the Pentagon. No freeze up, easy peasy, because I know what the hell I'm talking about and because I know I'm not going to be judged on some bullshit evaluation. (re: "x<<8 from above). Interviews are more a crap shoot. I mostly get offers, but sometimes just utterly choke. More importantly, I usually feel miserable after.

Don't make up theoretical situations when you have real, empirical data, please.

I made no comment on what kind of interview works best. I merely observed -- what is certainly true -- that sometimes "defusing the bomb" situations actually do come up in real life, where everything is at stake and you have to work under very severe time pressure.

Do you disagree that such situations sometimes arise in real life?

If not -- if your point is that that isn't necessarily a good reason for interviews to involve such situations -- then I think we are in violent agreement. I am not arguing for defusing-the-bomb interviews. I just don't think it's quite right to say that in real life you never have to defuse a bomb.

I can't imagine there are that many 3-4 hour projects that won't already have available code. The most important part of an at home project in my opinion is the walk through.

The best interview I had asked me to go through the project and explain the what and why I did things and asked for high level understanding of what the framework I chose or the browser/node was doing based on what I wrote.

It was an app in React and they went through why I decided to make a component for x, y but not z and then asked if I understood the virtual DOM as a concept.

To me that's the best you can do, you need to understand how the programmer thinks about problems, works through them and that they are engaged in the ecosystem at large.

IMO it depends on the position. I did a test-project with a follow up code review for my first job and it was a fantastic. If I had not gotten the job, I still would have been happy with the experience and code to show future employers.

If you are interviewing for a more junior or senior position, many candidates are probably switching jobs and are already swamped with work. Also, they probably already have some pet projects they can share. Requiring a test project may seem amateurish.

A company she's interviewing with asked her to do a sample writing task as part of her application/interview. She hasn't decided whether it's worth it or not. For someone who has 15 years experience in the field, excellent recommendations and credentials, spending (her estimate) 12-15 hours doing pro bono work just to apply somewhere is ridiculous.

If you don't value my time before hiring, you definitely are not going to value my time after hiring. Also, if you are incapable of judging a fit based on resume, interviews, and just talking with me, you are not mature enough, experienced enough, smart enough and intelligent enough and have failed the test for being my potential coworker and boss.

Edit: The tests make perfect sense for entry level positions and entry level candidates but once someone requesting tests for experienced positions and candidates, it shows the immaturity of the company, group, team and people who are unable to assess suitability of candidate and place too much emphasis on technical skills and tests as a crutch. The best jobs in my career were those where coworkers and boss had good relationship dynamics. Technical excellence had nothing to do with how well we worked and delivered results.

It even easily pays for itself in just weeding out the bad ones.

If you have billion dollar trading systems and need a cool-headed guy who can talk to VPs or directors in one breath and SAs, DBAs, SAN, Network, etc guys in the next I'm your man.

I applied to head a global support organization, with teams in (from memory) North America, India and Asia Pacific. I'm pretty sure day-to-day would be a mix of employee career management, forward planning with my application development partners to make sure we were prepared capacity and training-wise to take on whatever's next, and crisis management of production issues and the like. Business as usual as they say.

Yet I found myself answering computational complexity questions about hash map insertions. To be fair, before I became quite so management-centric I've found plenty of badly performing code via the usual tools (dtrace, strace, thread dumps), and sql queries using analogous database tools, but at some point you have to rely on technical people to do their jobs.

Am I wrong to think if I'm going to manage a 60-100 person organization across three timezones I don't really need to be under the hood in the code any longer? Or am I clueless?

An organization that does this is hiring stupidly. They have clearly demonstrated via interview that they don't understand the job to be done and/or how to determine that a candidate can do that job. Asking low-level technical questions is a terrible way to answer what I'll guess was the intended "question", something like:

Does this candidate understand the technology and work well enough to make executive decisions grounded in our organization's reality?

On one hand, I totally agree that technical tasks should be left to the technical people, preferably those who are actually working on the system. There's almost nothing worse than a manager trying to take technical decisions out of people's hands.

> Am I wrong to think if I'm going to manage a 60-100 person organization across three timezones I don't really need to be under the hood in the code any longer? Or am I clueless?

On the other, I think people want to work for people they respect and to the extent that people respect technical chops that might be what they are screening for. Though the hash map question sounds like a soft ball, so it might be screening for a baseline of software competence.

But at what point does it become ludicrous? When your CIO is yelling "No, No! You have to enable the EPEL repo or you'll patch to the wrong version!"?

If so, then I would point to those samples and suggest those should be relevant data for assessment and I'd like to get further in the process before putting in extra work for this.

If they're prepared to discuss the matter, great.

If they just give a blank 'sorry, this is our policy,' then walk away. Why? Because if they're not willing to have a discussion with you, that means they don't care about you. It means they think they have a hefty surplus of candidates. Which means you are very unlikely to be the chosen one, and you would probably just waste a lot of your time.

Keep in mind that in today's job market, there are probably 10 people lined up who are willing to do just that.

The question I consider when asked to perform for free: why should anyone simply donate their knowledge to a profitable business after spending a lifetime to attain it?

I personally pushed to make our interview process more centered around a take-home style assignment, as I feel it's a much better approximation of programming skills than an in-person, high stress whiteboarding session, or a quiz on some programming trivia. We try to keep the assignment tightly constrained ("Here's a broken app with x requirements. Fix it.") in order to keep it to a few hours max.

This I feel has been tremendously helpful for us, as I've never seen someone pass the take-home assignment and subsequently do poorly in the technical portion of our interview. Previously we had many people scrub out of our (admittedly pretty easy) technical interviews. Obviously asking for the take-home has resulted in a few false negatives, but I'd much rather an overly strong pre-interview filter to wasting hours of my entire team's time on a crappy interview.

I remember a few months ago, I was applying for an internship with a company and they requested that I write a web app to test coding proficiency before they thought about granting an interview. I spent about 12-15 hours writing the thing, deployed the app to Heroku and put the code on Github. I sent a link to the app and the repo to the recruiter. I never got a response of any kind.

Although some companies do try to make the application experience as pleasant as possible for the applicant, the majority of companies don't give a shit about the people who want to work for them, and make no attempt to respect the time of their applicants. Placing greater demands on the applicant is an easy way to shift more of the workload from the recruiter to the applicant. The applicant is the loser in this situation.

At the other end of the stick, there are those still trying to break in to the field. They may have moved to a new city, they may have worked in a totally unknown firm, they may have taken an "alternative" path through the educational system (and just to be blatantly obvious, the above describes me, circa 5 years ago) - their CVs don't jump out at employers, and as even phone screens are fairly expensive in engineer time, they are not very likely to be given a chance.

Online coding challenges and take-home tests etc are a quick and cheap way to extend an opportunity to more "risky" candidates. I think that's an important element.

(FTR, the company I ended up with, I got through to primarily via a "Who's hiring" thread on HN, however they did operate a "take home" test that took one hour).

And although this system might be more accessible than traditional recruiting, it is far from perfect. It is the job of the community to demand better and more respectful hiring practices from companies. Paying the applicant for the time they spent working on the project or offering a traditional interview for people who work full time and have families would be a good start.

Tons of companies hand out these "homework" tests to hundreds of people without having even the slightest intention of hiring them. F* that.

We always gave really extensive feedback on it, partially because one of the things were were looking for was how people would react to that feedback (I was generally surprised at how many people got defensive about fairly objective observations/questions).

Overall I think it was quite a good data point. It was nice to have a more low-key and extensive complement to the more stressful live whiteboard interview (yes, we did have one of those, and I still think it was useful).

The other benefit of the coding exercise is that it might filter out a certain level of impatience. We don't have coders who can't be bothered to follow [insert team process convention here].

I estimate it would/should take any programmer/problem solver no more than 15, maybe 20, minutes to come up with the solution if they have experience in the language we request they solve it in. The exercise doesn't require specific domain knowledge but should quickly assess whether a programmer, particularly with experience in a different language, is able to learn and apply the syntax and semantics of another language. If they are completely unfamiliar with the language then maybe an hour. They can use whatever references they want. We will check for complete copy/pasted code and alter the requirements and/or test data over time.

The other great benefit is we get to see what/if/how they ask questions to clarify the problem and solution.

EDIT: This exercise is geared towards fresh graduates or developers that don't have experience in the language we use. Can it be gamed? Yes. Might some people not bother? Yes. Are we okay with that? Yes.

Also, the exercise is designed to be original and so a solution can't be Googled.

How can you state that as something absolute? I certainly understand your position, but I would be _glad_ to do something like that. My reasons

- I hate white boards and quizzes. I would fail those, probably.

- I'm not interested in travel time, just because. Give me 'homework' and only meet if you're prepared to make me an offer (other issues notwithstanding - it's okay if you reject me afterwards if I show up without wearing pants) without any more bullshit

- I value my free time, but I also love to work on Things™. Any such 'homework' assignment would be a tiny pet project to drag me away from YT/HN/Awesomenauts and force me to learn something that I might not have picked myself

In fact, I even thought about posting an Ask HN sort of thing to offer (limited somehow, day-job and being a dad and all) working for free in exchange for the input. I just haven't done it so far, because of fear of failure/rejection.

So - you state a good point: People might not want to invest the time. But please speak for yourself only, not for the industry. I very much like the idea of presenting work done at home.

That said, I probably wouldn't do both. If someone asks me quizzes first (and I manage to pass for weird reasons, stars align) I wouldn't invest more hours. You, the employer, just wasted hours with crap while you could've gotten ~reasonable~ accurate ideas about my work. If someone asks me to do one of these assignments, invites me to come over and THEN starts the quiz BS I'd probably get up and leave.

Employers: Pick one way to test my skills. My preference: Judge skills in a remote/async process, use the face time to check for a cultural fit / negotiate / talk about the company, position and job: "We invited you after seeing your work, here's why you should work with us, this is the offer and these would be your coworkers - let's chat and do the tour"

A basic rule of courtesy is that a company shouldn't ask the candidate to invest more time in the process than they are willing to invest.

Most companies will spend an hour or half an hour talking to you on the phone and then give you a project that takes at least 8 hours to do. That's a ridiculous ask. It assumes that the candidate already knows they want to work for your company and is willing to invest that much time to get the job.

They forget that an interview is a 2-way street. The candidate is also deciding if the company is the right fit for them, and being asked to invest a ton of your own time when the company doesn't seem willing to invest theirs is a huge turn off.

There are a lot of advantages to a take-away task - such as being able to write actual code with a computer on your own stack as opposed to just writing on a white board (which some people have problems doing).

However, this type of ask should only come after both the company and the individual have already invested significant and equal amounts of time - enough time for the candidate to be sure (or fairly confident) the company is a place they'd like to work. This means the take-away may only be useful after the on-site, or possibly right before it but after a few rounds where the candidate gets to understand the company better.

It felt very much like they were just exploiting applicants for crowd-sourced ideas.

Even under the current system, at least the waste is symmetric. I give up a few hours of my time, and the company gives up a few hours of its time. There's equity. The mutual work that the company and applicant do offset each other.

A take-home test model skews that balance in favor of the company. An applicant can spend 10 or more hours working the project. The company can run it through an automated testing suite and have a recruiter spend five minutes looking it over. The system is designed to waste more of the applicant's time and less of the company's.

But it's never symmetric. Someone in HR spent time setting up the job posting and managing the process. Someone in management took the time to respond to HR and review your resum, then approve the interview. At least one person at a time is in the interview with you. Then the entire team will spend time afterward breaking it down.

A single hour spent by a bad candidate wastes at least 3 man-hours of work by the company, and most likely more.

So? Companies need employees. They have to do what it takes to get them. If it weren't worth it, they wouldn't do it.

It makes sense to me that more time in aggregate is spent by the company than the candidate, because the company has dedicated recruiting/HR/coordination people that handle the process. I, as an already full-time employed developer, don't have as much time to burn with interviewing.

Wasting candidate time should never be used for screening. At most, steps that take a significant amount of time or effort should be reserved solely for determining the order in which the acceptable candidates receive offers, and the amounts of those offers.

ammon / uptown, I've put off doing my screen-sharing section of your interview process (I got pushed past the phone screen?) due to a lack of time. Maybe adding a way to 'schedule' it would be helpful for those of us that live by our g.calendars....and you all as well.

Other projects are enormous. 40-80 HRs. of work, easily (write an entire web-app!) I did one of these... did not get the offer. I would not want to complete another.