Everyone should use FizzBuzz and teams should come up with similar challenges that are novel enough not to be memorized.
The reason why FizzBuzz exists is because a lot of people apply for programming jobs who can't write code. It's not just that they don't know framework X or have an outdated approach to problems. They literally cannot produce anything remotely recognizable as working code.
> The reason why FizzBuzz exists is because a lot of people apply for programming jobs who can't write code.
I question how soon this actually is. I was assured that once I got involved with interviewing I would be hitting these people regularly. After a couple dozen interviews, I have only encountered one person who was that bad. They vast majority pass the "write a simple, working program" test then fail miserably on the problem solving parts. What are you hiring for, and where, such that you (and others) get so many of these people?
It will probably depend on your hiring pipeline. In an established pipeline an engineer interviewing someone who can't code FizzBuzz is kind of a disaster. The recruiter asks their questions for the purposes of filtering out these types of people.
However, if you're in an early stage startup just getting started hiring you'll probably see a lot of these people. It will also depend on what type of engineer you're hiring. Most people with a couple years of software engineering experience under their belt can probably code FizzBuzz. If you're interviewing recent graduates it's a different story.
> It will probably depend on your hiring pipeline. In an established pipeline an engineer interviewing someone who can't code FizzBuzz is kind of a disaster. The recruiter asks their questions for the purposes of filtering out these types of people.
Our pipeline is run by the individual teams. All our recruiting team does is coarse filter the resumes for obvious rejects and collect basic information. All screening is done by actual members of the team.
I don't think it is a particularly burdensome, though it does get tedious if a req sits open for a while.
> It will also depend on what type of engineer you're hiring. Most people with a couple years of software engineering experience under their belt can probably code FizzBuzz. If you're interviewing recent graduates it's a different story.
I have only been involved in experienced hires, but the claims I read indicate the problem is just as widespread in the experienced people. That I cannot corroborate with personal experience. I can buy the new grad claim, though. It is disturbingly easy it get through a BSCS without being able to write a functioning program in some language.
If your goal in the interview is to humiliate those who don't work well under pressure, or to insult the intelligence of those that can pass it in their sleep, by all means, go nuts.
I'd walk out of an interview if they went FizzBuzz on me. If you're asking questions as stupid as that you obviously haven't looked at my open-source code or talked to any of my references.
You need to screen for what you want in a candidate in a manner that's appropriate for the type of candidate you're dealing with. Throwing your front-end dev a FizzBuzz is garbage. Asking them questions about their use of CSS in the past, the challenges they've faced, and what they're hoping to see in future versions of CSS can inform a lot more than any "coding test".
One thing I find is the most illuminating is asking someone what they like the least about their favorite language or platform. The thing that's causing them the most pain seems to precisely illuminate the stage of learning they're at.
For example, someone who claims to be a long-time iOS developer but who hates the message passing notation in Objective-C is probably more inexperienced than they're letting on. Someone who says they have "some" experience in JavaScript but is upset about some esoteric aspect of streams might be wildly understating their understanding of the language and environment.
Unless your company's workflow consists of writing code on whiteboards and deploying the whiteboards to production, interview code questions give a lot of bad data.
I'm mainly talking about junior developer interviews here. Although IMHO, administering FizzBuzz to senior applicants isn't a bad idea, either. You'd be surprised just how far a person can get into computer science without being able to code.
It's a terrible idea. Focus on questions which give you meaningful data. For juniors work on ascertaining their motivations and how they think. For seniors dig into their experience and what they're looking for in a role.
Unless solving FizzBuzz on a whiteboard is what your company does on a daily basis it gives you nothing but junk data.
Sometimes people need a moment or two to shift into "coding mode", and others might not be comfortable doing it without a particular editor or reference handy. There's many ways to produce good results, not all of which are whiteboard friendly.
What would you suggest to people looking to become or retrain as a developer? Because it seems this is something that's more of an issue these days than even a few years ago...
The first thing to do is ask yourself if you really want to become a programmer. Do you like programming? Have you ever tried it before? How comfortable are you with computers? You might be the go-to guy/girl for your friends and family, but are you 40 hours a week comfortable? How much time are you willing to spend debugging a confusing error message before running for help? Do you get any internal gratification from writing a computer program that runs successfully? What's going to keep you going when nothing you try works and you've been bashing your head on the same problem for a week?
The reason is that there are tons of jobs within the software industry at all salary levels that do not require coding. QAs, IT recruiters, business analysts, DB admins, designers, product owners, system administrators, etc. All these people benefit directly from the software industry and many do not know a lick of coding.
I think part of it is this sort of national illusion that everyone can become a programmer. But programming is just not for everyone. Learning to program requires a high level of diligence and self-motivation. In other words, you have to enjoy it. Not everyone is going to be inspired by "public static void main(string[] args) {}." A lot of people take one programming class and know right away it's not for them, and that's totally fine.
It really depends on the bootcamp. The sort operating locally here are such a gauntlet that the students who survive them are usually quite good, if not highly motivated.
Meanwhile I've seen university graduates with actual computer science degrees from respectable schools who can't do anything useful. They've never had enough practical experience writing actual production code.
I suppose the demand for developers has led to some companies getting more relaxed with their interview's I know in the U.K some companies don't do any testing at all. :O
Well, I do. Just don't have enough time to also pursue my programming hobby in addition to a job, a family, and other hobbies. "Code on side projects daily" has become more of a goal to strive for than a reachable one.
Keep at it and evaluate every few weeks if you feel ready to throw yourself into the arena and take some interviews. You may never feel ready due to the sheer amount of languages and knowledge you think you'll be checked on, that means you need to narrow your focus and specialize in a popular stack that you personally enjoy working with to get your foot in the door.
It is absolutely reachable. A personal path for reference:
2012: Graduated college with a non-comp sci degree (although had tinkered with tech, software, linux, etc since a teen)
2012-2013: Took comp sci MOOCs.. Obsessively learned python and built throwaway projects. Took code challenges weekly.
2013-2015: Got a job as a manual test analyst. Used python to automate testing, got promoted to test lead.
2015-2017: Took a job as Lead QA Engineer. Learned C# for the job. On the side picked up React and Django/DRF for building out SPA/microservices. Began getting serious about clean projects on github and kind of branding myself as a developer (personal landing page, etc). I couldn't keep recruiters off me from my linkedin, stackoverflow and github profiles. Was like ok.. I'm ready... it's time.
2017 (mid): Studied the hell out of algorithms and data structures. Did tons of whiteboarding practice and began taking interviews. Signed up for some tech recruiting apps like hired and opened the recruiter floodgate. I had 2-3 phone interviews a day for 3 weeks. Then a few in persons per week. Not one whiteboard session. Some would send code challenges. The rest asked if I could send them a github project that we'd review during the interview.
2017 (mid)-Present: Now a Software Engineer at an established startup working with brilliant peers and some of my favorite stack.. A massive kubernetes cluster built on Python, Go, React, and ElasticSearch services.
So from 2012-2017 there were many points where I doubted I'd land that dream... and then boom! As soon as I got the balls to throw myself into some interviews for the position I wanted I found it and now I no longer feel like I have to grind away every evening to stay sharp since my job is doing that for me now.
Agreed and here's a word to the wise. For whatever reason, tools for other coders always make for the most impressive side projects, even if no one ever uses them.
The reason why FizzBuzz exists is because a lot of people apply for programming jobs who can't write code. It's not just that they don't know framework X or have an outdated approach to problems. They literally cannot produce anything remotely recognizable as working code.