Unemployment is the lowest it's been in decades. Build your emergency fund, and interview until you get your new gig (sidenote: get your finances in order [1]).
The tech sector is a small part of the entire economy from a jobs perspective. They can be picky if they want, but the rest of the economy will absorb talent they won't. Always be able to negotiate from a position of power (ie emergency fund, not needing to take a job you don't want or that is a poor offer). Employers are still adapting to the new norm (having to pay market rate and above, not being able to dictate terms, etc).
Personal opinion: If you're in the position to, decline take home work unless you're being paid. Would you work an unpaid internship?
Look at these unlucky people who can't afford to do an interview because they require 6-10 hour homework assignments.
For all of the talk about getting people into coding, especially non-traditional students, stuff like this really hurts the rhetoric. If you're already working 2 jobs, or have kids, etc, asking someone to do 6+ hours of unpaid work is frankly offensive.
To follow up from my data science job hunt postmortem (https://twitter.com/minimaxir/status/951117788835278848), I agree that the trend of having both an algorithm test and a take-home assignment before an onsite is the new standard for hiring in 2017. For data science, I believe take homes are a better assessment of skill. Fortunately, most of my take-homes were 2-3 hours.
The exception was a take-home that took 16 hours due to its massive scope, which in retrospect I should have rejected.
I don't want to work for a company that expects me to spend a weekend (or fractional weekend) working for free. If they're trying to draw me away from my current employer, they need to do better than that. :shrugs:
I don't get it? That doesn't sound too bad. A brief interview with candidates, a short take home project, and then a final interview seems quite reasonable. There are tons of people applying for jobs, and companies want to make sure candidates care and are actually capable of programming; how else are they supposed to gauge someone's abilities? Just ask how merge sort works, then hand that Rock Star Software Engineer their 100k job?
I like this statement from the replies there: "People here really think a $90k job is owed to them for getting a piece of paper and meeting a few times and answering a few questions right."
I don't know how people are getting hung up on 4-6 hours for a task. I won't even rate any of my software tasks less than 2-4 hours in scrum, because I know that with planning and/or testing no non-trivial task takes just an hour.
4-6 hours for one interview is fine. For 10-30 positions?
When you already have a 60+ hour role and may also have travel+++ ?
When other firms are moving faster to the real meat of the process?
If you assume a freshly graduated engineer with the summer off who is only applying to your firm, then a 10 hour assignment is reasonable. Heck an unpaid internship for the summer is fine for both sides.
If you're in a competitive market hiring for reasonably normal positions, you'll have a bad time.
Firms that are offering unique, incredibly highly compensated, strategic positions can require substantial effort and investment by candidates. Or firms where there is so much competition for a few roles that they can be exceptionally demanding despite low pay and poor conditions.
You need to make an honest assessment of where you really fit to see if your demands are reasonable.
> 4-6 hours for one interview is fine. For 10-30 positions?
Exactly! When time commitment is symmetrical, the companies would only move forward with candidates they are seriously considering to hire. Because for a 4 hour interview session with a candidate, they have to invest at least 4 hours of their engineers' time. Probably more, as there is typically more than one interviewer present at a time.
The company may spend only 10 minutes on average to review an assignment. Most of the submissions are dismissed in the first 5 minutes for something trivial or subjective. The more interesting ones get more attention, maybe 30 minutes of the company's time. Suddenly, "interviewing candidates" get cheaper. And as is the case with supply and demand, decreased price increases consumption.
Before, the company would have invited only 10 candidates for an in-depth interview for each position. Taking 4 hours of the time of each candidate, 40 hours in total, and spending 40 hours themselves. Now, they can give assignments to 240 candidates. That would waste about 1000 hours of candidates' time, while taking the same 40 hours from company time.
If it catches on, for every job, instead of sending 100 resumes, having 20 phone interviews and 5 in-person interviews (arbitrary numbers), you would have to send the same 100 resumes, get 20 phone interviews and 20 assignments, plus a couple of in-person interviews. Suddenly the cost of getting jobs increases multiple times for the candidate, while staying the same for the company.
"I like this statement from the replies there: "People here really think a $90k job is owed to them for getting a piece of paper and meeting a few times and answering a few questions right.""
At the same time, these companies are complaining about there being a "developer shortage".
My partner is an accountant, shortly to be a CPA. She's capable of making $90K a year. If she, or anyone she knows in the field was told "Hey, here's a set of books. Bring them back, balanced." was a part of her interview experience?
I really disagree with this. Yes it’s crappy if you put in many hours and don’t get the job. Interviewing sucks for everyone. But having been on both sides of this equation (hiring and being hired), I believe the take home is the best chance to evaluate someone. They’re able to work without the pressure of someone staring at them and clock ticking, given google and all their normal ways of working, and something long enough to be able to more realisticly assess them.
It’s amazing what a short assignment can tell you about a person, and it makes the follow up on site productive because there are so many ways to ask about their work.
Personally for Apple I asked specifically to be given one of these instead of the whiteboard, as I get overly stressed in a “pop quiz” type setup. They still ended up pop quizzing me twice, and one of them I didn’t do well on. It was my take home that pushed me over the edge and got me hired.
I spent multiple hours on one assignment, only to have the guy tell me off in a 2 min email. Didn't even have the courtesy to give me a call and let me justify the decisions I made with the code.
If you want me to spend more than 30 minutes programming for you, that's called work, and I would like to get paid for that.
They shouldn’t be asking you to code anything related to their actual work — it should be a toy assignment.
I think it all comes down to personal pref, but the data seems to show that whiteboard interviews are good to filter middle of the road talent, but top/bottom can look the same.
That's bullshit. When I was hiring I needed a Skype/Phone call, and 1 hour of on-site or just another more technical call/interview (1-2 hours max if it goes really well). Hired 3 great folks and 1 that decided it's not a job for him, because he found it boring after all.
I never take the "a couple hours long assignments" because the scope is never "a couple hours", once company wanted me to build a chat service that would take at least 20 hours of work to get properly done with testing, etc.
I'm talking one that I recall that asked for parsing Apache logs from a stream, displaying moving averages for most popular URLs, aggregates of visitor counts, having high water mark "alerts" for ingress traffic and monitoring rolling averages to "de-alert" when traffic dropped below that, including of course unit tests and documentation...
One, that's more than a couple of hours. And two, that sounds awfully like something you're planning to use, whether I'm hired or not...
Not everyone performs well in a technical call, especially since the questions rarely correlate with the daily job / workflow. Sounds like you found people who did.
NO FREE CODE. After getting through the recruitment hell I settled for one important rule for my sanity - symmetric time and effort involvement, i.e. pair programming with the engineer, onsite session with the team. Otherwise the project will likely be rejected for the most trivial reason but in fact most probably because of finding someone more desperate and cheaper. And yes, I've been on the other side as well interviewing people once.
This is probably the single best interview session I've ever had. Give-and-take is always good for easing the process, but in one case I had a programmer actually sit down with me at a laptop and pair program our way through an hour task. Still time pressure, I suppose, but it was vastly more natural and informative than any other interview I've done.
I had one person say after I put in 4 hours "The code wasn't clean". That was his feedback.
I pressed him and he eventually said "I ran this by 3 Senior Python experts I know. All of them said the code wasn't good." No other details.
Before he even gave me the assignment he made his decision. He lied about asking 3 other people.
Coding assignments are always one sided. Unless someone from the company is going to sit with me and invest equal hours into the project, I will never do another one.
They are used by companies to filter out desperate employees (young engineers who don't have reputation to fall back on, or nothing to lose by doing it) and it signals a lower value to the company.
Perhaps the opportunity of the assignment was to “right the record,” hoping to be surprised. It would have been nice to be more upfront about that.
I disagree with the notion of desperate employee — I’m anything but that, but I prefer a take home to show my engineering worth rather than a whiteboard if those are the two choices. Of course if you’re super famous then you probably won’t get either, depending on the company and it’s processes. That said I’ve been down the M&A path and still got (many) whiteboard interviews.
From reading the Reddit post, I think it's the combination of a take-home assignment plus the standard on-site whiteboard test battery that the OP was arguing against, and I admit I'm sympathetic to that. I remember interviewing at one place a few years back that had a relatively complex at-home assignment -- you had to write code that would hit various URLs that would return a string containing a long basic math formula (e.g., "1234-(3529(42-34)/2)+45", but going on for ~60 characters), write code that would parse that string to produce the result, then hit another URL pointed to by the result, while treating all the results as a node graph you needed to find the shortest path through. Granted, I'm one of those annoying self-taught programmers without a computer science background, so I probably found that a bit harder than someone recently out of school with these algorithms fresh in their mind -- but I got through the challenge correctly, wrote pretty nicely-structured and commented code to boot...which was, as far as I can tell, completely ignored* by the interviewers, who just asked me more on-the-spot algorithm questions instead.
I've been at other interviews in which the on-site interview is a walkthrough of the code I'd written, asking questions about why I made various choices. I think this is really a much better way to do programming interviews. It still weeds out people parroting code without understanding it, but it's a better example of what a candidate's actual code looks like -- and for the vast majority of programming jobs, that's probably more important than whether they've memorized algorithms that rarely come up outside other whiteboard tests.
> Personally for Apple I asked specifically to be given one of these instead of the whiteboard, as I get overly stressed in a “pop quiz” type setup. They still ended up pop quizzing me twice, and one of them I didn’t do well on.
I get a brain freeze when the clock is ticking. I've been practicing with ticking clock but its still hard.
None of the companies showed even 1% flexibility with their process. They say its a standard and they can't compare candidates if they use different methods for everyone.
I'm split on this. If it's <=1hr of work I wouldn't be super upset. I also don't mind whiteboarding as long as it's not just a bunch of banal garbage that google could divulge in a microsecond but unfortunately most interviewers go for the low hanging fruit. At the end of the day, companies aren't going to want to wait a ton of time to complete the interview because they usually want someone yesterday so I doubt that they're going to want to go to a 17 interview series to vet people.
I run coderfit.com, we match programmers with tech jobs in Zurich, Munich and NYC.
Since a long time I try to educate companies to at least pay a symbolic sum to the engineer, like 10-20 USD/hour.
The reason companies don't do this is because they think that if the programmer fails, paying 100 USD for "nothing" is a waste (x). Most don't value the positive reputation and word of mouth this will generate. They just assume that if you're rejected they will never meet you again and after all you "agreed" to do a free homework task, so you are not supposed to be pissed.
(x) Paying recruitment agencies five figures however feels okay because it is somewhat linked to the success of contributing bringing a new person in.
This is my educated guess why they are not doing this. 100 USD for a company is like, nothing but you have to get it approved and so on.
Also many companies live in the illusion people are supposed to be excited to work for them or even worse they think they're Google although most lack the brandname. They look at how Google hires and think "Google is successful", so we just copy them, which will make us successfull, too. Well, this is a guaranteed way to fail because Google can allow themselves to do this due to Sergey Brin & Larry Page who turned tech into value, which turned into prestige/brand. This reminds me of PG, who wrote in one of his essays: "Prestige is just fossilized inspiration. If you do anything well enough, you'll make it prestigious"
Similar results with codescreen.io. Originally I was charging $50/screen which is exactly what I was given per phone screen. Feedback is that $50 is too expensive even though we're seeing the same results and providing reports and a study suggestions for the candidates (which is how I decided to minimize completely wasting a candidates time).
People place a lot of value on human to human interaction.
> No matter what bs the recruiter trys to tell you, take home assignments are cheap ways to evaluate and screen out candidates. You spend X hours finishing the assignment, they spend 30 minutes or less judging it, pretty disrespectful if you ask me.
Or less...
Slightly off topic but a tip to companies that give these tests who might be reading.
If you must give a technical assessment I'm a fan of giving the candidate unit tests and asking them to write code that passes.
Then you have a slightly different unit test on your end. Same algorithm but different input values so they can't just cheat and write code that just echo's the expected results.
If the unit tests pass the candidate passes. If the unit test partially fails on a small number of the unknown values it's not an immediate fail for the candidate. I'll usually look at the code for 10 minutes and see why it failed.
I also recently went through the Coinbase interview process, and was pleasantly surprised that they offered this compensation for the take-home interview part.
Overall, a 4-6 hour task, to be completed on your own over a 1-week period, seems reasonable to me.
I have been outright refusing to do take-home tests and coding challenges. I do not care if it means fewer opportunities. They are not worth the stress. In a few cases the employer waived them, sometimes they tried to cajole me into doing it, a few other times there was hand-waving and excuses on their side.
I'd be concerned that these take-home assignments were really jobs the company needed done and were willing to solve Mechanical Turk-style, only with unpaid Mechanical Turks.
I work at a company where a “take home” assignment is a routine part of evaluating candidates who have made it through the initial screenings and face-to-face discussions. However, we set up all such assignments as small contracts (say 2 - 10 hours, depending on the candidates availability, the position, etc). We pay market rates and try to be as accommodating as possible; sometimes, a candidate just can’t fit it in, so we find alternatives or take more of a risk when we offer them a job. In general, however, it’s a great system for us and, I feel, very fair. I see it as a cost of recruiting and risk mitigation.
Agreed. I did about 4 of those in a few months and got rejected each time, with no explanation at all. One of these was for a teaching position. Really a waste of time if you ask me. I learned nothing and wasted many hours. If a company wants to see what my code looks like, I have many projects available on GitHub.
The only time I did one of these and actually got accepted, they used it as a justification for negotiating down my salary. "Your code was about 5 out of 10 on subjective code quality cool points, so we're cutting your offer by $10,000." Then they cut me loose after 6 months because the project was "over." This was for a full-time position.
Now, if I get asked to do a take-home assignment, I ask instead if I can pair program with an engineer for an hour. If not, then I probably won't even continue because they clearly don't respect their engineers' time.
The applications and stacks nowadays are so complex that yes, it's basically "anything you do will be used to lowball you" situation. Unless one creates fully compliant, fully featured application running on CI server. For free. And then begs for feedback.
I was told many times that they don't have time to objectively evaluate this so they don't even look at these. Even the companies that explicitly ask for this never look at those.
With code submissions they said they can objectively compare cadidates since they were measured by the same yardstick.
"They don't have time to objectively evaluate this," to me, sounds like, "Our engineers follow extremely rigid and obtuse coding standards that have no relation to the outside world, and are unable to read or understand code written by anyone outside our company."
On being measured up with other candidates, I'd really rather they assess me based on my skills and experience, not on a time-unlimited mini-project. The major factor in those projects is free time. I am always going to lose to a person with more free time than me, even though I may outmatch them in skills and experience. And if all they're looking for is someone with a lot of free time, that's not the sort of job I'm looking for anyway.
There are two kinds of companies: those with a high hiring bar, and those with a low one. It's less work to get a job at low-bar companies, so why would you apply to a high-bar company?
If the caliber of people you work with is a major factor in how much you enjoy working somewhere, you should be applying to high-bar companies even though it's more work.
Caliber of co-workers matters more or less with different kinds of work. In a tight software development team, a small number of doofuses or toxic people can make working there awful. In a typical outside sales team, co-worker competence might not matter as much because you're each closing deals independently. So there's no single answer.
The state of the interview process in tech shows that unfortunately many developers are seen as pushovers and weak people by wider society, mostly importantly by the people hiring. They put up with a lot of crap that others would say 'uh, no' to. Worse if promoted to middle manager they'll turn around and whip their own kind hard all in an effort to server the masters.
Take home assignments are as perfect as it gets (the assignments need to align with the role you have and there are also some challenges related to the scalability of the process and, in some cases, cheating). It filters those who think they are too good for it and it gives an opportunity for those who are competent and eager enough and those who don't do so well under stress when they are interrogated in front of a whiteboard (most people).
Those who complain that it takes too long to do homework assignments are not being honest about the actual time it takes to prepare for the traditional trivia-based interviews where it takes weeks and sometimes months to prepare. Somehow it's hard to find 2 - 3 hours for a homework assignment, but 6 month to prepare for a quiz interview is totally ok. Exaggerating a bit to make a point ;-)
Technical interviewing shouldn't be a separate skill engineers have to master because nobody wins here. The companies get people who are good at interviewing instead of doing the actual work the companies care about. Of course, the communication part of the interview is important because the engineers will need to work in a team environment.
It's obviously none of my business, but I can't help but be curious whether you are currently responsible for hiring decisions, and if so whether or not you use take home assignments, and finally if so whether or not it is paid for. Or perhaps as an employee the process worked out for you. In either case, more details documenting how take home assignments work best in practice would always be appreciated!
A take home assignment beats many alternatives, but places the entire burden on the potential employee (employers love it!).
This is my position on both sides. I'll pick a homework assignment anytime when I have a chance as a candidate. I have lots of life commitments and this is one of the big reasons why I like it. I also like it because it's an opportunity to shine and be creative (it depends on the assignment, of course).
Yes, it's not perfect because you can end up dealing with somebody who doesn't like how you comment your code or they don't like your tests... It's actually a good thing in most cases because it also filters out the companies where you wouldn't want to work anyways.
It's an opportunity to have a meaningful and relevant conversation.
Not all assignments are created equal. Like with anything it has to be well done.
When I hire people I craft the assignments for each candidate depending on the role and the person on the other side. It's also important to communicate the expectations and the desired outcomes. And it's also important to give an opportunity to the candidate to have a follow up requirements discovery step where they can ask any questions about the assignment.
Are you hiring 50% plus of the candidates that did the homework assignment for you? At 10% hiring rate, a candiate will have to do 20-30 hours worth of assignments for all the companies they interview, and I haven't once gotten an assignment that takes less than 5-6 hours.
There are a lot of details and finer points that need to be considered, of course. The quality of the assignments and how the process is executed are big factors here. It's also important for the assignments to have a well defined scope. Having an opportunity to ask follow up questions is also important (also mirrors the actual software development process where the requirements might be a bit fuzzy).
Homework assignments do have an effect on the job searching strategies. It's not ideal to do a homework assignment for 10 companies at the same time, but usually you can serialize the process where you can work on the assignments sequentially.
The best I've recently encountered were "1-2 hours" assignments with the words "enjoy the task!" or something similar. FUCK YOU. I'm going to print it, I'm going to find you, and I'm going to stick it up your butthole.
I won't say I agree with most interview processes for software, but here's more food for thought:
CPAs presumably have been externally certified, so perhaps you only need to check "team fit" things.
Sales interviews: if you can't sell me on yourself, why would I hire you? The interview is enough.
Lawyers I would assume have some number of public items for me to look at.
Software engineers: none of that applies. If they've contributed to open source, maybe you can look at that, but many of the great engineers I've worked with have not.
You're making an assumption that the tech screening process actually screens people on a criterion that matters. But nobody measures the false-negative rate, so they have no idea.
I've now worked at places that did CTCI interviews and "traditional" interviews, and I've noticed no difference in overall quality amongst the employees. I've known plenty of idiots who work at big, famous tech companies, and plenty of amazing people who never ran the whiteboard gauntlet at GooAmaFaceSoft.
My opinion has evolved: tech interviews are the result of generations of cargo-culting amongst a group of people who copied Microsoft, and never really questioned their assumptions. They're just as random and noisy as any other kind of interview, but far more arrogant. Spolsky was right that you should do a FizzBuzz test, but that's it. That's all you need. Everything else should be about communication, personality and the other intangibles that matter far more for every job that involves working with other people (which is all of them).
I half-agree, but Spolsky also makes an excellent argument in "Hitting the High Notes" [0] that there is disproportionate value delivered from excellence, as opposed to mere competence ("Five Antonio Salieris won’t produce Mozart’s Requiem. Ever. Not if they work for 100 years.").
FizzBuzz + short work sample + strong communication skills is probably not that far from optimal if you want to hire lots of people who are competent and work on problems that they have solved before. Note that I said "optimal" and not "good"; this is still a noisy process.
But if you're doing something where you need to people to excel beyond what they've done before, and perhaps beyond what your company has ever done before, then I think it's naive to think that additional testing for things like on-the-spot thinking, creativity, and diligence under pressure convey no useful signal. This, in my opinion, is an extraordinary claim and requires strong evidence before anyone should take it seriously.
"But if you're doing something where you need to people to excel beyond what they've done before, and perhaps beyond what your company has ever done before, then I think it's naive to think that additional testing for things like on-the-spot thinking, creativity, and diligence under pressure convey no useful signal. This is, in my opinion, an extraordinary claim and requires strong evidence before anyone should take it seriously."
The extraordinary claim is that whiteboard testing (or take-home projects, or...well, anything in the current tech interview) does any of those things.
You can't whiteboard-test for excellence. Excellence is both contextual (i.e. it depends a lot on your company, team, culture, etc.), and based mostly on squishy, intangible factors that go beyond "code": picture the brilliant coder who dons his headphones, falls down a hole, and produces a pile of undocumented, complex code of zero business value. It's a cliche, but do we interview for it? No. We ask people to do a graph search on a matrix.
My contention is that we'd do far better with some simple, basic screens for technical competency, and then spending most of our time on communication skills, personality, clarity, organization, planning, business sense and team fit.
...but of course, these are questions with no single correct answer, so engineers are afraid of them.
> The extraordinary claim is that whiteboard testing (or take-home projects, or...well, anything in the current tech interview) does any of those things.
This is just a naked assertion. This kind of testing happens in many places and industries, and many people seem to believe it's useful. Maybe they're all deluded, but that's precisely why I'm calling it an extraordinary claim.
Do you really think it is obvious, prima facie, that asking people to demonstrate some skills on their feet, or to do a short sample of work for you, tells you nothing about their ability to do good work? If so then I suppose we'll have to agree to disagree.
Edit: I'll add that I personally "interviewed for excellence" as a professor for many years. There was, as far as I could tell, no doubt among professors that interviewing was a non-trivially useful part of evaluating a candidate for graduate school. Again, maybe we were all deluded. But that's a claim that demands some proof.
"This is just a naked assertion. This kind of testing happens in many places and industries, and many people seem to believe it's useful. Maybe they're all deluded, but that's precisely why I'm calling it an extraordinary claim."
Provide evidence that coding interviews does what you want it to do. Saying that "other people do it, and therefore it must work" is cargo-cult analysis.
I'm trying not to be a jerk here, but I already know the answer: there's no evidence. People do this stuff for exactly the same reason you're biased toward doing it -- because someone else with a big name did it, and nobody goes wrong by doing what Google does!
"Do you really think it is obvious, prima facie, that asking people to demonstrate some skills on their feet, or to do a short sample of work for you, tells you nothing about their ability to do good work?"
I think it tells you something about that person's ability to do the skill you've tested. Sort of. Under extreme pressure.
Does asking people to code on a whiteboard tell you how they're going to work with their peers, communicate clearly and efficiently, document their code, focus on business goals, and generally not be an asshole (all of which are far more important skills for success in a group)? No.
Even as far as coding ability goes, I've many, many "brilliant programmers" who eat leetcode problems for breakfast but can't be trusted to write clean code on their own. It's a borderline useless signal.
I will fully agree with you that many interview practices are bad and "cargo cult". I'm just saying that I disagree on where the burden of proof is. The fact that large fractions of the industry do it and seem to believe that it has some value is , in my mind, what establishes this belief as the norm — in distinction to the belief that these practices have zero value, which is (again in my opinion) an extraordinary claim.
I'm saying "lots of people do it, I can give theoretical arguments for why it might be useful, and it seems common across industries, and this is the only industry I've seen that has a meme about it being totally useless ... so I'd like to see some evidence that it's useless". You're saying "prove that it's useful". We disagree on which direction bears the burden of proof.
Edit: to provide something a bit more explicit, the kind of thing that I would consider persuasive here (again just my opinion) would be several companies that have succeeded like Google, Amazon, Facebook, Microsoft but have employed hiring practices based just on FizzBuzz and communication skill evaluation.
“Five Antonio Salieris won’t produce Mozart’s Requiem. Ever. Not if they work for 100 years.”
Can I just point out how absurd this argument is? Even putting aside the issue of Salieri’s talent (which he had in abundance), the fact is that most of the Requiem wasn’t even written by Mozart, except for scattered bits here and there. And as far as the movement that everyone knows is concerned — “Lacrimosa” — Mozart only penned the first eight bars!
So yes, even people with a fraction of Mozart’s talent have and will continue to create things that are just as good as his own work. (Heck, maybe even better!) The rest is inspiration and marketing.
I am too ignorant of musical history to evaluate the analogy, but taking the myth-story as given in popular understanding (presumably based on "Amadeus") I think the content of the argument is clear, even if he picked terrible examples to highlight his case.
Having said that, I appreciate you pointing out these facts about Salieri and Mozart. Thank you for educating me a bit today!
Not that I don't agree... but for a CPA, lawyer, engineer, and many other professions you have to go through years of education and rigorous testing to acquire the titles. We pull down some of the highest salaries in the US, we have incredible responsibility, and our profession requires zero formal education or testing to prove our abilities. It shouldn't be too far fetched to understand why some companies feel the need to vet their candidates.
Meh. I enjoy take home assignments because I can add that as a skill to the resume when done and some are actually pretty fun. Now I doubt I'd do something like "here's a CloudFormation template with a hundred different resources, now make it work with another cloud platform," but something like "build a few docker containers running nginx through docker compose, and automate some random manual tasks through scripting" is doable.
I think this could be tempered by a "check in everything you've got after __ hour(s)" time limit. Maybe allow requesting the problem details whenever ready and expecting a response within a given time frame?
This definitely ups the pressure, and things like hardware/internet failures would muddy the waters.
It sounds like even a commitment guaranteeing opportunity for discussion & feedback would be enough to satisfy several commenters here, but that is rare for liability reasons when employees are turned down.
Take home assignments should be illegal.
It makes the field unattractive even if the pay is high. Doing work without any payment and for hours of your own time. I think it's time that developers realize we're all a bunch of push overs and maybe should unionize for some standard requirements to keep us all sane from abuse.
81 comments
[ 3.9 ms ] story [ 131 ms ] threadThe tech sector is a small part of the entire economy from a jobs perspective. They can be picky if they want, but the rest of the economy will absorb talent they won't. Always be able to negotiate from a position of power (ie emergency fund, not needing to take a job you don't want or that is a poor offer). Employers are still adapting to the new norm (having to pay market rate and above, not being able to dictate terms, etc).
Personal opinion: If you're in the position to, decline take home work unless you're being paid. Would you work an unpaid internship?
[1] https://i.imgur.com/CcEVQAV.jpg
For all of the talk about getting people into coding, especially non-traditional students, stuff like this really hurts the rhetoric. If you're already working 2 jobs, or have kids, etc, asking someone to do 6+ hours of unpaid work is frankly offensive.
The exception was a take-home that took 16 hours due to its massive scope, which in retrospect I should have rejected.
I like this statement from the replies there: "People here really think a $90k job is owed to them for getting a piece of paper and meeting a few times and answering a few questions right."
I don't know how people are getting hung up on 4-6 hours for a task. I won't even rate any of my software tasks less than 2-4 hours in scrum, because I know that with planning and/or testing no non-trivial task takes just an hour.
When you already have a 60+ hour role and may also have travel+++ ?
When other firms are moving faster to the real meat of the process?
If you assume a freshly graduated engineer with the summer off who is only applying to your firm, then a 10 hour assignment is reasonable. Heck an unpaid internship for the summer is fine for both sides.
If you're in a competitive market hiring for reasonably normal positions, you'll have a bad time.
Firms that are offering unique, incredibly highly compensated, strategic positions can require substantial effort and investment by candidates. Or firms where there is so much competition for a few roles that they can be exceptionally demanding despite low pay and poor conditions.
You need to make an honest assessment of where you really fit to see if your demands are reasonable.
Exactly! When time commitment is symmetrical, the companies would only move forward with candidates they are seriously considering to hire. Because for a 4 hour interview session with a candidate, they have to invest at least 4 hours of their engineers' time. Probably more, as there is typically more than one interviewer present at a time.
The company may spend only 10 minutes on average to review an assignment. Most of the submissions are dismissed in the first 5 minutes for something trivial or subjective. The more interesting ones get more attention, maybe 30 minutes of the company's time. Suddenly, "interviewing candidates" get cheaper. And as is the case with supply and demand, decreased price increases consumption.
Before, the company would have invited only 10 candidates for an in-depth interview for each position. Taking 4 hours of the time of each candidate, 40 hours in total, and spending 40 hours themselves. Now, they can give assignments to 240 candidates. That would waste about 1000 hours of candidates' time, while taking the same 40 hours from company time.
If it catches on, for every job, instead of sending 100 resumes, having 20 phone interviews and 5 in-person interviews (arbitrary numbers), you would have to send the same 100 resumes, get 20 phone interviews and 20 assignments, plus a couple of in-person interviews. Suddenly the cost of getting jobs increases multiple times for the candidate, while staying the same for the company.
This is not good.
At the same time, these companies are complaining about there being a "developer shortage".
There wouldn't be an interview.
It’s amazing what a short assignment can tell you about a person, and it makes the follow up on site productive because there are so many ways to ask about their work.
Personally for Apple I asked specifically to be given one of these instead of the whiteboard, as I get overly stressed in a “pop quiz” type setup. They still ended up pop quizzing me twice, and one of them I didn’t do well on. It was my take home that pushed me over the edge and got me hired.
If you want me to spend more than 30 minutes programming for you, that's called work, and I would like to get paid for that.
I think it all comes down to personal pref, but the data seems to show that whiteboard interviews are good to filter middle of the road talent, but top/bottom can look the same.
I never take the "a couple hours long assignments" because the scope is never "a couple hours", once company wanted me to build a chat service that would take at least 20 hours of work to get properly done with testing, etc.
I'm talking one that I recall that asked for parsing Apache logs from a stream, displaying moving averages for most popular URLs, aggregates of visitor counts, having high water mark "alerts" for ingress traffic and monitoring rolling averages to "de-alert" when traffic dropped below that, including of course unit tests and documentation...
One, that's more than a couple of hours. And two, that sounds awfully like something you're planning to use, whether I'm hired or not...
This is probably the single best interview session I've ever had. Give-and-take is always good for easing the process, but in one case I had a programmer actually sit down with me at a laptop and pair program our way through an hour task. Still time pressure, I suppose, but it was vastly more natural and informative than any other interview I've done.
I pressed him and he eventually said "I ran this by 3 Senior Python experts I know. All of them said the code wasn't good." No other details.
Before he even gave me the assignment he made his decision. He lied about asking 3 other people.
Coding assignments are always one sided. Unless someone from the company is going to sit with me and invest equal hours into the project, I will never do another one.
They are used by companies to filter out desperate employees (young engineers who don't have reputation to fall back on, or nothing to lose by doing it) and it signals a lower value to the company.
I disagree with the notion of desperate employee — I’m anything but that, but I prefer a take home to show my engineering worth rather than a whiteboard if those are the two choices. Of course if you’re super famous then you probably won’t get either, depending on the company and it’s processes. That said I’ve been down the M&A path and still got (many) whiteboard interviews.
I would be shocked if any company in the world gives you this choice.
I've been at other interviews in which the on-site interview is a walkthrough of the code I'd written, asking questions about why I made various choices. I think this is really a much better way to do programming interviews. It still weeds out people parroting code without understanding it, but it's a better example of what a candidate's actual code looks like -- and for the vast majority of programming jobs, that's probably more important than whether they've memorized algorithms that rarely come up outside other whiteboard tests.
I get a brain freeze when the clock is ticking. I've been practicing with ticking clock but its still hard.
None of the companies showed even 1% flexibility with their process. They say its a standard and they can't compare candidates if they use different methods for everyone.
Companies will differ depending on the role, team, and who’s interviewing you.
Since a long time I try to educate companies to at least pay a symbolic sum to the engineer, like 10-20 USD/hour.
The reason companies don't do this is because they think that if the programmer fails, paying 100 USD for "nothing" is a waste (x). Most don't value the positive reputation and word of mouth this will generate. They just assume that if you're rejected they will never meet you again and after all you "agreed" to do a free homework task, so you are not supposed to be pissed.
(x) Paying recruitment agencies five figures however feels okay because it is somewhat linked to the success of contributing bringing a new person in.
This angers me, as it suggests the programmer wasting time for nothing is fine..
Also many companies live in the illusion people are supposed to be excited to work for them or even worse they think they're Google although most lack the brandname. They look at how Google hires and think "Google is successful", so we just copy them, which will make us successfull, too. Well, this is a guaranteed way to fail because Google can allow themselves to do this due to Sergey Brin & Larry Page who turned tech into value, which turned into prestige/brand. This reminds me of PG, who wrote in one of his essays: "Prestige is just fossilized inspiration. If you do anything well enough, you'll make it prestigious"
People place a lot of value on human to human interaction.
Or less...
Slightly off topic but a tip to companies that give these tests who might be reading.
If you must give a technical assessment I'm a fan of giving the candidate unit tests and asking them to write code that passes.
Then you have a slightly different unit test on your end. Same algorithm but different input values so they can't just cheat and write code that just echo's the expected results.
If the unit tests pass the candidate passes. If the unit test partially fails on a small number of the unknown values it's not an immediate fail for the candidate. I'll usually look at the code for 10 minutes and see why it failed.
I really appreciated it, and I’ve decided to adopt that as a policy in my future hiring.
Overall, a 4-6 hour task, to be completed on your own over a 1-week period, seems reasonable to me.
http://www.smashcompany.com/technology/embarrassing-code-i-w...
The only time I did one of these and actually got accepted, they used it as a justification for negotiating down my salary. "Your code was about 5 out of 10 on subjective code quality cool points, so we're cutting your offer by $10,000." Then they cut me loose after 6 months because the project was "over." This was for a full-time position.
Now, if I get asked to do a take-home assignment, I ask instead if I can pair program with an engineer for an hour. If not, then I probably won't even continue because they clearly don't respect their engineers' time.
I was told many times that they don't have time to objectively evaluate this so they don't even look at these. Even the companies that explicitly ask for this never look at those.
With code submissions they said they can objectively compare cadidates since they were measured by the same yardstick.
On being measured up with other candidates, I'd really rather they assess me based on my skills and experience, not on a time-unlimited mini-project. The major factor in those projects is free time. I am always going to lose to a person with more free time than me, even though I may outmatch them in skills and experience. And if all they're looking for is someone with a lot of free time, that's not the sort of job I'm looking for anyway.
If the caliber of people you work with is a major factor in how much you enjoy working somewhere, you should be applying to high-bar companies even though it's more work.
Caliber of co-workers matters more or less with different kinds of work. In a tight software development team, a small number of doofuses or toxic people can make working there awful. In a typical outside sales team, co-worker competence might not matter as much because you're each closing deals independently. So there's no single answer.
Those who complain that it takes too long to do homework assignments are not being honest about the actual time it takes to prepare for the traditional trivia-based interviews where it takes weeks and sometimes months to prepare. Somehow it's hard to find 2 - 3 hours for a homework assignment, but 6 month to prepare for a quiz interview is totally ok. Exaggerating a bit to make a point ;-)
Technical interviewing shouldn't be a separate skill engineers have to master because nobody wins here. The companies get people who are good at interviewing instead of doing the actual work the companies care about. Of course, the communication part of the interview is important because the engineers will need to work in a team environment.
That's one way to put it!
It's obviously none of my business, but I can't help but be curious whether you are currently responsible for hiring decisions, and if so whether or not you use take home assignments, and finally if so whether or not it is paid for. Or perhaps as an employee the process worked out for you. In either case, more details documenting how take home assignments work best in practice would always be appreciated!
A take home assignment beats many alternatives, but places the entire burden on the potential employee (employers love it!).
Yes, it's not perfect because you can end up dealing with somebody who doesn't like how you comment your code or they don't like your tests... It's actually a good thing in most cases because it also filters out the companies where you wouldn't want to work anyways.
It's an opportunity to have a meaningful and relevant conversation.
This sounds like the key and something many who complete take home assignments don't get.
[edit] Thanks for taking the time to add a bit more context.
When I hire people I craft the assignments for each candidate depending on the role and the person on the other side. It's also important to communicate the expectations and the desired outcomes. And it's also important to give an opportunity to the candidate to have a follow up requirements discovery step where they can ask any questions about the assignment.
There are a lot of details and finer points that need to be considered, of course. The quality of the assignments and how the process is executed are big factors here. It's also important for the assignments to have a well defined scope. Having an opportunity to ask follow up questions is also important (also mirrors the actual software development process where the requirements might be a bit fuzzy).
Homework assignments do have an effect on the job searching strategies. It's not ideal to do a homework assignment for 10 companies at the same time, but usually you can serialize the process where you can work on the assignments sequentially.
Does this happen with experienced positions open in other departments?
Are experienced CPAs interviewing for the new position in Accounting required to balance an example set of books?
Are experienced Sales interviewees expected to go out and sell a sample product before being hired?
A lawyer for Legal expected to write a sample brief or appear before the court in a sample trial?
HR expected to do sample HR things?
Think about it.
CPAs presumably have been externally certified, so perhaps you only need to check "team fit" things.
Sales interviews: if you can't sell me on yourself, why would I hire you? The interview is enough.
Lawyers I would assume have some number of public items for me to look at.
Software engineers: none of that applies. If they've contributed to open source, maybe you can look at that, but many of the great engineers I've worked with have not.
I've now worked at places that did CTCI interviews and "traditional" interviews, and I've noticed no difference in overall quality amongst the employees. I've known plenty of idiots who work at big, famous tech companies, and plenty of amazing people who never ran the whiteboard gauntlet at GooAmaFaceSoft.
My opinion has evolved: tech interviews are the result of generations of cargo-culting amongst a group of people who copied Microsoft, and never really questioned their assumptions. They're just as random and noisy as any other kind of interview, but far more arrogant. Spolsky was right that you should do a FizzBuzz test, but that's it. That's all you need. Everything else should be about communication, personality and the other intangibles that matter far more for every job that involves working with other people (which is all of them).
FizzBuzz + short work sample + strong communication skills is probably not that far from optimal if you want to hire lots of people who are competent and work on problems that they have solved before. Note that I said "optimal" and not "good"; this is still a noisy process.
But if you're doing something where you need to people to excel beyond what they've done before, and perhaps beyond what your company has ever done before, then I think it's naive to think that additional testing for things like on-the-spot thinking, creativity, and diligence under pressure convey no useful signal. This, in my opinion, is an extraordinary claim and requires strong evidence before anyone should take it seriously.
[0] https://www.joelonsoftware.com/2005/07/25/hitting-the-high-n...
The extraordinary claim is that whiteboard testing (or take-home projects, or...well, anything in the current tech interview) does any of those things.
You can't whiteboard-test for excellence. Excellence is both contextual (i.e. it depends a lot on your company, team, culture, etc.), and based mostly on squishy, intangible factors that go beyond "code": picture the brilliant coder who dons his headphones, falls down a hole, and produces a pile of undocumented, complex code of zero business value. It's a cliche, but do we interview for it? No. We ask people to do a graph search on a matrix.
My contention is that we'd do far better with some simple, basic screens for technical competency, and then spending most of our time on communication skills, personality, clarity, organization, planning, business sense and team fit.
...but of course, these are questions with no single correct answer, so engineers are afraid of them.
This is just a naked assertion. This kind of testing happens in many places and industries, and many people seem to believe it's useful. Maybe they're all deluded, but that's precisely why I'm calling it an extraordinary claim.
Do you really think it is obvious, prima facie, that asking people to demonstrate some skills on their feet, or to do a short sample of work for you, tells you nothing about their ability to do good work? If so then I suppose we'll have to agree to disagree.
Edit: I'll add that I personally "interviewed for excellence" as a professor for many years. There was, as far as I could tell, no doubt among professors that interviewing was a non-trivially useful part of evaluating a candidate for graduate school. Again, maybe we were all deluded. But that's a claim that demands some proof.
Provide evidence that coding interviews does what you want it to do. Saying that "other people do it, and therefore it must work" is cargo-cult analysis.
I'm trying not to be a jerk here, but I already know the answer: there's no evidence. People do this stuff for exactly the same reason you're biased toward doing it -- because someone else with a big name did it, and nobody goes wrong by doing what Google does!
"Do you really think it is obvious, prima facie, that asking people to demonstrate some skills on their feet, or to do a short sample of work for you, tells you nothing about their ability to do good work?"
I think it tells you something about that person's ability to do the skill you've tested. Sort of. Under extreme pressure.
Does asking people to code on a whiteboard tell you how they're going to work with their peers, communicate clearly and efficiently, document their code, focus on business goals, and generally not be an asshole (all of which are far more important skills for success in a group)? No.
Even as far as coding ability goes, I've many, many "brilliant programmers" who eat leetcode problems for breakfast but can't be trusted to write clean code on their own. It's a borderline useless signal.
I'm saying "lots of people do it, I can give theoretical arguments for why it might be useful, and it seems common across industries, and this is the only industry I've seen that has a meme about it being totally useless ... so I'd like to see some evidence that it's useless". You're saying "prove that it's useful". We disagree on which direction bears the burden of proof.
Edit: to provide something a bit more explicit, the kind of thing that I would consider persuasive here (again just my opinion) would be several companies that have succeeded like Google, Amazon, Facebook, Microsoft but have employed hiring practices based just on FizzBuzz and communication skill evaluation.
Can I just point out how absurd this argument is? Even putting aside the issue of Salieri’s talent (which he had in abundance), the fact is that most of the Requiem wasn’t even written by Mozart, except for scattered bits here and there. And as far as the movement that everyone knows is concerned — “Lacrimosa” — Mozart only penned the first eight bars!
So yes, even people with a fraction of Mozart’s talent have and will continue to create things that are just as good as his own work. (Heck, maybe even better!) The rest is inspiration and marketing.
Having said that, I appreciate you pointing out these facts about Salieri and Mozart. Thank you for educating me a bit today!
This definitely ups the pressure, and things like hardware/internet failures would muddy the waters.
It sounds like even a commitment guaranteeing opportunity for discussion & feedback would be enough to satisfy several commenters here, but that is rare for liability reasons when employees are turned down.