Yap saw it. A large company someone new hired. Hung around for about a year, managed to write 100 lines of code. Only 10 were ever accepted after peer review.

However come meeting time, would be very vocal about random technologies -- we'd talk about spawning a process and he'd chime in how you can do this complicated kernel trick with signals, or shared memory and whatnot. At first everyone was impressed. Heck, I was.

After a while nobody saw any results from him though. When came time to show his results he started to claim to have health issues. So was gone for a while.

After a couple of months the manager caught on and kept assigning him different tasks hoping they'd finally find something he's good at. Would get as simple task, yet instead of just doing it, he would re-frame as some complicated theoretical problem, which needed research and the solution needed something like P vs NP solved in order to deliver it. Not sure if someone in the end explicitly told him that "Look Pete, it is a test function, just write the test function. You don't have to solve P vs NP to do it". (Pete is not his real name)

But yeah he was invited to depart, after collected a nice salary for about a year. He's probably at another company now doing the same thing.

Oh man, this brings back memories...

There was this company (shall remain nameless) where the product was always "around the corner". Just one more week or two! Yes it doesn't work right now, but these are minor things, let us iron out the final bugs!

This went on for almost two years.

Leadership being non-technical, they didn't know whether what the "technical team" was telling them is true or not. They couldn't check, but were not idiots, so eventually suspected bullshit. So they hired us as "crisis consultants", to do an audit and put things back on track.

Needless to say, we had to scrap everything. Which, it turns out, was about half a dozen unfinished PHP scripts and some apache configs... the result of ~4 man-years of work!

The main employee squirmed and lied and lashed back during meetings. Not a pleasant experience at all. For anyone involved. When the true horror of the situation became apparent, they had to be let go.

Of course, this "worked out" only because we had the leadership's full backing (they really felt more shameful than angry, on account of their mismanagement), and because we could stand our ground technically. Now what to do if you're a grunt employee, without good access to leadership, observing such bullshit unfold... difficult. Chances are, the bullshitters are better at politics & smooth talking than you are, so confrontations are risky.

Similarly, impossibility results in distributed systems theory can act as a pretty good cover. Something along the lines of "You know, in a distributed setting you cannot distinguish node failure from delays in communication. So no, I won't be writing monitoring scripts for this service. They will be useless."

> After a couple of months the manager caught on and kept assigning him different tasks hoping they'd finally find something he's good at.

This is exactly the reaction I'd expect from a good manager. Work the problem and see if you can fix it instead of blaming people for things.

I suppose I'm always willing to give people the benefit of the doubt, but of course only to a point.

Yes, but not actually a programmer. The guy was hired to be a project manager.

After joining things were as expected but after a few weeks we noticed that he was rarely around after lunch and never around after lunch on a Friday.

We would email him at those times deliberately to catch him out and I recall starting to put sticky notes on his laptop "Came to see you a X time". He would come back and just dump all the notes in the rubbish and claim he never got them. He would often claim to be working from home, despite his laptop being on his desk and usually closed. He would also never responding during those times to email or IM.

A classic seagull manager he would appear when something went wrong, making a lot of noise, writing a lot of emails and then vanishing. He would also be sure to be seen when something was delivered often staying back late on those times.

It got so bad one friend of mine started tracking when he was around and then tracking when one of his relatives died. During his tenure the following incidents occurred,

- Hot water system blew up. 4 times. He had pictures which he would show all the time.

- Uncles, aunts, and various over family members died to the total of 20 individuals.

- Our time tracking him showed him to be in the office less than 15 hours a week on average.

We started to suspect he had a second job and was pulling the same con on them. This was never proved, but we did find someone who had worked with him previously and they reported the same behavior.

The worst thing was it was raised with management at least several dozen times and nothing ever happened. He managed to pull this scam off for 4 years. I could not believe the waste of money this guy was, literally $500,000 burnt on a useless individual.

Pretty much why FizzBuzz is a thing: https://blog.codinghorror.com/why-cant-programmers-program/

Yep. At my last company we'd ask people to write an integer parser, and a task that required some very basic LINQ - a join, group by, and select.

We saw everything from completely non-functional code, to doesn't handle negatives or signal failures/triply nested for-loops respectively(partial credit OFC), to picture perfect code w/ multiple tests.

Obviously weighted very far to "completely non-functional code". It boggles my mind the amount of "programmers" who literally can't.

I wish I could give tests like this to my potential co workers as well.

