That story could have been taken directly from my own brain. People like this get hired not infrequently and it's always frustrating to get one on your team.
I want to work where you have worked, then. Rant from the aircraft industry follows, feel free to ignore.
Engineering incompetence is widespread from my experience (flight test engineering). I wish, as a flight test instrumentation engineer, that I had not had engineers from various disciplines ask me how to interpret the contents of their test monitoring screens. I am responsible for providing the accelerometers, strain gages, data bus monitoring, and so forth that the various teams request and making sure that the data from those sensors is decision quality and properly telemetered and recorded. But it is NOT my responsibility to interpret that data. And yet, some of these other engineers, who are responsible for real-time monitoring of safety of test parameters during flights, clearly have no clue what they are looking at. One engineer even confused hydraulic pressures with engine temperatures during one test I was involved with and was about to raise a fault against my system because she thought the data was faulty. That's just one instance -- sadly, I have encountered many more during this career.
Yes, these people are trained in their disciplines and on the content of their monitoring screens, but for some, it just doesn't seem to stick. How can they, in good conscience, respond with a "GO for test" when asked if they know they do not understand their monitoring screen?
I've never worked with anyone who flat out couldn't code. I've worked with some who needed more help than others, but I'm fine with that since I've been that person myself with some things. But never with someone who just couldn't do it at all.
On the other hand, I've certainly had interviews with people who are just awful at it. So much so that I think the interview process is by far the greater obstacle to finding competent people than some huge mass of incompetent people out there.
Think about it this way- Almost no one has ever had explicit training in interviewing. Everyone learns by trial and error and rumor and superstition. It's one of the most cargo cult aspects of any given business.
I had a "software engineer" work for me that didn't know if from while. Literally. He was copy pasting stuff until it "worked". One day he calls me over because his program is hanging. He had something like " while (x) print something; ". I asked how that would work if x never changes in the loop. After I bit of blankness, I said " isn't this just supposed to print once, like maybe use an if? "
"Oh yeah, if. That's the one I wanted."
...
Worked with another person of similar skill, that went on to become Microsoft MVP. Do not underestimate how far drag-n-drop and copy paste can take someone with modern timing. Especially if they're good/inclined to tout themselves.
Say what you want about Google (it seems to be common here), but you will never work with anybody like that at Google. Really never ever.
You will work with managers, PMs, and lawyers who have much more coding skill than that.
Not to say there isn't bad code. Actually the problem at Google is people write too much code... But there is a base level of competence you can expect.
> you will never work with anybody like that at Google. Really never ever.
Well... at a previous company I worked at, we hired an ex-google software engineer. He had a good resume, and was one of the best interviewees I've ever had. He totally nailed algo questions and even some arcane functional stuff I threw at him he hadn't seen before (yes, those kinds of questions are pretty dumb, but I was a bit more naive back then).
But, this guy ended up being a terrible programmer. I mean, he seemed pretty darned bright from that interview session. Amazing even. But he was unable to ship code, let alone write good, elegant code. He just wasn't wired for it.
Ironically, he ended up getting booted from his team and moving into the biz side where he made a lot more money than the rest of us (trading).
Yeah, I'm not saying there aren't terrible programmers. I'm just saying that everybody can write a 1 to 3 line "for" loop and navigate a directory structure :) That's the level of incompetence the parent was describing.
Definitely not true. I'm a current Google employee, and one of my teammates (a senior staff engineer, no less) does NOT know what a unit test is, what an API is, what Borg is, or how MapReduce works. After suspecting this for a while, I asked him to try to explain some of these concepts, and he either had no answer or his answers were hilariously wrong.
(He did come from an acquisition, though, and doesn't write any code. He's more of a manager, despite not being on the manager track.)
I don't know what Borg is either, but then I realized it is likely an internal Google thing; unit test, API, MapReduce -- these are all ubiquitous concepts to programmers outside of Mountain View, so the inclusion of Borg seemed a little out of place.
I am currently working with Google. We had people who couldn't code on our team. I don't know if they were officially contractors like me or Google proper.
I knew a guy who could go to the board and draw a FSM, construct a context-free grammar, or construct a proof for anything the professor asked for.
And in Algorithms, he could go to the board and walk through any algorithm we happened to be talking about.
In essence he was perfectly suited to white board interviews.
But when I worked with him in Software Engineering his code was unmaintainable, poorly commented, and he was very abrasive and unpleasant to work with.
Yup. The difference between a computer scientist and a software engineer.
It's a sad state of affairs that our industry is currently conflating the two. Or maybe the industry has only now reached a stage where the two need to become separate?
I mean, you wouldn't expect a theoretical physicist to design an experiment or, worse, a bridge.
I absolutely would expect a theoretical physicist to at least be able to competently contribute to the design of an experiment, especially as it pertains to his specialty.
The bridge analogy is spot on, in my opinion. It mirrors my above comment, and I couldn't agree more.
That may have been the case for 2006 Google, not 2015 Google; there's ~18000 engineers now.
I helped a classmate who didn't understand basic programming concepts batting 1/20 in full time interviews before getting and accepting a Google offer.
That was when I realized how far Google's hiring standards have fallen.
Do you work at Google? I agree with the grandparent - I haven't met a single person lke that here. I'm sure false positives exist but they are rare - you need to do well on a bunch of interviews that involve both coding and algo questions.
Either your friend learned how to code or won't last long.
I knew somebody like that who got hired at Google. Bad coder, got fired from two companies in a row, and would have gotten fired from where we worked too, except I went out of my way to stop it from happening.
That turned out to be a mistake, but that's another story. Point is, he went on to work at Google.
This also happens in places where people are hired 'in bulk', and where technical questions can be answered by rote. Even when your standards are higher, it's still easy to hire people that are just slightly more incompetent, just by not doing a coding assignment.
This is why, at least around here in the Midwest, it's easy to stereotype other programmers by just looking at the last few companies they worked for. Came from XYZ? I won't even suggest an interview, because their architects would barely be junior devs here. Came from ABC? You don't need a screening, because you'd not have lasted two years there if you aren't at least decent.
This is the real reason hiring through networking is so prevalent around here. If someone competent vouches for you enough to bring your resume forward, chances are they'll at least not embarrass themselves in a simple interview that asks for a little bit of coding.
The reluctance of accepting a mistake in hiring is also an issue too, but I see more of that when we add both time and changing standards. For instance, I know of a big company that started with a really low talent level. They somehow managed to hire better people than they had, as time went by, but promotions have a lot to do with seniority. So you have a team of 'architects', that are supposedly in charge of things, but that, really, are worse at their job than the people that they are currently hiring. So what happens there? They have this nice cycle of hiring developers, having the good ones see that they will have to spend their time there arguing with architects that were never that talented, and whose skills are now outdated. But the architects have been there so long, they are part of the scenery. They'll never quit, as they'd never pass another interview for their experience level somewhere else, but they'll never leave their spot open unless they are fired. And management will not fire them, because they are old buddies. That's how organizations decline.
I know in South Africa, where I live, you have a third reason. And fourth.
3. There are regulations in place that disallow you from firing employees easily. Even if they're incompetent, they can only be fired outright if they break their contract in some really big/obvious way. So they're forced to follow the motions, giving warning letters, eventually having a meeting to discuss it, etc, and only after that has all been done, can they dismiss the employee.
4. Affirmative action quotas. Theoretically sound and noble. But in practice just means that if there is a shortage of said "group", then you are invariable forced to hire sub-standard individuals, and keep them. Sad, but true.
Funny aside from above. We once had a junior that was hired fresh from undergrad school, with the idea that they'd be trained up to speed. They were trained by the company (while getting a salary) for, I think, about a year before they were passed off as real junior developers in to the company. Said junior had the nerve to chuckle/mock me because I had an "IT" degree, instead of his fancy CS degree. In reality, he couldn't code a coherent piece of code to save his life. We spent countless wasted hours (this was after he finished the internal training) trying to at least get him to contribute something, anything even non-coding related. In the end, once he got his 9month/1year experience, he jumped ship. Probably to trick another company into paying him to sit around "learning".
"Never attribute to malice what is sufficiently explained by incompetence". Nepotism is not necessary.
In one company I worked for, the interviews were done by the self proclaimed CTO (which was one of the founders of the company) which was actually a dentist with no tech knowledge whatsoever. Of course in this case the interviews were just generic chats, with no technical question.
I once was offered a job for director of engineering of a big financial firm in the UK based on a couple chats over the phone with the CEO and some tech guy (don't remember the title). With the CEO, I just chatted a bit in general about my past and my future, with the tech guy, mostly explained my past, talked maybe 5 minutes about tech (design patterns or something) and that was it.
No code, no hard technical questions on what to use what or when, nothing. I know a lot of people that didn't have the skills for that job but their attitude and bullshitting techniques would probably have gotten them the job. And this was a very successful company handling millions in revenues and working with the major banks.
