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.
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.
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.
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.
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).