When I was a recent graduate, I was thrown into becoming the lead developer for a product at a startup after my boss left to become a Java dev.

The workload was enough that we needed to hire another developer, so we lined up a couple of people for interviews. As the most senior technical person on the team (with two whole years experience) it fell to me to try and hire someone. I had barely had any technical interviews, let alone interviewed someone, so I did what anyone who read Jeff Atwood's blog would do. I used FizzBuzz.

Then and now, I still feel it's a poor way to judge someone's programming ability. It judges your ability to know the modulus operator above anything else. However, it did seem to weed out most of the people who came for the job. We had people with eight years experience and significant experience in what we did that couldn't get as far as the for-loop. I asked a couple of super basic questions to judge their knowledge (how do you guys deploy code at your current job? difference between a class and an object? etc), and nearly everyone answered these, but FizzBuzz was solved by only one person, even when they were allowed to use any language they want. We ended up hiring this guy, and he's still there (well, at the company they acquired them shortly after I left). We're still friends, and I consider him to be a rock solid developer whom I would hire again.

I've not used it since, but I've worked with a number of developers in the past few years that have walked into a job with nothing more than a CV of impressive words and a memorised list of answers to the kind of questions you see on the first page of a "developer interview questions" Google search. My favoured approach has been a relaxed conversation in a cafe and a task to build something, done either at home or in the office, but I often wonder whether I'd be better off just going back to FizzBuzz.

I have a "simple" problem where a piece of code somebody "wrote this morning" doesn't work. Its about thirty lines, has a pretty print harness and well defined inputs and outputs - it normally takes a competent programmer about 15 minutes to solve in an interview setting (less than five outside).

What absolutely shocked me when I first started using it is that it normally takes them 10 minutes for them to decide to insert any form of debugging code, and many try and not talk to me - despite introducing the problem as "a quick debugging task which we hope will show your willingness to talk problems over".

Of course the man that took the biscuit was the one who, after I introduced the problem boldly stated "This is obviously a complex problem. If I had more time I would be able to solve it for you". No.

Just at the last job, I was hired at the same time as another 'senior' guy. It took me all of 2 hours in the job to realize he was completely incompetent.

I requested a meeting with the director, and explained to him that despite being very new in the job, I suspected the guy was indeed completely incompetent, didn't have any experience of what we were working on and that me being an expert, it was pretty easy for me to realize he didn't know anything about what he was talking about. I emailed him proof that he had at least lied about the work he had done on a task... But the guy still managed to survive the first 3 months, so was 'hired'...

I told the director that I couldn't work with him at all, as I thought he was just a hindrance -- I emailed several times detailed reports to show he was completely incompetent at programming, and was just lying about stuff he did do....

The guy still stayed 18 months in the company, and he eventually left by himself.

After he left, I inherited his 'work' and proved in about 20 minutes that he had completely faked a demo he had done of a feature he was supposed to work on... The code wasn't there at all, they had been conned.

Thing is, said guy probably picked up some extra lingua to put into his CV for the next 'job' he'll go into...

> How many of you have not worked with someone whom you suspected of not being able to program, despite being paid to do so?

I haven't, and I don't understand how people like that get and retain jobs without having some other "in" to exploit the system.

> I don't understand how people like that get...

Their resume is so good. They worked at top companies. Nobody wants to insult them with some simple test of programming basics during interview, so they rather ask them what was it like working in the Big Companies. After some chit-chat, they get the job. The company thinks they're lucky to have hired someone that smart.

> ...and retain jobs

Inertia, lack of communication inside the company, etc. Those people are usually also very friendly and soon learn who reports to whom and how to hide the fact that they aren't contributing anything useful.

> Their resume is so good. They worked at top companies. Nobody wants to insult them with some simple test of programming basics during interview, so they rather ask them what was it like working in the Big Companies. After some chit-chat, they get the job. The company thinks they're lucky to have hired someone that smart.

So, bad processes and cultish worship of certain companies.

> Inertia, lack of communication inside the company, etc. Those people are usually also very friendly and soon learn who reports to whom and how to hide the fact that they aren't contributing anything useful.

So, more bad processes.

I know my responses are bordering on flippant, but having come up from the real engineering world I don't see how these things happen for any reason other than companies in this industry are not run nearly as well as their management thinks.

Maybe they hired some managers who can't manage, but interview well and have a lot of experience managing at top companies?

Dual response to you and raverbashing, since you both express the same concept:

