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.
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?
The failure rate on fizzbuzz is spectacular. That's why; far too many resume/CVs are full of nonsense. It's not always the candidate's fault, either. When doing technical interviews for contractors, I've gotten into the habit of giving the candidates the version of their CV passed to me by their agencies to check; a good percentage of candidates horrified to see what had been claimed by the employment agency on their behalf.
There's various levels of bullshit, of incremental bullshitness
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...
We had a surprise at my company. The candidate had a masters degree and 2 years experience in a known software company.
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.
I'd consider the interviewer as much of a problem as the hire in this case. Talking to someone for an hour and not being able to figure out if they could write basic code? Hiring someone based on their background and not doing a background check (after getting their approval ofcourse)?
How do you find out if they can write basic code without asking them to write some code?
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 them to think up a way to implement a function to do X. Keep X simple, simplify further until you find common ground. Any other ways to implement? Tradeoffs? What about under this or that constraint?
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').
At smaller companies who have trouble attracting better talent, avoiding technical questions is a (flawed) way of showing deference to the prime candidate. It's a way for the company to say, you are special to us and we respect you so much you don't have to do tricks for us.
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.
Your attitude seems to be that of a bad cop - "you are guilty until proven innocent." If I were interviewing with someone that expressed the level of suspicion that you have here, I would cut the the interview short. Interviewing is a two way straight and I can't imagine working with someone with that level of skepticism. Obtaining a PHD illegitimately? Honestly you sound very jaded.
I used to believe that. I even passed up on a job that I should have taken because of it.
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.
Spoiler: Their four scenarios are written from the pov of a hypothetical hiring manager that offends the applicant with bullshit (the "bullshit" they refer to at the start of their post) no matter the context.
You think that they wrote those scenarios with their own voice, so you are misreading the point.
Nowhere in the OP's original comment is it clear that this is third person point of view from a "hypothetical hiring manager."
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.
>"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.
Agreed, I have come to believe strongly in the value of Fizz Buzz and other simple tests. Many candidates have strong resumes but large companies destroy their souls and skills by sticking them for 8+ hours a day in rubbish meetings. Go without coding for a few months of this and your ability to Fizz Buzz will be compromised. Most smaller companies are looking for active, hands-on developers and Fizz Buzz is a quick check to ensure that the candidate spends a substantial part of the day writing code and designing software.
Yes. Always have an easy problem in analysis & coding, like constructing a simple Boolean predicate from some comparisons. You will thank yourself later when you don't hire the fantastic-looking candidate who had absolutely no idea how to work the problem.
Resumes get you the interview. Interviews get you the job.
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).
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.
What is the answer to those questions? I can Fizzbuzz in any number of languages, but the first response that springs to mind for the others is "Fuck off."
Really? As a potential member of my team, I really do want those questions answered because how you answer them tells me about your character, personality, and thought process.
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."
I usually cook my own questions that involve a loop and an if statement. I kid you not, plenty of candidates cannot do simple stuff, and they're interviewing for a developer position.
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'll gladly tell them how the modular arithmetic works, I just want them to fill out the rest. Many are unable to, which tells me that they don't know even the simplest constructs in programming.
It is more fair to do fizzbuzz. Seeing someone being taken over you because he is good at bullshitting is super infuriating. Might be fine if the position was "sales", not fine for engineers.
Fizzbuzz is cool. I am quite confident I can do it.
If you're a Ph D that's interviewing for a job that requires you to write HTML, or a company interviewing Ph D holders to write HTML, something is wrong.
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?