In my experience, it is. I've done technical screens with _failed_ fizzbuzz-grade problems to people whose CV said that they have been coding for years, and those people were looking for (Senior) developer roles (not management, 'architect', just plain developer).
The first time I was given this problem on an interview it took me two attempts to get it right. That is, I wrote the code, ran it and it failed to do multiples of 15 properly
I’ve spoken to people who get about as far as writing a loop and printing the number but just have no idea how to go any further with the fizz and buzz logic at all, even with lots of hinting.
I think it’s because many developers just call one API and send the result to another API - they never have to write any actual logic themselves, so they don’t know how.
One example: Declared themselves to be an experienced Pythonista of N+ years. Couldn't write a `for i in range(100)` loop in Python without hints. They probably could've done it in a different language, but I didn't want to have anything to someone who misrepresents experience in their CV. It's fine to say you don't know it and instead show me that you can learn it.
OMG can I come work for you?
Been coding for my entire life, just don't have the resume text to back up the fact that I can learn just about any language/tool/framework/gizmo that I come across, so trying to get hired to any particular place, who all require "proven track record, 1+ years in X,Y,Z,ZZ and ZZZ", is almost impossible.
I'd love to see more openings saying "we use these tools, but we're open to work with anyone who can show they can learn them and be a solid team member".
One of the customers I work with is currently looking for backendy/devopsy people who want to work with Go/Python/Kubernetes/Bazel and make things better. There also exists also some frontend stuff that needs work. Basically, we're looking for generalists. Get in touch if this sounds like your sort of jazz :).
That's interesting. It hadn't occurred to me that some of the failures might be down to people trying to code in a language they are not familiar with.
This was over a phone/internet call (first technical screen after a non-technical recruitment call). Or are you saying our non-technical recruiter should be asking potential candidates to write a fizzbuzz?
I am interviewing candidates in the Fortune 10. We get a lot of fraudsters that have found a way to lip sync Webex interviews and do all manner of silly things to get marginal people hired into roles they aren't suitable for. After 25+ interviews, and hundreds over the last nearly 20 years of my career, I can tell you in just a few minutes whether I want to work with that developer or not. I don't have to ask them to code, I just have to ask them things about our day to day work that only real developers know, for example:
If you're writing Spring Boot applications, tell me about which jars you include in your build to do that. Oh you only use Spring initializr? Okay, well, then tell me about which jars you added to your project after that initial setup. You say you use Kafka in your current role, tell me what jars allow you to set up Spring Boot Data for that. Oh, you don't use that approach? Interesting. We looked at doing that, too. And then, hopefully, you get to understand what they are doing and what they know.
Interviewing for Angular: What is your least favorite thing about working with Angular? What packages are you using in your application? Have you had trouble with your CI builds in Jenkins (or whatever they say they use?) I listen to them and I ask questions that ought to be relevant to them.
I typically start "hard" and then if I don't get anywhere, I ease back. You stated that you write REST services? Tell me, what Java library do you use for making a REST call from inside your application? Oh, okay, another team did that, I see...
And so on. It becomes very obvious whether the person is bullshitting you. I recently interviewed someone for a tech lead role who says he had been a tech lead at another company but I was astounded by not only how bad his answers were but also by how little he appeared to know about the business of coding. Either the guy was lying to use completely or he was in a real creampuff kind of lead role where you don't need to know anything about coding, anything about the architecture of the system you are responsible for, or anything useful at all, really. How do I get that job?
>tell me about which jars you include in your build to do that
If you're doing this frequently enough, you probably have a template of which "jars" (dependencies) you generally use, so you probably don't remember.
If you're doing this infrequently, you probably googled what you need to include for what you want to achieve and forgot about it.
So you're filtering out efficient (templated a standard process) and competent (figure stuff out on the fly without guidance) people, and filtering in people who... remember the name of the dependencies they're using to implement things?
> If you're doing this frequently enough, you probably have a template of which "jars" (dependencies) you generally use, so you probably don't remember.
You're being ridiculous. Being able to converse with other developers is part of being able to do the job. A very common topic of conversation is "what libraries are you using on your project? Why are you using X instead of Y?"
I expect every engineer I work with to be able to talk about the tradeoffs of using (or not using) any library in any project they've ever worked on. Knowing what's in your application is important with regards to size, speed, understandability, modifiability, etc. I consider this information far more important than if you can reverse a binary tree.
> So you're filtering out efficient (templated a standard process) and competent (figure stuff out on the fly without guidance) people, and filtering in people who... remember the name of the dependencies they're using to implement things?
People who remember the dependencies they're using to implement things and can explain why they are using them are both efficient and competent. Most likely, anyway. It's not the only signal I use when hiring, but it's an important one.