Having non-technical management interview and assess technical hires is a serious process error. If you are hiring someone, regardless of what it is for, and you task someone with evaluating that candidate in an area the interviewer knows little to nothing about you have screwed up royally and need to fix your process. I haven't seen that happen in a real engineering company, at least not for technical roles.

I don't get this. Even when I interview people I am going to report to, I grill them on technical questions.

Managers are usually the less technically inclined at certain companies. They don't know what to ask and they don't care

It's especially common when they used to work at a "famous" company.

Some real world examples: in the mid-2000s being a "Googler" was a straight pass by some to thinking you were some wizz-bang amazing programmer. Because Google only hired the best and brightest, right?

Then you work with some of them and realize they they were nothing more than a smart college kid who got lucky with who hired them and were terrible programmers. They were juniors at best, but now with the ego of RMS.

The same happened for a while with "Game Producers" from Zynga, when they were riding high and had a better reputation. The trouble was that Zynga had a policy of rapid promotion so you got "Producers" and "Studio Leads" who couldn't last 5 minutes outside of Zynga. That wasn't always the case, but it happened enough that it actually became something of a black mark in the industry.

So basically you just hire people with stellar-looking resumes. When has that ever been a good idea?

Never said it was a good idea but it's shockingly common. Also passing an interview isn't hard. Especially if you know the right terminology and are personable.

It's the day to day on the job tasks where the lack of skill becomes really apparent.

former js coworker: "i cant populate that dropdown with the results of an ajax request because everything is 'async' in javascript"

Current co-worker, a contractor, on a remote project wrote 1000+ lines of JS to load a JSON file in Node (he didn't realize he could just require it).

While playing with Node as someone new to JS at the time, I wrote some code to load a JSON file due to not knowing I could require it... and it was vastly less than 1000+ lines.

On a similar basis, I once worked on a codebase where someone had implemented strftime, poorly, a few different ways, and also come up with several replacements for strptime, all of which had subtle bugs and none of which worked the same.

Both of your examples describe people who can code.

Given only the information you provided, I would hesitate to mock them, for fear they might make something really cool.

Though strftime is in ISO C, so there is little excuse, strptime is a POSIX function, so there is at least the possibility of a credible portability argument there. (Though this probably doesn't stretch far enough to justify the lack of an #ifdef to select the system's strptime if it is provided.)

In this particular case the application was already quite POSIX-dependent in other ways, but it's a good point to make -- I did hesitate before deciding on it for that reason, now that you remind me.

To add additional details, for those who might draw amusement and/or wisdom: In all cases the input/output date/time strings had the same format. Further, a number of the bugs were due to half-implemented reinventions of atoi being involved -- and atoi was definitely available, as one of the reinventions used it! Finally, in at least one case there was a Y2100 problem.

To be fair, I'd reroll atoi too - but only once, with "sufficient" unit tests (e.g. round trip unit tests for INT_MIN..INT_MAX), and only because atoi has no proper error checking nor wchar_t* variants.

Indeed; atoi in fact invokes undefined behavior in out of range situations; you can only safely use it when the input has been lexically analyzed to be a valid integer of only so many digits as not to overflow.

I'd tend to make this re-rolled atoi a wrapper around strtol/wcstol.

> atoi in fact invokes undefined behavior in out of range situations

Ouch! TIL. You'd think by now I wouldn't be surprised by such things, and yet, somehow I was...

On the other hand, if it worked, he could write a JSON parser, which most programmers cannot do.

I could forgive anyone for not knowing about requiring json files in node. It is kind of arcane.

But 1000 lines?

    var x = JSON.parse(fs.readFileSync('filename.json'));

Huh neat I actually didn't know that.

There must be something missing to that story. Even the most asinine way I can imagine doing that would be 50 lines max.

Did he try to write a complete JSON parser from scratch?

I was such a guy for a while.

I actually can program, and implemented some stuff in that company (moving the whole codebase from svn to git and educating everyone, for example). But then I got into depression because of family issues, and just couldn't write a single line of code for an entire month. I kept giving excuses, inventing all kind of bullshit to cover it, and felt even more depressed because of it — so when they finally fired me, I was relieved.

Now when I see guys who're doing this all the time, I can't help but imagine what's going through their head all the time and in what an awful state they must be in.

> And gets credit for it.

You let him get credit for 7 years?

When you're in the trenches, it's often hard to know what's being presented externally.