re: The Hireable Unhireables: A Response VIEW POST


"Specifically with Github, my immediate response is "I was writing code with a wife, son, and a lawn to mow before Github existed, and none of my jobs have required me to commit in an open-source repo""


When I get this same question (I have yet to), I'll simply say that all projects worked on at companies are closed source. Which is the truth.

Alas, look at my portfolio instead!


I feel like a lot of this overemphasis on being able to see your previous work comes from a decade-old blog post from Jeff Atwood (blog.codinghorror.com/why-cant-pro...) which is also what popularized fizzbuzz IIRC. The fear you will get a programmer who can't program.

It's part of the anti-academia movement too.

But honestly tools like fizzbuzz or just a little bit of light whiteboarding (another thing we glorify a bit too much in interviews) takes care of that.

Styleguides change by company and can be taught. If a person has a long track record of implementation and no red flags, I don't see how useful it is to require that they build a long collection of code-samples, just to prove they can do their job... There's not another knowledge worker that has the same except maybe for the scientific fields and publishing... But I think that's a poor standard for a field that changes as rapidly as software engineering...


Today, being asked fizzbuzz in an interview would be a red flag.

I've seen people say that even a simple "problem" like that can tell you about the interviewee. Sorry, beg to differ with such folk. Even though interviewers who used it might well be competent developers themselves, it's an un-enlightening interview question.

The thing about fizzbuzz is not that it is too simple. It is that it is trivial. It is trivial even to a competent student midway through a CS course. The only thing you can attempt to find via fzzbuzz is aspects like how they name, or whether they write tests. But, fuzzbuzz is too trivial a test for these aspects either. So, you'll end up judging a candidate by trivial choices and trivial disagreements.

Instead, find a problem that is simple in the sense that it does not take too much time, but make it something a programmer has to think about for a few minutes. Make it something that has at least one follow-up question, perhaps with a twist. You can still judge things like naming (but, don't be pedantic).

But, mainly... watch if the person's eyes light up when they try to figure out your little problem, and see if they give it their best shot. That'll give you more than watching how good they are at stifling their yawns as they plod through fizzbuzz.

Honestly I'm being a bit loose with the definition of fizzbuzz, because yes the exact "fizz on threes, buzz on fives, fizzbuzz on both" has been ground into the dirt so much that it's useless due to exposure.

Originally it was to test if the candidate knew how to use the modulus operator, as knowing how mod works indicates an understanding of how a lot of things in programming work...

Now it just tests if you did the bare minimum refresher before the interview haha!

When I say fizzbuzz I'm really thinking of a small algorithmic problem for exactly the same use. I think I agree that the best indicator is if they shrink away and don't try or if they jump in feet first!

I'm never worried about naming or whitespace or whatever in an interview... Like I said, styleguides change from job to job, but that urge to learn and solve problems is what we all should be striving for!

Understood. My rant was confined to true fizzbuzz.

I'm fine with little coding problems. Ideally, the candidate can be asked to do something like that before they come in for an interview, or before they actually interview with a person.

There's an aspect that's useful during an interview too: to try to see how they think (without making it some super puzzler).

The key thing to look for is clarity of concepts and clarity of thought.

code of conduct - report abuse