This is in response to an excellent post by @vorahsa about how the industry treats people, and how he has even heard his coworkers referencing thes...
For further actions, you may consider blocking this person and/or reporting abuse
"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""
Bingo!
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.
Awesome article especially the part in companies limiting their pool of engineers by trying to follow Google in the most extreme way.
Thanks! I think it's critically important for companies to honestly understand where they are in their lifecycle and make decisions based on what's best for that company, at that time.
None of us can predict the future, so trying to build a 5 person team to operate (and hire) like Google is going to make the road a LOT harder than it needs to be!
A great post and good continuation to mine! I'm sure you're not surprised that I pretty much agree with everything you wrote.
Thanks so much! I think it's an important conversation to have, and one that can help move the industry forward. Thank you for kicking it off, because we need to keep the focus on improving our industry and move the standards a little bit at a time!
I see what you're saying, but rocket engine plumbing is actually a thing.
I'm actually excited about this comment because it gives me a chance to talk about one of the funniest conversations I've had about this article.
One of my friends is a mid-career changer from hardware to software engineer.
We joke about the fact that, before he switched, he used to work on lightsabers (plasma... Specifically plasma torches IIRC)
He called this out as well:
I responded with one of my favorite nerd jokes I've ever made that only works in this context:
Replace lightsaber plumbing with rocket science and it still works haha