A lot of people have the idea that “tech” (whatever that is) is the path to riches, and that they can just start out and learn as you go, just as you might for a manual labor job.

I don’t mean this in any way condescendingly or to imply these people are dumb. Often parents/partners are telling them “go get a job”. The process is discussed a lot on HN, Reddit etc, but most people don’t know that job searching is itself a skill in and of its own. They don’t teach that in HS or college.

I think you can learn as you go with tech. It depends on where you start. If you are a humble hobbyist with a few projects under his belt then a junior position isn’t too far out of reach.

As long as you pace yourself and are open to learn you can become a senior developer.

I had a friend at google who got so sick of people who couldn’t code his first question was “write anything in any language on the board”. About 50% of interviews ended there. I question if that was a reasonable way to start since it is a terrifying social question (what’s the hardest thing I can reasonably do that meets his unknown criteria). It is therefore probably a better test of professional confidence (though that’s really great to have too).

I went the opposite way. I got sick of adversarial interviews. (If you can do the job we’re on the same side. If you can’t you’ll be miserable here so we’re still on the same side). I started opening my interviews with “what did you have for breakfast?” To set the tone of at least everyone can answer the first question. The last guy I hired sheepishly said “I skipped breakfast” but I still counted it a pass.

It's better to actually give a dead simple question instead of leaving them guessing. When interviewing interns, we would start off with "print all the items in an array" - besides for instantly weeding out candidates who couldn't code at all, (and there were a surprising amount), it's also a great confidence booster for them before moving on to the real question.

I had an interviewer ask me "how do you copy a file in Unix". Which was a good intro to the rest of the interview... Which was, "let's brainstorm together other ways to copy files around until we run off the end of what you know". Was a fun one.

It was too long ago to remember details, but I suppose the interview got as far as "the data link supports 16kbps, the far side doesn't have compression software, but you have to move 10e6 zeros in less than 30 seconds, how?"

"Wow how'd you pass Google's lang interview so quickly??"

for(;;){}

> write anything in any language on the board

That is a horrible question that tells more about him then the interviewee.

Why? When I read that comment I looked up and laughed, imagining what I would choose. I’d probably laugh in such an interview — and why not?

It would lead to lots of enlightening discussion.

Yeah, "no right answer" questions open up the opportunity to work together in a dialog, which simulates real work better than "test style" questions.

I also had great success hiring for IT ops by telling the person, "we use some systems you are not familiar with here, so I'm going to spend the next 10 minutes teaching you the system, and then we'll discuss how you'd diagnose it when you get your first page about it". This tests their ability to learn something new, to engage with an unfamiliar situation, but in the context of mentorship. The only problem with such an intimate technique is that when someone bombs it, they really really bomb it: There's just no hiding what's happening, as it's happening.

Because it is a question that can't provide a positive signal, only a negative one, and since the negative signal is kind of flaky. I.e. somebody "passing" this by writing some code doesn't actually give you any confidence in hiring them. It is only going to filter out people who can't code at all, and then you have to ask them a real question. But due to giving the candidates no guidance, some who actually know how to program will not just bang out something simple in as minute. They will think it is a trick question; or waste time choosing what to write rather than just do it; or start writing something far too complex for the purpose of just passing the quick filter.

It is a profoundly shit question, setting up candidates for randomly failing.

10?"FSCK GOOGLE"

20GOTO10

I have given over 100 on site interviews for a large well regarded company, and I’d say about 20 percent can’t seem to program at all. I have only actually asked FizzBuzz once because it feels terrible to go with that simple a question, but they were failing another easy question and I wanted to calibrate if the easy question was too hard or they really couldn’t program. They completely failed fizz buzz - they started a for loop but couldn’t decide what to do in it, and the idea of directly translating each instruction in fizz buzz into a line of code in the for loop didn’t seem to gel with them. I know there is no way to know for sure, but it didn’t feel like just nerves - it really felt like they had no idea how to do word problems in math class, they couldn’t turn a description with a few bullet points into code implementing them.

So, for what it’s worth, I’ve definitely seen it. I don’t even think it’s particularly uncommon.

1/5 is the same ratio I was going to say. And that's people that make it past the initial pre-screen phone call.

I've also never asked fizzbuzz, but some similarly easy things. Like reversing a list. No memory or complexity constraints.

