Hacker News new | ask | show | jobs
by TacticalCoder 931 days ago
> 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.

1 comments

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.