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.