The candidate ratio I’ve seen has been all over the map depending on the company. At one place it was more like 90% of candidates who couldn’t write any code, another place it was closer to 50%, and I’ve worked at some places where nearly every candidate we got was at least somewhat competent as a programmer. The obvious answer is better pre-screening or candidate sourcing, but one of the places with generally high quality candidates was a small startup with no recruiting to pre-screen (although we mainly recruited from local meetups so perhaps that was good sourcing)

A lot of people learn on the job, and you miss 100% of the shots you don't take. I suspect that this occurs as many people work adjacent to software roles, and know some code/read code regularly - the gap is that they cannot recall basic syntax and if/else ordering on demand when asked to generate code.

My hiring manager told me the other 2 candidates the interviewed (both of which allegedly had college degrees) didn’t even make it to the fizz buzz stage. They got stuck trying to calculate the rolling sum of an array.

The amount of confidence needed to drive people around at high speeds is much higher than the amount required to join a zoom meeting.

Some people know how to put parts together but never learned algorithms and data structures. Most may have not learned discrete math, either. Those devs are still very effective but run into quadratic time problems a lot. I’ve met a lot of them in my work.

It appears to be so common because it's a self-selected bias of observation. The people who can't fizzbuzz are the ones who don't get hired and are continually circulating among the applicant pool. The people who can will get jobs and remove themselves from the pool.

If the question is why people who can't fizzbuzz keep trying anyway, well, Dunning-Kruger. They don't know what they don't know.

At that time I was at a relatively traditional company whose hiring and sourcing practices does not involve leetcode puzzles.

I'm not a fan of algo trivia either but fizz buzz is very far from leetcode imo. I genuinely would not be able to hire somebody who couldn't complete it, whereas some of the lc hards can be a bit problematic if your DSA is rusty.

I always figured leetcode was just a slightly harder version of fizzbuzz (because fizzbuzz really is a bit too easy.) You can often puzzle out a solution based on experience alone, if you've been programming long enough.

I guess the leetcode idea fell afoul of goodhart's law, and a lot of people just started memorizing algorithms instead?

Fizzbuzz is a basic competency check, it really doesn't require any "clever" thinking. I haven't looked at many leetcode exercises but the ones I have so far definitely go beyond that, and often place "unrealistic" constraints (e.g. not being able to use standard library functions). Which isn't to say they don't test anything useful, but as someone involved tech-screening hires, I doubt I'd ever bother with a leetcode exercise. Mind you I wouldn't use Fizzbuzz either, but only because it's too well known and easy to regurgitate a standard answer for.

I have over 20 years in software, only a few as a developer. I can provide value, but I can’t fizz buzz. If I studied for it I could.

There’s a lot of stellar talent out there that won’t fit traditional boxes.

So I'm not going to belittle you, I'd actually like to get to the bottom of what's going on here. You say you're a developer, but then ... I'm wondering why you think you can't solve fizzbuzz? Do you have trouble with loops? With conditionals? Do you have trouble knowing where to start? What kind of programming do you normally do (what languages or tools or frameworks do you use)? How did you learn to program?

Sometimes I've taught kids to program and they could solve it in a single lesson. Sometimes I've tried to teach people and they just couldn't learn at all. I'll probably end up teaching some more people in my time, so the better I understand, the better I can maybe help people in future. I hope you have a minute to help me out here!

I wrote network software in late 90s, including a cfengine replacement.

Probably wrote a few hundred apps. I’m old school. All in C.

Ok, that confuses me even more!

I was thinking maybe you relied heavily on javascript frameworks that do iteration for you. That might explain it.

If you've written a lot of C code, did you somehow manage to do so without using 'for' or 'if' on a regular basis?

(You can tell I'm very confused, because I thought 'if' and 'for' happen a lot in C).

Just to be sure: maybe you're confusing 'fizzbuzz' with something else?

Fizzbuzz was: print the numbers 1 to 100, but instead print "fizz" on every 3rd, "5" on every fifth, and "fizzbuzz" if both.

(That's it, there's no trick question, and we don't care about things like typos or off by ones, because everyone makes those if you just ask out of the blue)

Are you sure you've never written anything similar before in some function or other? (the original cfengine itself seems to have quite a number of functions that loop over something and filter it. )

Hi! Just wondering if you're still around? If you have a lot of C experience, haven't you written a lot of for and if statements? I'm still most confused.

The point of FizzBuzz is that if you can't effortlessly solve it without studying for it in particular, then you're completely unqualified for any sort of software development.

A FizzBuzz is a for loop and if-elif-elif-else in the simplest implementation. If you can’t come up with code for it (given the full problem statement, of course), then you can’t program at all.