For this shit alone they should be burned to the ground. Why do recruiters do these silly "homeworks"? Every time I hear this during a recruitment I'm like "ooooh, so you just do a mass-casting, and see who's the most desperate?". Nope, nope, nope...
Asking candidates to do tests on their own time is rude and dumb.
Any "homework" longer than an hour or so is disproportionally a burden on the candidate. I feel it is unethical and a dealbreaker for me.
Candidate just devoted significant portion of an entire day with no compensation in hopes to work for you, you basically say 'no' and give nothing back.. its using peoples labor for free and trashing them.
Interviewing candidates also isn't a free labor source (in event that 'homework' has some professional use, which it often could)
Other than obviously or blatantly incompetent coding, I'd expect that as a minimum, a code review would be a part of the equation.
This is similar to you working on a project, your boss looking over it, not saying a word, dragging it to the Recycle Bin, and walking off.
I once spent two hours on a test for a contract development company. I'm an accomplished senior developer and normally i would have told them to F off, but I was curious so i did it. I did pretty well on it, but never got a response. Zip, nada, nothing. I emailed them multiple times and even called HR. Still no response.
Anytime other devs ask me about that company, i say don't waste your time, they are super shitty.
I don't want somebody who 'knows' how to invert a tree, any more than I want someone who's learned the answer to Fizzbuzz.
The point is not that you know how to do it, but that you can naturally perform basic manipulation of very simple data structures. If you can't swap two values, or you can't write recursive code, you may think you're a competent programmer, but I don't agree. What is basic, if that kind of thing is advanced?
If you think an employer expecting that level of competence has 'a sort of attitude', then I don't know what to say. How would you react to someone who felt that way when asked if they could code a loop over a pair of lists, or return a function from a function, or any thing else you consider routine (do you consider anything routine)?
It worries me that programming has become 'copying and pasting from Google' and that people would find it offensive that anyone could possibly have a higher standard than that. If that's a horribly elitist, unacceptably arrogant attitude to you, then again, I don't know what to say.
I just think people starting out should be supported and being arrogant about it doesn't really help anyone.
So, do you feel like answering the questions in my edited and toned down version?
I confess I am really struggling with this at the moment, because this kind of thing seems to keep coming up. And I honestly cannot figure out where I'm going wrong to expect programmers to be able to do this kind of thing.
Adjust your expectations.
Methinks you left the last and obvious/inevitable step out.
I suppose the main objection to that would be "but we'd end up paying out so much money to people we don't hire!", but that feels to me like it says more about that company's recruiting process. Just wait until you're serious about potentially hiring somebody before you bust out the homework assignments and you're fine.
I think homework assignments can work great, but compensation for the time seems totally logical, and it should somewhat be in the area of reasonable too, not just a 'spend 20 hours but get 200 bucks' either.
I think it's one of the most close-to-actual-work things you can do (especially if they give you a problem at least close to what you're going to be working on everyday).
Designed well, I could imagine a test that would take 1 to 2 hours (of course you can't control how long someone will work on something, but if I ask you to reverse a string in python I don't think it's reasonable for that to take hours), and succinctly test for clean architecture and good general software engineering principles.
Last time I got a stupid exercise about counting amount of 4s and 0s in a number, while obeying to a specific pattern, then generate numbers that according to that pattern would match a specific formula, while taking into consideration some GCD relations among those numbers.
Yeah, cool exercise for a weekend. Zero value when writing enterprise distributed systems with web/native GUIs.
It's hard to get one at 4 hours, but that provides just enough to really see something while still being respectful of candidates' time.
Of course, this is entirely dependant on the type of programming that you're hiring for!
Needless to say those candidates didn't got hired.
If we as an industry don't trust/value the stated experience of others, why do we continue to ask for it? Maybe tech companies should just stop accepting resumes then?
FizzBuzz is an interview question you just expect.
RosettaCode has every FizzBuzz solution out there. Tons of people know how to FizzBuzz.
This is just "learning enough to pass the test" - a canned answer like the one you know you have for "How do you deal with multiple simultaneous high priority projects?" or "What's your biggest weakness?"
You may be filtering out lazy lazy candidates with FizzBuzz. But just because they can do it doesn't mean they can ship code.
I don't care what your biggest weakness is. You could have severe OCD or addiction. You could battle depression. You could be a chronic procrastinator. None of those matter. What does matter is if you give a solid straight honest answer, rather than some canned crap you read on a web site somewhere.
Same goes for how you manage multiple high-priority things. Every job I've worked on, every team, it always happens that there are multiple high priority things. Do you try to do them all and then crash and burn? Do you do them half-assed? Do you fight to get priorities aligned? Do you call the sponsors together and share information about the deadlines? Do you under promise and over-deliver? Do you ask for help from your team?
The way you answer is often more important than what you answer. Unless it's "Fuck off."
:)
If you don't know how to reverse a string, or split an array of ints into two with even and odd ints, or write a while loop that terminates on a specific word - I have zero belief that you can fill the position I have available.
I have no problem with short sanity checking exercises during interviews. The problem is when they expect a lot more unrealistic whiteboard code.
a) I won't believe you got your PHD legitimately, do fizzbuzz for me.
b) You're faking both your diploma and your 4 year experience at Megacorp, prove me wrong via fizzbuzz.
c) Alright your credentials check out, do this entirely unrelated to the job assignment to prove that you have what it takes to do the job.
d) Alright you aced your assignment which despite being entirely unrelated to the actual job, domain and language, convinces us you got what it takes. Now, tell me an example of when you resolved a conflict with a colleague and how you did it...
You think that they wrote those scenarios with their own voice, so you are misreading the point.
Had they articulated "A hiring might think" at the beginning or even anywhere in their post then yes it would have been clear.
Regardless you don't want to work for anyone - fellow team mate, hiring manager or company that harbors that level of suspicion towards candidates. It's a red flag. I did not miss the point.
Really though? You're going to be like that? You're going to be the guy that tells the person making the point they didn't mean what they meant, after failing at reading comprehension?
The post I responded to said:
"Why even ask for resumes if you're going to ignore them? I also get very annoyed when people ask about your experience, then in the very next breath pretend none of it matters and you should do fizzbuzz."
Which I called bullshit. Then I listed a bunch of things that are also bullshit of the same kind but they get incrementally more bullshitty, among them was this:
"Alright you aced your assignment which despite being entirely unrelated to the actual job, domain and language, convinces us you got what it takes."
Which somehow you took literally.
Because somehow, you believed, someone would actually not only do that, but they would actually think that. They would actually knowingly hand a candidate an assignment they know is entirely unrelated to the job opening, and they would go online and detail their though process on this.
Was this a one time incident or do you go responding to every piece of irony on the internet pointing out that the writer must have meant what they said.
You seem to have greatly over-estimated your articulation and communication. But rather than entertaining the possibility that your intent might not have been universally understood, you are going resort to condescension and ad hominem remarks. Not very mature or constructive.
Then I sat on the other side of the interview table too many times. If my company is going to pay you or (more importantly) if I'm going to trust the success of my project to you, I really do want to know you can do the job. If that offends you, I'm sorry.
We relied too much on the resume and mostly talked during the one hour interview. After hiring the person turned out that our new employee would have had serious issues with FizzBuzz. Maybe even looping through arrays...
When we interview people know we test for basics, regardless of their resume.
Again, it's flawed, but trying to find and attract talent at a small company who maybe can't pay top dollar makes people take risks like this.
At least that's my experience!
If you talk about past projects, they talk about architecture and project management. If you ask about code they have written, they say it's all proprietary.
Ask about some peculiarities of their favorite languages.
Have them describe a recent difficult bug (very insightful - in their description's wording, the scope of the bug itself, steps taken to solve, etc. - but could be 'proprietary').
You can't just hire someone because they say they know something, you'd end up spending a fortune on employee turnover when everyone you've hired turns out to have exaggerated their resume.
1) Who cares if they've exaggerated their resume? The question is supposed to be whether they can contribute well to your code base/business right? I see this as a point towards getting rid of resumes -- maybe companies can stop bullshitting on what they "require" from candidates, and test more literally for what they want.
Don't take my resume, but if it's a backend position where the focus is erlang and postgres, test as specifically as you can for that, with fizzbuzz-like business requirements mixed in, for the best of both worlds.
2) I often wonder if there's anyway to lessen the costs of employee turnover. Obviously there's less you can do about time spent interviewing, but there's gotta be some cheaper way to figure out if someone is going to be a good employee while on the job? I mean that's the best test you could possibly have. Is it just the legal/logistical framework that's missing?
Also, I often wonder if running a company where it's hard for newcomers to ramp up and easy for newcomers to break things is a failing of the CTO and executives/managers all the way down to the newcomer (of course the newcomer is to blame as well if it's flagrant but I also think top-of-the-line tech orgs have (mostly) bulletproof process that evolved with them and got them to where they are (i.e. newcomer can't break your build if commits to shared branches/environments are gated by automated testing to begin with).
CV doesn't matter.
Fizzbuzz is cool. I am quite confident I can do it.
Surely if they were serious about me, they'd pay me to do a stupid task, right? Or am I way off base?
Experienced dev? Someone pay the man.
Sorry, we've all gotta pay our dues.
If they offer you a homework assignment that you think is going to take some time, and they give you a week to do it, and you can do it on your own time, just do it. Stay positive and upbeat. But learn from the homework. is it trivial? Or is it related to the work you'll be doing?
If, however, they make you come to their office or be available for specific times, and they don't offer to compensate you for skipping your other job or obligations, take that as a sign that they aren't considerate. You could put that as a negative in the "core values" bucket.
But yea - don't demand anything during an interview. You may certainly ask politely, but don't demand. It's a two-way street. Even when you negotiate your salary, don't demand. Be firm, but be nice.
This is only true if they give you a coding assignment after you have interviewed and you actually want the job. Under no circumstances should you waste your time with companies that are just so swamped that you have to jump through hoops so they'll deign to talk to you. Interviews are a two-way street and even an interview for a job I eventually pass on is a two-way street--coding tests aren't, not materially. You learn a little about the company but basically nothing about the people or about the current state of the market (both of the reasons why you should be interviewing even if you're happy with your job--to network with others and to keep your finger on the pulse of the industry).
You probably shouldn't do it if it'll take you more than an hour or so, either, as it communicates how much they respect your time. You can tell if someone can write code in short order. And you would be well-advised not to waste the time of people with ample open-source code you can check out instead. (Shouts, company-that-looked-at-a-completed-CloudFormation-management-stack-and-then-asked-me-to-write-two-for-loops.)
What's actually important is whether you can work with the person, which coding tests don't tell you (and, just as importantly, they don't tell me if I can work with you).
If you have ample open source code, lots of experience that's relevant to what I'm doing, then gosh yes - nobody should be giving you homework to do.
To your point about only doing homework after you interview, look at it this way:
If you're unproven, then you're getting the homework because I don't trust resumes. I've seen college profs and career counselors tell people "If you've dabbled in it, put it on your resume." Combine that with people who don't have any code online because "I have a life outside of work" or "all my work is NDA", and I'm sorry - I need to see if you can do the job.
Look, I know it sucks to do homework as a candidate before you interview. You're taking 5 hours to do it. And I know it feels like a disrespect for your time.
But there are devs on the other side who are part of the interview process too. And for each candidate most companies interview, there's about 2 hours for every hour interview per person. Cos there's usually some kind of prebrief, the interview prep, the interview itself, then filling out scorecards and the debrief. That's a time investment too.
And if I'm interviewing tons of people, and then give them the homework, and it turns out they're great people but can't do the job we need them to do, then we wasted their time, got their hopes up, and wasted a lot of our time. Hiring people for a team is extra work. If I spent 3 hours in interviews today, guess what? I still have to get my work done too.
The argument against homework from the candidate always comes down to "Why should I have to prove I can do what I say I can do?"
Because that's what interviews are. And if you can demonstrate you can do what you say you can do, you'll make six figures sitting behind a computer screen in air conditioning.
Sounds like a sweet deal to me.
So last time I needed a job, I interviewed at something like 38 places. All had my Github, smack dab at the top of the resume. Exactly two (2) out of a total of like 10 responses that passed through the first phone screen and wanted a coding test said "you have a Github so we don't need you to do the coding test."
So...I agree with you, but they totally do ask anyway. ;)
...
> That's a time investment too.
Those devs are getting paid for it, though. If you want to pay for my time, then that obviously changes things.
(If you are picking up that I do not care that the company spends money, you would be correct. People matter, not LLCs or corporations. ;)
> The argument against homework from the candidate always comes down to "Why should I have to prove I can do what I say I can do?"
I disagree. The argument I generally hear (and I'm more sympathetic to your position if somebody is a non-person on the internet) is "you aren't paying me for work you are asking for." Which is the framing that, IMO, makes much more sense. Neither of us should be working for free and we should be pushing back against upper management if they want you to be complicit in trying to make me work for free (or vice versa).
> Hiring people for a team is extra work. If I spent 3 hours in interviews today, guess what? I still have to get my work done too.
I 100% empathize, but this speaks to a failure of management. If an interview isn't being counted as filling space/reducing story points for that sprint/whatever-Agile-Agile-Agile, then management dun goofed.
That aside, There are tons of people out there who simply do not have the extra time to do open source work. Families, other obligations, health issues, you name it. It's pretty great to be able to do self-promotion via open source code, I certainly hate the idea of saying "no Github? Sorry, no interview". But I also can't just take people at their word because people either embellish or outright lie during interviews and resumes.
I've had a ton of people who said they could do soemthing during an interview, but didn't actually demonstrate that on the homework. Way more than you'd think. Especially with less-experienced folks.
They had a post looking for a full-time contractor, I contacted them and they gave me 4 hours of paid work. That was good, so they gave me 8 hours next. That was good, so they gave me a week's worth of work next. That was good so they gave me a month's worth of work.
By the time my half day + day + week + month was up, they had a nice contract ready for me to sign and we've been happy ever since!
I really like the way they onboarded me - there was small, but increasing risk shared equally between them and me as we started our relationship and learned to trust each other. It's been great, and if I was going to hire somebody on I'd do the same!
Then we sat down in his office and he handed me a programming quiz. While young, I was an accomplished dev with my name on a multiple published products. The first question was unclear, it didn't specify if I was to optimize for speed or memory or maintenance cost. So I got up, walked out, handed him the unstarted exam and left to take a job at Apple. Where I was highly rated in every performance review and extolled for my ability to work well with others.
People who don't want to take coding exams fall into two rough categories.
1) They are fakers, their resume claims are BS and they are afraid of being unmasked.
2) They are very good developers, and don't like tests. Maybe because of test anxiety, maybe they find them insulting given their career accomplishments, or mostly because they know they have little to no bearing on how good a developer they are. The reasons I refused the test that day was a combination of all three.
One example, even today I can't whiteboard anything to do with binary trees, because in 30 years of professional development I've never had to do anything with them, and can no longer remember any of the binary tree algorithms from my comp-sci classes.
My recommendation to you (as someone who has hired over 40 devs in my career) is to do paired programming tests with candidates. You can get a much clearer idea of their thought process and abilities, and it's a far friendlier and respectful process.
Too many managers measure the process cost only in their own time. They think, oh, I'll give 10 candidates a test to filter out the worst ones and then I only have to spend my time interviewing the top two or three. First you are ignoring how easy it is to cheat those tests and how little they apply to actual dev work, which means your top two or two are not likely to be your best two out of the ten. But you are also ignoring the possibility that four others refused to test and two of them were likely as good or better than anyone in your test group.
I will never take a coding test again. When someone requests one, they tend to be a crap company with poor software dev practices and a huge noisy open floor plan.
As someone who, without really bullshitting, is in box #2 of what you describe--this is a great recommendation. Coding tests are largely a joke. I test fine, but I have somewhere north of a hundred thousand lines of open-sourced code out there. I can write code. You're not helping me learn anything as I help you learn whether you want to hire me with your (probably bad) coding test.
But we both benefit from pair programming. Because it's fun, it's usually more thought-provoking, and it teaches me about a company and a person I might run into again in the future.
> When someone requests one, they tend to be a crap company with poor software dev practices and a huge noisy open floor plan.
...also this. Coding tests are the warehoused, wholesale way to hire developers. You probably deserve to at least be handled retail.
In those cases, if you don't agree with those weekend projects, you will most likely just not get a job because someone else will do it. If you ask for compensation for your time you will most likely hear a mad laugh and a "Nope"
The feedback from candidates (including those we didn't hire) has been extremely good - they much prefer this to puzzles or whiteboard coding sessions.
Note that we give such challenges to candidates after they passed through a phone screen and a first interview with a pair of engineers.
This whole idea of asking people do use up their nights and weekends to do free work is completely ridiculous. And the justification is always the same - "we think its better than implementing algorithms on whiteboards."
Well who ever said writing code on a whiteboard was necessary? This justification is ridiculous as it suggests there are just two possibilities for hiring people - algorithmic puzzles and unpaid work.
At my last place we used one, said "please don't spend more than 5 hours on it" - it was a challenge to read a specific industry format (e.g. test you can go and find something to read it, not implement a library to do so ... not reinventing the wheel) and present it in a basic RESTful web app (testing that you know what REST is, and can implement basic CRUD).
Never had an issue getting it done, and it was very illuminating, some people who passed through the initial interview with flying colours turned in absolute crap.
Stated another we don't want you to give up more than an "entire evening" or your "entire Saturday afternoon." This is messed up.
What's even more messed is that you generally won't be given the opportunity to you discuss your thinking or choices on your project. It's just pass fail.
Did you go over your reviews with the candidates that put in 5 hours who failed? And while a company says things like "don't put in more than X hours", the reality is people will put in much more time than that because they know they being put under a microscope and judged as if its production code.
It's either that, whiteboard interviews, or restrictive probation period if we don't test their coding ... each have their downsides, and it was decided the coding project was the most fair.
If you already interviewed them twice, why in gods name do you need an easy to cheat programming challenge? Why not do paired programming instead?
It's not the recruiters, they are just the messenger. But yeah this is a joke.
I've been in a couple of "hiring manager" roles and many times the challenge completely exposed under par developers with otherwise interesting cv's. Sloppy code, beginner mistakes etc. It's maybe a sign of the times where hiring managers need to actively test whether someone is propping up their CV with stuff or is actually knowledgeable. I wish it were different, but alas it is not.