[rewmie]

> I've lived both sides of this. I’ve been subjected to the mysterious whims and casual insults of the job-seeking process.

I've grown to learn that it's important to understand that interviewing in particular and job-seeking in general is not an objective and impartial process, and the output is not deterministic or reproducible. You can be hired even when there are objectively better people in the race, and you can be sidelined right on the phone screening even though you are the ideal candidate. It's a crapshoot, and the only people claiming otherwise are motivated by a mix of survivorship bias with a need to avoid recognizing that the process is flawed by nature.

> I’ve also interviewed and rejected experienced candidates who talked a great game but couldn’t demonstrate the ability to code FizzBuzz-level problems in any language.

I'm afraid that this take is also a reflection of the cargo cult mentality that plagues recruiting. I personally know FANG engineers with half a dozen years of high-profile work who had to spend weeks training coding golf and algo&data structures trivia before passing the first round of interviews, all because these trivia games bear no resemblance with real world software engineering. In fact, I will go as far as to claim that they serve more as ladder-pulling than actual technical assessments. For example, once I was automatically rejected from a C++ position to work on a desktop app because I wasn't familiar with placement new. This also extends to framework tests. I know a guy who applied for a backend position who was rejected because even though he rolled out a Spring service from scratch that passed all integration tests, the interviewer complained about how the service did not commented the controllers. These are things that takes a single comment in a PR to address. I mean, is adding a comment w challenging technical feat? But somehow some interviewers reject candidates based on this nitpicking.

[john-radio]

> I personally know FANG engineers with half a dozen years of high-profile work who had to spend weeks training coding golf and algo&data structures trivia before passing the first round of interviews, all because these trivia games bear no resemblance with real world software engineering. In fact, I will go as far as to claim that they serve more as ladder-pulling than actual technical assessments...

FizzBuzz is a trivial technical problem, though, not a leetcode medium or even an easy. I agree with you that you shouldn't have to grind leetcode all day in order to be considered a valuable software developer; but the existence of people selling themselves as "engineers" but who can't solve fizzbuzz would go a long way towards explaining how we got into this leetcode situation in the first place, because such a person would not be able to be successful as a software developer and they need to be weeded out during the candidate search somehow because they are around and they do want the job.

[rewmie]

> FizzBuzz is a trivial technical problem (...)

No, it is not. The term fizzbuzz doesn't refer explicitly to the loop with the modulus example. Fizzbuzz is an umbrella term for tests that are used to assess proficiency, but in practice they tend to have weird gotchas that get you disqualified for random reasons.

Case in point, there are online coding challenge tests where you do fizzbuzz tests that flag you as disqualified for cheating if you move your focus away from the page. That's one way to fail fizzbuzz tests: you start the test, switch your browser window, boom you're tagged as an incompetent moron.

[ursakhiin]

Why wouldn't FizzBuzz refer explicitly to the challenge that shares its name?

[shermantanktop]

I said “FizzBuzz-level.” I’ve used actual FizzBuzz for new grads who I suspected couldn’t code, but normally I’m using questions that require looping, conditional logic, perhaps the use of a simple helper data structure like a map. I consider “reverse a string” to be advanced FizzBuzz. Anything requiring DFS or binary search is not FizzBuzz. “Print a tic tac toe board using asterisks, one character at a time” is FizzBuzz.

[TacticalCoder]

> I personally know FANG engineers with half a dozen years of high-profile work who had to spend weeks training coding golf and algo&data structures trivia before passing the first round of interviews

> all because these trivia games bear no resemblance with real world software engineering

You may actually agree with GP for he is not talking about that. GP is talking about FizzBuzz: less than ten lines of code and three if or something.

Someone who cannot solve that cannot code, as simple as that. I don't care about a little error but someone who doesn't know how if and else do work has no place in "real world software engineering".

I mean: how many developers working on critical systems like those in a commercial airplane don't know how a conditional statement work?

Anyone who has ever interviewed candidates knows there are master bullshitters out there.

As one CTO once told me before I'd be interviewing people: "When you look at their CVs full of buzzwords, you'll often feel like you know nothing. But for many of them, once you'll start asking trivial questions you'll quickly realize they're the ones who know absolutely nothing".

Asking to solve FizzBuzz is not asking to solve a problem which requires to know when to apply, say, Floyd-Warshall.

FizzBuzz is not a high bar to pass.

[shermantanktop]

I’m at a FAANG-type company and have interviewed over 1k engineers at all levels, but mostly senior+. The coding questions I ask aren’t literally FizzBuzz, but do involve counting, looping, conditionals, etc. Good solutions are possible in 30m and take 30 lines of code or less. And I’m not looking for beauty or perfect efficiency, I’m looking for code that works and which the candidate can explain.

Example: given the x/y coordinates of a rectangle, can you write a function that tells me which points in array are inside or outside?

Other companies may get a different pool of candidates, so such a low-pass filter may not be necessary. But these people have resumes which describe them as capable engineers. What I usually find is they are no longer coding much, but are doing design reviews, code reviews, and attending meetings.

[shantnutiwari]

>I know a guy who applied for a backend position who was rejected because even though he rolled out a Spring service from scratch that passed all integration tests, the interviewer complained about how the service did not commented the controllers

yeah, and though the job advert says "spend 1 hour on this", you find that 1 hour isn't enough. And yet, the interviewer will pick up faults "you didnt finish this"