Hacker News Reader

Comment by skizm | Hacker News Reader

I'm totally okay with that. I was fresh out of school and was working at a small consulting company that required us to go work with some larger companies and lots of "senior" devs - 10+ years of experience all of them - I'd say 50-60% of them could not code fizz-buzz.

There was one meeting with two devs, both of whom had worked as programmers for over 10 years at this company and we were looking at code one of them wrote. The code looped over a string's chars to check for a single char's existence, and there were 26 IF statements: one for each alpha character. I had to explain to these two about the "contains" method. 10 years of programming experience each. And I had to show them the "contains" method... Since then "X years of programming" doesn't mean a thing to me.

View on HN

How are people that can't do fizzbuzz able to function in a programming job? The thing you describe should lead them to struggle with virtually anything. I used to do front line interviews, and it was rare even then for people like that to make it to me. I've mostly worked for large, successful tech companies. I don't see someone like that getting a job, and definitely not being able to hang around for a long time.

I assumed they got by without doing much work. I was there mostly to fill budget. This company had a policy that projects had to meet budget. Their window was 2% under budget or 5% over budget or they would get in trouble (or maybe the budget was less next time or whatever).

As far as I could tell they would just try and get lost in process as much as possible and not do any work. I just went with the flow, I wasn't trying to make waves. Also, I was only working with those two in particular for two months. Did almost nothing. Took a week to get approval to add a column in a DB. I could have written all the code that eventually went into production in 5 minutes without red tape, and that included testing.

What kind of company was this?

It's amazing that these horribly managed companies haven't gone bankrupt yet.

It was probably a government contract.

In the contracting world, I get one of these people every year or so. They jump onto projects often, are discovered, given warnings and improvement plans, and usually find another project before they're actually fired.

Their big asset is that they can be billed at high rates but only get paid minimally themselves, allowing the contractor to pocket large profits. The bean counters love to hire them, and just expect the good developers to carry the dead weight.

Not to appear to be misogynistic, but 3 out 4 of these, at least in my experience, are women. Usually they can coast far longer than most men because there is always one easily manipulated male dev on the team who gets suckered into helping her do all her work. I was that dev once early in my career.

Yeah. It's recurrent in contracting firms.

But it makes sense for contracting firms. People get billed no matter whether they do (or can do) anything. The ability to execute is not part of the job.

Because 'writing code that somehow works from business perspective' and 'writing well-designed, readable, maintainable and optimized code' are two different things.

I have similar situation when Team and Tech leads in our company write shitty and unmaintainable code. But they've spent N years in the company and became leads because of that.

This is a good lesson though: at the end of the day, revenue is the only thing that matters. The CEO doesn't care if you are looping through strings using if loops or string.contains() or whatever, because he knows that what keeps the company in business is whether the contracts get signed, which they often do as long as the product works reasonably well and satisfies customer requirements.

This isn't to say artisanship is unimportant, but that it's not the most important thing.

You're right, but it misses what's really happening: it's a trade off between short-term and long-term productivity. Essentially, writing bad but working code quickly today means technical debt, bugs, and taking longer to add features later.

Decent developers can avoid this trade off, and write decent code in the first place in about the same time. The trouble is, the CEO typically can't tell the difference. Even long term, it's hard to identify if something is taking long because the team is rewriting crappy code or undoing shortcuts, or the task is just difficult.

"The thing you describe should lead them to struggle with virtually anything"

... And now you know how Comcast help pages describe settings that do not exist, and why RiteAid calls me "Nancy Brown" when I log in and on and on.

A bureaucratic IT department in a company that doesn't sell software as their main product usually does not have the meta ability to rock software development.

I've been doing this since the late 80's and I've never even been asked about fizzbuzz.

Every time it's mentioned, I have to go look up what it means. For some reason, it refuses to stick in my head.

When people say someone "can't do fizzbuzz", do they mean can't do it cleanly or optimally, or can't do it at all?

Can't do it at all. About 70% of the people we interview fall into this bucket. Another 10% can't do it cleanly.

The rest get to continue past the first five minutes.

Just to clarify, since I've never done a programming interview:

70% of people can't do fizzbuzz during the interview?

Correct.

For our coding screen, we use coderpad.io, which lets you chose whatever language you want. Go try it out yourself!

Thanks, I'll check it out!

That's so surprising to me that such a large percentage fail, especially if they get to choose the language

Doesn't include Lisp :-(

At least it includes Clojure, which is technically a Lisp...

Presumably in their preferred language, or with acceptable pseudocode?

I find that baffling, and I am self-taught and a very mediocre programmer. I'd barely even call myself a programmer as I've historically spent more time designing. I can't think of how they might be stumped by it?

Is it true even of programmers with experience/age on their side, likely to have encountered loads of real world challenges? I've gone back to read about it a couple of times since first hearing of it - swear I must be missing something?

Is it possible that they're both unfamiliar with the language/environment? I doubt I could write a working fizzbuzz in go, and it's been so long since I've written C that I'm genuinely not sure if I remember how to write a working program.

Then get them to write it in pseudocode? Would interviewers disallow that?

That's what I've always been asked to do, and what I always ask to do. I don't want someone stumbling over "is it toLowerCase() or toLower()?" while they're thinking.

I've read that same stat elsewhere, so thanks for the confirmation. Maybe these people are nervous? Sometimes your mind goes blank when you go into an interview, so I'm interested in knowing how far they actually get when solving the challenge.

I assume that most of them fail to get the logic right. Yes, even those the logic might seem to be trivial, a lot would fail to either get even the pseudocode correct. Many others would fail to translate it correctly into code (even in their preferred language).

I found that OP's key phrase is senior dev "manager".

Senior dev are required to have these skills brushed out for a technical interview, however 80% of dev manager don't program at work anymore. Asking them for this kind of skills that are not going to be required in the actual job is a bit odd to me too.

How do "such" devs get hired in the first place? The one who interviews and hires them must be a bad dev, too.

But doesn't this demonstrate that completing HackerRank challenges is absolutely not indicative of coding ability?

Imagine their code looping over the latest version of Unicode. :)

Reply on news.ycombinator.com