I can't. Over my career I have worked with hundreds of engineers and scientists who wrote code. I know zero who are in positions where they have to write code at all, let alone as software engineers, who cannot do that.

> Both of these are very difficult things to accept. They may be even more difficult to accept if one is extraordinarily smart/diligent and one studies/works solely in organizations which apply brutal IQ/diligence filters before one is granted even a scintilla of the admission committee's time.

I spent my first 9.5 years at Raytheon, a company that is very light on the detailed technical aspects of interviewing and very heavy on the behavioral aspects. There are not committees, just the hiring managers and the interviewers. You know, the system that is supposed to have companies awash in these people who supposedly can't construct a basic for loop but can bullshit a good game. Never met one. Not at Raytheon, or Northrop, or Lockheed, or Boeing, or any of the other companies I worked with during that period.

Sure, most of them were what this community would disparagingly label as "9-5 engineers", but they all produced code that basically worked and provided some value to the program they were on. Normally if there was a problem it was a political or attitude problem, not one to technical ability.

That's what's so mind-blowing to me about our terrible process today. It aggressively tries to find and dispatch unqualified candidates, so much so that it forcefully repels talented people. And it fails miserably at screening out people who can't code! It is the worst case scenario of processes.

It's also really important to remember that the problem is People Who Can't Code, not "People Not Smart Enough To Code". Time and again I've "worked" with people who could very effectively critique my own code, who could participate in design meetings down to the bits-and-bytes layer, and, having taken responsibility for actually implementing some portion of those designs, could not commit usable code to save their life. I don't know what the deal with these people is, but they are out there: plenty smart, totally fluent, and completely ineffective.

I was talking to Erin this weekend about the phenomenon and realized that these people not only exist, but are actually favored by the way the market works. A smart person can last many months in a dev role before anyone realizes they're ineffective. Then, it takes many, many more months to manage them out of the team. By the time the story plays itself out, the bad team member has more than a year on the job, and when they parlay that resume line item to another prominent job elsewhere, their previous teammates aren't outraged but instead relieved. They end up with gold-plated resumes and tons of credibility.

1) Young, fresh graduates who still remember well the CS material. Or those who have a lot of free time and can study for these interviews (for example look at this Quora link http://www.quora.com/How-much-time-did-you-spend-preparing-f... the first reply mentions spending 28.5 hours per week for 5 weeks, which is 142.5 hours total) From a senior software engineers perspective that's a ridiculous commitment for something where an arrogant asshole interviewer can shutdown a whole onsite interview process because they're having a bad day or have some favorite question they think is the One True Question for determining if someone is a software engineer.

2) The software industry tends to overvalue youth. It has a very high salary at start, but also a very quick salary cap. And most companies have no technical ladder, and even those that do it's a joke compared to the manager ladder. All of this is not surprising. Since the industry is so heavily biased towards hiring and rewarding youth, older experienced engineers are not valued.

3) Senior software engineers have heavy pressure to leave the software field. I'm feeling this now. I'm a senior at my current place and my salary is basically capped. There would be little to no benefit going to another company. And even if I wanted to, I have a family now and don't have the free time to study for software interviews. My options are basically go into management, consulting, or start a business. I have no desire to start a business or go into consulting because I simply don't like doing those business related things. I want to be an engineer not a business person. But if I just stay an engineer, I will probably get laid off someday due to ageism. And if I'm an old engineer who is laid off, job mobility is basically gone due to ageism and the CS heavy interviews that I don't have the time or motivation to study for. So the only safe path is management. A lot of senior engineers face this decision. Which again reduces the number of mentors and experienced engineers to teach the new younger engineers.

4) And doesn't anyone notice just how wrong whole concept of studying for an interview is? There's a whole book publishing industry dedicated to technical interviews such as Cracking the Coding Interview. The technical interview has become like the SAT. Many could just study to pass it, but be horrible engineers.

http://www.conweets.com/tqbf/gayle/

(I'm having a pretty bad day, which I hope doesn't show through too much in that summary).

In that context, "give take-home tests" and "ask better questions" sound like the exact opposite of good answers.

I think this is a problem that's unique to very large corporations. Not only do thousands of people interview there, meaning questions and answers are likely to be traded verbatim online, but there's also actually an incentive to cheat your way in: you can hide out for 1-2 years and acquire a horde of cash and resume fodder.

Google have actually made this problem worse for themselves, too. By overvaluing their interview process, they've made cheating even more lucrative. Cheat your way into even an offer there and you have something valuable to put on your resume!

I suspect you haven't seen a lot of cheaters on take-home tests before because at a company like Matasano, there's little incentive to cheat your way in. You certainly can't hide out in a corner doing no work there.

Google is no more a proof of the value of algorithm tests than Github proves the value of manager-free organizations.

I was a bit horrified at the acquisition coaching comment. I did not realize that happened but of course it makes sense. Can't manage an acquihire if your devs can't pass the algorithm tests at the big acquirers. Shame.

It is actually more profitable for me if I say that these algorithm tests are BS and completely study-able, and even the worst engineer can pass them. That easily translates into "here! buy my book and even YOU can get a job at Google!"

It's actually a much harder sell when, really, it's more like studying helps someone perform better, but only to an extent.

Oh, and the acquirers encourage studying and prep, just as most of the top tech companies do for their normal dev (and non-dev) candidates.

To be clear: my experience is that the algorithm interviews, when done properly, work reasonably well to identify intelligence/problem solving and coding skills. Those are more important at some places than others. They can work well for certain places -- but not at all. I do not think that all companies should use this process. It's not right for all places, but it's reasonably good for some.

As for Google being proof of the value of algorithm test: I think you're pulling that from a twitter conversation very much out of context.

Context: Some people were arguing that the algorithm interviews offer zero value - that you'd be at least as well off, if not better off, hiring at random.

If they truly believe that (and they appeared to be sticking to this argument), then it's absolutely relevant that not just Google, but basically all the top tech companies, use this hiring process. Could a randomly selected group of engineers build the technology at companies like Google, Facebook, Amazon, etc? I suppose that's what they must believe, and I find that pretty absurd.

If they had argued that these interviews sort of work, but aren't nearly as good as some other interview processes, then you're right that the company about Google and other companies wouldn't be relevant. And I also wouldn't have brought it up.

Given that there is no correlation between job performance and interview score, are you saying this based on your gut instinct, or do you have objective data somewhere?

My best estimation is that the Google interview process is just a glorified fizzbuzz presentation, and that the hiring decisions are more or less made by arbitrary factors, including the nebulous "culture fit".

While it may be amusing to work through the details of doing a merge sort on a linked list in 30 minutes, it's certainly not germaine to the quotidian experience of an SWE at Google.

That's not a correct assumption. I suspect that you are referring to the (infamous) Google studies on this that were alleged to show this. The articles about this got many details wrong, and the study was fundamentally flawed. Remember: they only studied the people who did very well. That's like finding no link between exercise and health when you only study people who run regular marathons.

Merge sort on a linked list is a bad interview question, so I agree with you there. Good questions are problem that actually make you design a new algorithm.

I disagree with your assertion that lambasting Google's hiring practices is an easy sell in the market. The last time I tried I was dismissed out of hand by a talent consultant.

That... wasn't my assertion at all.

This has been going on for ages. A lot of coding bootcamps and similar things are just interview prep programs. A lot, I mean a lot, of people I have worked with can nail interviews but can't do real work for shit.

Unfortunately to land a job, you have to go through this process. Developing interview skills is parallel to being able to do actual work.

How? If the person is not delivering stories it's pretty obvious. I've seen a few people get the boot after three weeks.

Team accomplishments can be embellished, stronger team members can cover for the weaknesses of weaker team members, but admitting that a decision you made was incorrect gets punished. It's obviously better to hire someone competent in the first place, but the next best alternative, for the manager, is to live with their bad hiring decision.

As engineering managers, we were expected to "manage out" about 10% of the lowest performing staff on a yearly basis. The way that worked was basically that the 10% under-performers were to be put on strict personal improvement plans, and were under no circumstances given raises at all, and it should be made clear that no raises would ever come their way unless they improved.

That was it. Sounded harsh if you were used to 10% a year raises, as many of the good performers got. Not so harsh for those who were used to live in fear of getting "exposed" and fired.

And as a manager, if I were to designate a lot of my team as under-performing come review time, it'd reflect badly on me, so managers also had an added reason to push for good reviews for their reports: You'd end up getting paid more by getting good reviews yourself if your reports were helping create a good impression through rankings that you as a manager could trivially fudge (we did "360 degree reviews" were the manager and report could both designate some co-workers to review the person, which was of course trivial to game for those who wanted).

There was also an implicit expectation of a bell curve. If you had an under-performing team, that'd be awesome news for at least some of the weaker members on your team (and conversely, I several times had reports who got short-changed because I was told too many of them were designated "above expectations" even though my manager and other people who had worked with them agreed, and so several of them were ranked lower to get the "correct" spread - it was absolute lunacy).

Unsurprisingly, come hiring time, I felt like we were under siege by an army of ineffective developers hoping to find refuge somewhere safe and hard-to-get-fired.

There are scarily many places like this for ineffective people to hide. Sometimes for many years.

I ran into a C programmer that did not get the relation between pointers and parameter passing. It was some scary awful code. Damn prep for code review almost got me in a car wreck.

Conversely, there have been plenty of people who I would call anti-workers. They technically accomplished "something" but the quality of work was so bad that the team would have been more productive without them. They were a net negative productivity for the team. At most companies I've worked at there was one of those.

For example I've been told that iterating over list of objects and aggregating (min/max/sum) some of their properties would involve introducing dependency on local installation of SQL server.

If that's the bar, then I'd estimate that roughly 80% of programmers in the valley right now can't step over it.

This debate is filled with so much heat -- and so little light -- because everyone carries around their own subjective definition of competence. I've personally never met anyone working in a company who can't code at all, but I've met plenty of supposedly elite programmers who are adrift without a framework. Are these people useless? I don't know, but I know they're interviewing other programmers.

If I think about it long enough, I go in circles and I end up back at the thesis of the article: this industry is filled with some spectacularly judgmental people.

If I had to reduce the debate to two clear groups, it's that one group believes that there's a bright-line distinction between "good" programmers and "bad" programmers, and that the questions-at-a-whiteboard model is an effective way of discriminating the groups. The other group doesn't believe in partitioning the world into two clear groups.

It isn't debatable that there are a lot of people who can't write code. I believe that trivial phone-screen coding problems are pretty effective at weeding those people out. Beyond that, it's much more about candidate/position fit, and that's a more subjective question. The problem is that programmers tend to be uncomfortable with subjectivity, preferring instead to posterize the shades of gray -- that's how we end up with the apocryphal Google engineer who can't code.

In your stated example (person hired; can't fathom basic realities of C pointers), I doubt that it reflects a complete inability to be functional in some programming role -- just not the one you were needing. Most "Rails programmers", for example, would probably be hopeless in that situation, but perfectly capable of cranking out websites with Rails. I've seen a fair number of real-world programmers whose (lack of) knowledge of algorithms and data structures makes me cringe -- and I certainly wouldn't hire them for the kind of work I tend to do -- but I have to accept that they're effective within their niche.

On the other hand: I think the counterintuitive thing about ineffective programmers is that many of them are perfectly capable of reasoning through a CS problem in Java or C++ or Python on a whiteboard. But they're --- for lack of a better term --- useless when it comes to actually getting real-world systems built.

My thoughts about why this happens aren't yet well-formed. I just want to contribute the perspective that the "bad programmer" problem isn't just about people who can't buzz a fizz.

Software engineering is a performative art. Sure, there is a heavy intellectual component, but you actually have to do actual software engineering to get good at it. You can't just study the theoretical aspects. It's like how you can't learn Haskell just be reading a book and some websites. And yet, someone could go through school for CS and slide by without actually doing any real engineering / programming. I had a CS graduate TA (for a CS discrete math class), at a very well regarded school, who literally did not know how to compile a C program, full stop. He was very into the pure-math side of CS...but still.

As an analogy - you can imagine that someone who has studied music theory for years, has perfect pitch, knows how all the various branches of music relate to each other, which artists influenced whom, etc...could still be shit at playing musical instruments or creating new music.

Recruiting is two problems: outreach and qualification. We did novel things on both fronts. For this thread, I just want to be pointing out: the changes we made to qualification were critical, instrumental, fundamental to our success. Most of our best hires could not have happened had we qualified candidates the way we did in 2009, and the way most firms do today.

It's only sometimes about people not being aware of a language feature. It's usually about people not being able to program.

   System.out.println("" + 3/4);

In reality you'd only use a mod operator if you were doing things like sorting into 4 columns or doing an operation on every 3rd thing. And it's not a concept that is introduced at school. Now I try to think of it, I think I only picked up mod when I was learning rounding in my first language and the man page happened to mention modulus at the same time.

And every dev should have hit the remainder operator at bare minimum when they had a long running loop and wanted to print a status every kth operation, eg

   for(int i=0; i < 100000000; i++){
     // some operation
     if(i % 100000 == 0)
       printf("** operating on count %d\n", i);
   }

    z++;
    if(z>100000) {
        print x;
        z=0;
    }

A brief search on SO and lo and behold:

http://stackoverflow.com/questions/1504420/c-what-does-the-p...

Viewed 38,000 times. Every language probably has a similar question.

While only "older" (I'm 39) developers will be likely to have been in that situation, it took another decade after I moved onto hardware with FPU's before I worked on anything where we actually used floating point math.

Instead we'd be working with fixed point stored in integer. E.g. for financial systems, floating point is a nightmare. Working with fixed point to whatever number of decimal points our accounting department wanted (5-6 typically) for tax calculations and the like was preferred.

So there are large number of areas where people can have worked successfully for many years without ever using floating point.

Part of the issue here is that each of us has a different understanding of what it takes to get a "real-world system" built.

That's somewhat obvious because each of us has different "real worlds", so even within the same language/ecosystem there is a huge disparity in what skills are required to be genuinely successful in different teams/organisations/applications.

To put it in concrete terms, when I worked in banking, the main impediment to building successful "real-world" systems was getting clear, unambiguous requirements that could be translated into something implementable. Some of the best developers in that organisation were excellent at their job because they could take the incomplete and inconsistent desires of a banker, and turn that into a coherent and complete "world view" about the system they were required to build. We were primarily a Java shop, and they could produce an adequate application within the frameworks available to them, but I shudder to think what they would have said if you asked about "coupling and cohesion" or the java memory model, or how dynamic proxies work, or even how they should choose between making a field a short, int or long.

So, for my current (startup) organisation, I wouldn't hire those people - despite them being instrumental in producing some of the most satisfying and successful (ROI) systems I've been involved in. This team needs people who can do hard engineering, and if my former colleagues applied for a role here they'd end up looking like the proverbial "inept programmer" that we're debating.

This is a reflection on their skills, but it's also a sign that similarly named roles ("software developer") in different teams require and cultivate different skill sets.

Thanks to the Dunning Kruger effect, people who are incompetent do not realize they are incompetent. I remember reading a follow-up paper to this study (I wish I could find it again!) which concluded that when people have their mistaken beliefs pointed out to them, it actually reinforces that mistaken belief! This means that when people actually engage in debate, the two sides entrench and become more confident in their positions.

I have actually argued that this may be what leads large corporations to have a kind of "talent inversion". The people with the least talent have the most confidence and volunteer for the craziest projects. The projects fail, but due to politics the failure is hidden and spun into a success. The original developers begin to believe their failure was a real success and any debate to the contrary only strengthens their belief -- which fuels their confidence. This confidence allows them to be promoted where the cycle continues and multiplies.

This leaves you with a strange situation. Everyone will agree that incompetence is a big problem in the organization. Unfortunately, everyone will point to completely different people when asked who is incompetent.

Let's say that you want to improve the level of talent on the team. In other words, you want to hire only people who are more talented than the average person already on your team. I think this is not an unusual situation to be in. If talent is normally distributed on the team then half of the team is below average (I hope I got that right because I suck at statistics ;-) ). But thanks to "talent inversion", you may have a higher proportion of people in senior ranks that are in the "below average" section.

Now you can have a debate about the what kind of people to hire: If person A thinks that they are at the top of the talent scale, they can't expect candidates to be as talented as they are. Probably they think it is completely reasonable to hire people who are considerably less talented than they are. Person B may actually be at the top of the talent scale and may be arguing strenuously that candidates must be considerably more talented than Person A.

Clearly such a debate will have a lot of heat without a lot of light.

So people at a place like Raytheon who simply can't code (or don't like to code) end up doing something else that they are better suited for.

Early stage tech startups just don't have a bunch of ancillary positions like that. Founders and early hires had either better be great at code or great at biz dev.

Also it's worth mentioning that it's not just a tech/engineering phenomenon. It's very common for people in other professional fields (law, medicine, etc) to get a little ways into their career and realize that the job is not at all what they expected or wanted or are suited for, and there are alternate career paths there as well.

If you can't code, you're probably still useful for other stuff. Businesses love to take people they already know and find better roles for them. It's way better than firing badly utilized talent and having to interview for some other candidate with that skillset.

I wouldn't go so far as to say, "There are no incompetent employees," as there are definitely worthless people in the workforce. But it's not as clear as a lot of people might think.

All these companies require degrees, check GPA, and typically have managers that came from technical backgrounds. While not perfect, this combination reduces the chances that a total dunce slips through. Also, all of the above companies tend to be looking at engineers/physics folk over cs/IT, although in the past 15-20 years a lot more CS.

I work at one of the above and for a long time only EEs were hired for any software positions. In regards to math ability that's a fairly high bar. And math competency is pretty well correlated with the ability to program at all.

Not saying that someone couldn't slip through. But all of the mentioned factors tend to reduce the pool of potential flops vs some of the now-standard hiring practices (from the article).

Thing is, I'm a decent programmer, maybe even above average. My career so far has consisted largely of being the only or one of a few technical people and doing whatever needs to be done to make X happen. I built a poor-man's version of the mail sorting machines the USPS (and other postal organizations) use to photograph, OCR and sort mail. I remember everyone's mind's being blown when Outbox (R.I.P.) showed people pictures of their letters, and I built a system like that by myself for a previous employer in about two years while also completely rewriting the website. 65kLOC of VBScript/ASP to 20kLOC of python/django plus a whole bunch of new features.

If you believe sloccount (I don't really) in two years I did about 4 person-years of work that it says is worth a substantial fraction of a million dollars and a substantial multiple of what I got paid.

But I don't remember what a red/black tree is.

Knowing data structures and algorithms isn't the only way to be a competent programmer. To get my EE degree I had to take calc 1,2,3, diffeq, discrete math, linear algebra, senior level statistics, and these were all just pre-reqs to my engineering classes.

I think a lot of people get hung up on computer science == programming. There's a lot of overlap, sure, but huge amounts of programming doesn't have anything to do with computer science.

The reality is different industries have different standards. I'd probably never pass a SV interview because I'm not ever going to memorize many of the CS fundamentals. I work with EEs, Aeros, MEs that code (robotics types), math physics and chem PHds, etc. Sure there's a few CS guys here and there usually that double majored in phys or math.

On a given day, what's more important to our engineering problems is my understanding of advanced linear algebra topics, not a sorting alg (lot of work in CV recently for ex). We really don't bring anyone into an interview that hasnt studied the full gamut of math required in a math/phys/engineering degree. In such an environment, the interview questions are more about how you solved problems and never the memorization of some sorting alg. Oddly enough, when you weed out everyone that doesn't have a full math curriculum first, you don't seem to find many people that 'cant code'. Go figure.

How you solved a problem is probably the only meaningful way to screen candidates. Sadly there are a lot of people who think that a whiteboard coding session is "how you solved a problem" when few -- if any -- meaningful problems get solved in an hour or two.

When I get really stumped on something the first thing I do is get my head out of the problem. Go for a walk, work with my hands in the shop, get lunch, anything but try and solve the problem directly anymore. This strategy used to make me really nervous in college with short deadlines but now that's less of a concern.

I have yet to step back from a problem and not figure out the solution (at least where one exists).

Another part is the inherent error is using education as a proxy for ability to contribute.

My biggest concern, however, is that we assume there is a hierarchy of programmers. That the person who surpasses John Carmack is automatically more valuable than someone else, because it's a vertical pecking order.

In reality, it's likely that given the constraints of a position, Carmack++ is not a good fit.

We see someone build a faster sqrt algorithm as ability. What about the programmer who does his best to navigate internal obstacles adroitly -- why is that not praised just as much? It's certainly a difficult accomplishment -- why praise people for ability entirely?

I have a friend who is a mid-level manager at one of the listed companies, who came in without a degree, and was promoted because of proven competence to where he is now, and is spending several hours a week working on his degree because he's been promoted to the point, none of his superiors will let him be promoted further without a degree, despite handling the job better than his peers.

On the flip side, I've worked with people with a degree in CS (or similar), who couldn't develop a good software system if their life depended on it. The other side of this is, that many people don't continue to learn and only stagnate once they become familiar with one system. Software development tools don't stop coming out... there will always be new languages and platforms, but I have always seen a lot of resistance... I'm one of the few 40+ y.o. developers I know who keeps an eye on what's coming up in the community.

But my point was about Statistics. The HR warlords for all those defense/aero companies that have set these limits have done so because it segments the pool of candidates to one with a lower chance of bust (or so they've decided as such).

I'd like to see data, I'm some HR or consulting group somewhere has it. Or maybe it doesnt exist. A simple logistic regression problem with a high number of variables (degree or not, age, major, self-study, continuing ed, etc etc).

edit: also - all my comments are speaking from the engineering side of these companies. not IT. So the actual work content is a bit different than the original article may be concerned with.

For candidates who are fresh graduates, it looks it is the most effective way to ask algo and data structures. For a senior engineer who has at least 10 years of experiences, the interviewers cannot find some better questions to ask, to verify if the candidate is a good coder?

I was interviewed once. I was asked a question. I knew the question could be solved with a "fancy" algorithm, since I read the original paper in graduate school. It was elegant and beautiful, very creative. After so many years, I couldn't remember any details, and I had had no opportunity to use it in my work. I am not a genius, so I couldn't figure it out in 20 minutes during interview. Does that mean I am a fake?

It certainly sounds like the author doesn't think there are any actual incompetent engineers out there.

Personally, I know that to be false. I have worked with incompetent engineers, who literally couldn't code FizzBuzz.

Look at past experience, and ask the candidate to talk about that experience to verify that they aren't lying.

If someone has 5 years experience working at Google, and they can talk coherently about technical aspects of the projects they worked on, there is no reason to ask them to code on a whiteboard.

The way it currently works is this: I see you have a CS, degree and 10 years experience at a well known company. Excellent. Now you have 2 eggs and a 100 story skyscraper. Tell me the minimum number of egg drops you'll have to perform to discover the minimum height that will break the egg.

Every engineer no matter how experienced has to answer questions like they just left school yesterday, no other industry does this.

>Personally, I know that to be false. I have worked with incompetent engineers, who literally couldn't code FizzBuzz.

99 times out of 100 you could catch that engineer by talking to him about technical aspects of past projects he worked on.

I always argue for this, and about 98% of the time people look at me like I'm sort of crazy man and our company is going to go down in flames. Everyone has an anecdote, "well, there was this one time ....", yet I'm convinced that there's roughly 0 real value add from all of the hoops and hurdles most interviews provide in terms of accurately identifying strong candidates.

I always try to make the argument that if someone can talk intelligently about a wide range of programming knowledge in an actual conversation - for instance, knowing that data type X would be a logical segue from the current point, and do that throughout the interview, personally I think the likelihood of them being an idiot are slim. However, most people I argue this to are always afraid of this, afraid that some interloper will sneak through unless we put them through a gauntlet of questions regarding things they'll never do in their day to day life.

Like make a table view that has word counts for a string. Or make this simple puzzle game. Or make a simple address book app.

My current opinion on this would be to offer a laptop so you aren't disadvantaging candidates who don't have one too badly, but let people use their own if they have one (and let them know ahead of time that it will be an option and what they should be set up for.)

In the past, I've used CollabEdit for "phone screens" and the whiteboard for in-person interviews. I try to ask some "coding" questions (identify a better data structure / algo for a particular scenario and then implement it in code) and some problem-solving conversational questions. Seems to work pretty well, but I'm always on the lookout for better approaches. Part of the problem is that the software field is so broad that it's hard to get a sense of a person's abilities with such a limited amount of time to ask questions.

Would you rather a laptop w/ standard editors and IDEs or would you prefer a google doc, collabedit or a whiteboard like many places do?

Moreover, if you're that useless without your dual monitors and a full-size keyboard, would a whiteboard-based interview be any better?

Could you use this specific scenario to view how the candidate would react? If he starts to complain that the right tools are not on the laptop, or he is unfamiliar with environment, does it is signify that he is focusing too much on the tools rather than on solving the problem?

Maybe his time management skills needs some work, ie limited time to solve the problem and too much time worrying about environment.

However...

99 times out of 100 you could catch that engineer by talking to him about technical aspects of past projects he worked on.

That does not work for us.

We must put each and every candidate in front of a keyboard, and bang out at least a little code.

We had one candidate, recently graduated with an MS in CS. Nice personality, good talker in general. The candidate seemed to understand CS and could explain how to solve problems.

However, even with repeated prompting, I could not get this person to even type in a loop to start to solve the problem presented.

We've interviewed multiple candidates with a BS in CS or similar who also spectacularly failed at doing even basic coding tasks.

Some people are really great talkers. They really do sound like they know what they are doing. But that does not mean they can actually do anything.

>That does not work for us.

How do you know, did you try it? I said 99/100, sure there are some rare people who may slip through, but there are people who slip through a coding challenge as well.

How do you know that your coding test is better at detecting secretly terrible engineers than talking through past projects (for experienced engineers)?

>Some people are really great talkers. They really do sound like they know what they are doing. But that does not mean they can actually do anything.

That's sounds like a problem with the questions you're asking. Some people can throw out buzzwords and talk at a high level, but if you really dig down into the implementation details of project you can weed those people out.

A degree is not experience, CS != programming.

So we end up asking them all those sorts of questions.

Going through a CS degree without learning to code is easy. Depending on your CS course you may hardly have touched any code beyond extremely entry level courses where you're being hand-held the entire way, if you pick the "right" subject.

CS is not software engineering.

Similar with internships.

For both those situations, I can understand that you want to verify ability to actually write code.

What you seem to be implying, is that this is obviously true for graduates, but couldn't possibly be true for people with real experience. (But your implication has no evidence to support it)

Exactly why do you believe that it is completely plausible for a recent CS graduate to be able to explain the technical details of their final year project when in reality they contributed zero code to that project, yet it is entirely implausible for someone with 3 years experience to be able to be able to explain the technical details of their most recent development projects when in reality they contributed zero code to those projects?

Here is problem. It's not entirely implausible, just very unlikely.

The type of interview I'm talking about isn't going to catch every single bad candidate just the vast majority. But whiteboard interviews don't catch every candidate either and they have an extreme amount of false negatives.

To your point about students, they have much less work experience to talk about. The point of the interview is to look at their experience and talk about it to verity they aren't lying. In most cases the student doesn't have enough experience to tell me anything.

That being said, if a student can talk me through technical implementation details of a final project, then I think that's a pretty good indication that the student can code.

I would say the false positive rate for that test would be very close to the false positive rate for a white board interview with drastically lower false negatives.

If you're Google and you have a limitless number of people who want to work for you, you can get away with taking a vastly higher false negative rate for a slightly lower false positive rate. However, if you're almost every other company out there, you might want to reconsider.

Let's name some schools here. In no school I am reasonably familiar with (either first hand or by friends with attendees) would this possible.

I do think there are incompetent engineers, and I have interviewed about a dozen of them. It is very easy to filter them out.

The challenging part is to evaluate how good the candidates are, and if they would be good for the team and for the applied positions.

In start-ups with <20 engineers, you would like to have the candidates to be able to wear many hats. In a big engineering team, the requirements could be different. For example, besides challenging and creative work, there could be some tedious, even boring, work. The latter is also important, both for the whole system running smoothly and for the long term health of the system. So if the candidate is sufficiently competent, very detail-oriented, disciplined, team-oriented, she/he would be an excellent fit for the job, even if she/he is not technically very strong and couldn't figure out challenging technical issues. An excellent engineer, on the other hand, might get bore, grumpy, and leave in 6 months. It is expensive to restart the hiring process.

  int* foo; // The addition of a star here, on a type, means we're converting the type /into/ a pointer-to-int /from/ a plain int.

  int i = *foo; // The addition of a star here, on a value, means we're converting the type /from/ a pointer-to-int /into/ a plain int (reference).

  int& foo = ...; // The addition of & here, on a type, means we're converting the type /into/ a reference /from/ a plain int.

  p = &foo; // The addition of & here, on a value, means we're converting the type /from/ a reference /into/ a pointer-to-int.

(edit: C++ style comments used even in 'C' code to try and prevent YN from treating stars as formatting... replaced a few instances with 'a star'... changed emphasis to use slashes because it's still eating asterisks characters...)

The problem with randomly trying things with pointers is that sometimes you can accidentally fix the issue but introduce a subtle bug that's dependent on the data being stored.

Operative word worked. This is exactly what the article says: "They always seem to be elsewhere. For everyone."

(The presence of incompetent engineers was certainly a factor in why I left that job.)

It's an idea, not an iron-clad rule, that perhaps "incompetence" isn't as rampant as so many people suggest.

Algorithms? Why would you care if a programmer knows the details unless that's the job. More important is how they approach and attack a problem. Sometimes a half broken shell script is fine. Or leveraging a database because even though slow an inefficient it will do it right. Half the secret to success is... Um.. seriously just watch this video and you'll know it's truth.

https://www.youtube.com/watch?v=q5LiQcY0bqk

We have a couple of things to analyze here: 1) could this have happened? 2) in this case would your satisfaction be false, i.e. he wouldn't have been doing good work for you over the next few months?

Or is there a chance that he had some skills that didn't require knowing any coding, while being able to contribute valuably to you...

That doesn't mean I don't understand how firmware works. I know what's going on deeply under the hood, and I understand systems architecture. I know how to debug the stupid SPI interface when you're talking to an Analog Devices ADC that just won't respond for no clear reason. I know how to read the datasheets for parts and pick reliable ones that can be sourced readily and have sane interfaces.

I have no idea what a linked list is. I do know pointers, but not super well, I just know that they're a spot in memory that gives you the address of another spot in memory, like the program counter. I know my limitations, I'd never try to interject in dealing with a system that has a full OS on-board, and I'd refer questions about encrypted bootloader based firmware upgrades to someone who knows what they're doing. But I still know what Mode 2 SPI is, and the typical noise levels on different kinds of shielded cable. That's not nothing.

shrug

I think the best way to determine if someone is a decent engineer is to get them talking about previous projects. If all they can do is talk about it at a high level and they don't seem to have any real knowledge of the implementation details, they didn't do the work themselves. I once had a guy who claimed to be an instrumentation engineer, but didn't know (even vaguely) how you would go about measuring temperatures in a process you're dealing with. I could be wrong (often am), but anyone who has done instrumentation but has never encountered a thermocouple... well, that would be a very unusual history.

"I'm sorry, I don't actually know C, can I show you this in assembly instead"?

> I have no idea what a linked list is.

I cool thing about the linked list is that it's probably the simplest data-structure in all of computer science. I can explain to you what they are in less than 30 seconds, provided you have even the faintest grasp on how computers actually work.

> I could be wrong (often am), but anyone who has done instrumentation but has never encountered a thermocouple... well, that would be a very unusual history.

This is exactly what I'm talking about: A good programmer who can't understand and reason about a linked list, that's very unusual.

> This is exactly what I'm talking about: A good programmer who can't understand and reason about a linked list, that's very unusual.

Well put then, I say rather chagrined ;-)

My intended point though was that sometimes you can't tell how good of an engineer someone is by asking them about things you know. Better to ask them to talk about what they know. But that's not very controversial I'd hope!

  I have no idea what a linked list is.

Or do you really find it plausible that people who don't know a single keyword in C can be "fantastic" C programmers? Or that it's a good idea to hire very, very nice people who can program for programming jobs because they might have other skills that might be valuable?

It looks to me a few amazon-style 10 minute reviews could save many many hours of HR rumblings and expenses.

At one of my past employers, my manager (who sat next to me) told me that he wasn't allowed to say anything whatsoever about past employees - when anyone called to confirm past employment he had to give them HR's phone number, where specially trained operatives would presumably answer the one and only question allowed.

I didn't perform that interview but I was left wondering what the hell he'd managed to do for so long. A long list of experience on a cv can be meaningless if every post has ended up being a net drain on the team while others work around the problem.

This industry's biggest hiring/talent problem isn't "posuers." The biggest problem is the persistent and incorrect belief that applied mathematicians (CS majors) can easily learn the skils needed to engineer complex systems as they go (or, worse, that said skills are trivial or even irrelevant compared to the ability to recite textbook DS/Algorithms trivia) and that they are also able to adequately determine the capabilities of other similarly trained persons to do the same mainly by relying on textbook test problems (albeit sometimes with a twist).

In other words the (undisputed, in my opinion) existence of people who can't write a simple for-loop doesn't justify the absurdities seen in modern software interviews.

Having been involved in a large number of interviews as an interviewer, my experience tells me the issue is that many highly-competent engineers are incompetent interviewers.

To illustrate my point, here is an imaginary example in the extreme scenario. I once spent a large amount of spare time in graph theory. So I could easily fail at least 95% of candidates by giving algo questions in graph theory. The questions are easy to describe, so they are perfect for interviews in this sense. But I would have done my team a big disservice by turning away potentially very good candidates, and I would have harmed our company's reputation.

Edit: typos and grammers

I have never understood what application Mensa-quiz puzzles and algorithms trivia questions have to the day-to-day work of making things go. It seems like a smart-person pissing contest. Maybe that that's what the bulk of their work time consists of? I hope not, but I wouldn't be entirely shocked.

A previous employer loved them some graph problems for interviews. I got in an argument with one of the senior engineers, and demanded I be shown where in our codebase we used graph algorithms. The answer: nowhere. But you had to know your way around them to get hired there.

Now when I interview, I refuse to study them. I think this serves me well in helping me avoid jobs I wouldn't enjoy anyway.

An interviewer once essentially demanded I invent morris traversal on the whiteboard in front of him. I'm not sure how that related to my ability to be an ml engineer.

In fact, a long time ago an accountant used this very technique to decide that I was a smart software guy. He then hired me even though he knew nothing about computers and software.

If an engineer can contribute in a pair programming session then you know they have something to contribute in your development team later, even if you don't pair all the time.

when i run in to an interview like this, it tells me i dont want to work with these people.

thank you for this golden nugget. its like thinking you can build the best basketball team by getting the most athletic looking players, except much worse. i guess the conventional wisdom is that good software engineers are like mathematicians, but in my experience they are more like craftsmen, like a cabinet maker or ship builder. i suppose its contextual to the software problem, but analytical, deductive aptitude, while helpful, seems to pale in comparison to what i consider the craft (consistent style, naming, testing, pacing, working together and communicating, effective editor and shell use, knowing how the fuck to use git, etc) which have very little to do with analytical, deductive aptitude.

It seems to be something that is clearly inevitable. We've been trying for decades to construct the perfect interview process to weed out people, and while we've had some fair success, people always manage to slip their way through.

I wonder if we spend sufficient time on the remedial end of things? Can we improve our practices for handling bad software engineers? Can they be saved? When do we get to the point where it's appropriate to cut and run?

Mostly what I look for in candidates I interview (for sysadmin/sysengineer roles) is signs of aptitude. I have a baseline knowledge I'd expect from them, but after that I'm more interested in gauging how flexible they are, and how they adapt to circumstances and change. e.g. "I see you introduced Chef to your current place to handle configuration management, why did you pick Chef vs other solutions? What did you compare it to? What hurdles did you come across implementing it?" and diving deeper and deeper in to it. The deeper you dive the more apparent it should be what kind of role they played in the whole thing and what they've learnt.

Me? I suck at whiteboard coding exercises. I'm a sysadmin, and one who does a reasonable amount of coding, but put me in a room under interview conditions and ask me to write something to solve a problem and I'll struggle. Worse it always seems like I get stuck with a developer asking me to solve some ridiculous thought exercise that bears little resemblance to anything I'd do in the real world, that I'm assuming ties in to their favourite algorithm or something.

> It is also, regretfully, not the case that all applications one receives to an advertised position of Senior Ruby on Rails Programmer would be from people who had ever opened a command line.

It always amazes me how many "Geek Squad" candidates you'll see who never even mention Linux on their resume that go and apply for Linux Sysadmin roles.

It strikes me that in the same day (albeit one filled with hiring articles) we get an article about the success of Greyston Bakery, which will literally hire anyone and train and support them as much as needed to be successful—and this, which is along similar lines but is about software development, which, obviously, requires special aptitude that not just anyone can succeed at, and must be protected from those who would trick us into getting hired. /s

Somehow, it feels warm and fuzzy to support the social justice of the little bakery that could, but when it comes to our own companies, our true colors shine.

Continue to take the systematic approach. It is still the best way. Of course, of course you should hire as effectively as possible, and try to have a baseline of aptitude, but there are always going to be outliers and bad fits. It's far more effective to optimize your system for the success of all employees than to focus on weeding out the 'bad ones.' Sure, there will be people that won't fit your system, but they made it through the hiring process for some reason—figure out their true aptitude and transfer them to something they'll be effective at.

The article may be wrong about the existence of fakes and bad programmers—anyone who has filed through a stack of resumes knows that—but it's right on the unreasonableness of the fear and the weight we give it.

I say it all the time to our CEO: if hiring is really a huge problem we want to focus on, how did we get all these great people? Hm.

The real problem is organizational. Stop worrying so much about hiring, optimize your process and be done with it, and focus on what happens afterward instead.

Much as successful security involves "defense in depth," I suspect that good HR involves much the same. It's not reasonable to build a strategy on some sort of ultimate impenetrable barrier.

Most organizations have two actual levels of membership that often exist outside of the formal rules. The reason it works this way, is to sequester the "net negative" members and protect the contribution of the "net positive" members. This must be what Valve is aiming for with it's hyper "flat" lack of structure.

Yes, I've had people fail this. Yes, I gave them an extra day post-phone-screen to complete it. No, they did not complete it.

While I loathe the alpha male dance of software engineering interviews, I fully support the Fizzbuzz test, having encountered those that fail it.

I did see similarly qualified people turn up to interviews but they were all invariably rejected.

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?

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.

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

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.

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

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

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.

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.

The bridge analogy is spot on, in my opinion. It mirrors my above comment, and I couldn't agree more.

A common joke is that you don't let the theorists anywhere near the apparatus, because they'll break things.

The bigger problem apparently is that he's an asshole. Interviews can screen for assholes, but not with programming exersizes.

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.

That turned out to be a mistake, but that's another story. Point is, he went on to work at Google.

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.

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

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.

However, the question we should be asking is: do we need a question more complex than FizzBuzz to determine whether or not someone is an STE? If so, why?

And if not, then why do most developer interviews consist of a series of coding questions that are more complex than that? Because as much as we like to say "so we can see how you think", really, virtually all interview coding questions are FizzBuzzes.

Best job I ever had.

I think the answer to your question is that it's impossible to determine whether someone is an STE with 15 minutes in front of a whiteboard, because nobody codes like that. You will get false positives from people who can slap together a simple algorithm but don't understand why slapdash hacks aren't good enough for production, and false negatives from people who are brilliant coders but need a little while to get into the headspace, or have their flow disrupted by having to use a damn marker instead of a keyboard and their favorite text editor. You cannot identify an STE in a one-hour interview. If you want to see if someone can code, have them actually code.

Oh, here's another big problem I don't think anyone has mentioned yet: people who think that the stuff they, personally, have memorized represents the core knowledge of computer science that everyone should know, and everything else isn't really important. This is the guy who is unimpressed by absolute mastery of regular expressions, but sneers in disgust when you don't know all the arguments for pushd off the top of your head.

There was a lot more technical, and a lot more practical stuff to that interview as well, but as someone with both dev and dev management positions on their resume, I appreciated that the interviewer just wanted to know if I'd prepared or at least been paying attention for the last few years with the easy opener. Would you even consider someone in this career field who didn't know what fizzbuzz was?

I failed the interviews with some pretty decent companies. I got better.

My learning experience with that, is that the majority of interviews I took were not to determine if I was actually good at my job. They were to determine if I was good at interviews.

Yes, of course. Why would not knowing what fizzbuzz is disqualify someone? Simply because they have not heard of it or not read the article on it means absolutely nothing. Not being able to do it, on the other hand, would obviously disqualify someone.

Some wrote C or pseudocode on Java interview but pseudocode made sense and they could explain it.

I wonder if people with such experiences interview candidates without degree in CS (it's free where I live so it acts as a good filter). Basicaly unless you are on 3rd-5th year of CS degree or graduated, or worked as a programmer - you will have problems with getting to interview.

That said, the same goes for at least two of the professors...

Writing code is the easy part, after all.

You are a warm body. We need a programmer. We will teach you to program well enough to make the client happy, regardless of your prior experience. If you don't learn, we'll bench/fire/dismiss you.

It's very cynical, but at least it's better than "oh no they can't program whatever shall we doooo" I see elsewhere.

To your point, a good manager should be helping grow the skills of their team, even if a member who technically shouldn't be there has landed in their midst. The industry is littered with stories of people who, given proper support, turned from a liability into a huge asset.

Having someone take a risk on you and be prepared to invest in teaching you necessarily will come with obligations to deliver, and even if it doesn't work out chances are you're better off (hopefully you'll have learned something even if it worst case is just that you're not cut out for that work) than when you started.

We could use a lot more of that for people to get past the initial challenge of making the move into industry after graduating. Especially given that so many areas mostly have CS heavy courses rather than software engineering.

"The fooBar subroutine was one statement long."

reminds me of when I first started to learn Clojure. I was so used to "=" or ":" for assignment that I had a difficult time seeing where the assignment was happening. Especially the rules about destructuring, which took me at least 6 months before I was comfortable with them. Also, the recursive rebinding in a Clojure "loop".

I don't mean to defend the bad programmer that you are talking about, but I can imagine an experienced programmer having trouble recognizing assignment if they were new to the language and the language had some unusual system of assignment.

More troublesome, the place she worked at the time had a very complex technical interview process where candidates have to show at least some level of competency in the core languages and concepts the company was using at the time -- and he had passed it.

But once work started, he was completely incapable of even trivial development tasks...somebody who knew nothing and had access to stackoverflow would have performed better.

Eventually, after about six long months, he just had to be let go. But the mystery of how he made it through the technical gauntlet remains.

I thought I had escaped this for the most part, but recently, while working a contract that had my company in close proximity with another, I uncovered perhaps one the best bullshit salesmen I've ever encountered. He was a master at moving goalposts, organizing meetings, and producing lots and lots of activity, but no actual technical output of any sort. He knew all the latest technobabble buzz-words and even taught as a professor in the subject at a local college. His pedigree seemed great.

Finally, during a forced meeting, he was asked to show something anything he had produced, and he pulled up a half-formed, invalid JSON file he was hand writing for another project.

We've been able to separate our work from his group, but it's unbelievably aggravating that he's still getting paid.

How common is this?

I had a similar situation. I didn't challenge the developer directly, but when asked to justify why our project was falling behind I sent a summary of the VCS log to my manager. The developer hadn't committed anything in five years! Management promised to sort things out, but it's over a year and she's still employed.

Throwaway account, because this is one of the reasons I won't be employed there much longer...

What was this person doing while they were employed? Why did no one else spot that his productivity was effectively zero?

Actually, come to think of it, I think it's almost exactly accurate that "He had the same seniority in the same role that I would be have today if I had not quit that company 4 years ago." (This incident would have been from 5 or 6 years ago.)

>that Z should be allowed to "continue to devote his full attention to work which he is well-suited for."

So what was this work? What did the person saying this have in mind?

(I cannot possibly imagine anyone saying that with a straight face, if they meant that he is totally incompetent but is the boss's son-in-law. If your quote/paraphrase is anything near accurate, the person must have genuinely thought that z was making an excellent, albeit different type of contribution. He took time out of his day to tell you that. What could he have been 'well-suited for'?)

It's irrational to base a network security plan on the notion that one can concoct an impenetrable barrier. Very few things in the real world are built like this, because it's very hard to get that to work. Most successful plans are built on a notion of "defense in depth." Valve is probably using their structure to create a "free market" within its workforce, allowing natural leaders to create subgroups, elites, and further compartmentalization.

Even if Valve, being comprised of very smart people, has a magic interview plan that can select for real technical talent 100% of the time, all of the other possible workplace pathologies will be impossible to filter out 100%.

Also, how many years of experience with Java he has on his CV...

What the hell would he be suited for in that case? Sweeping? Mopping?

[0] Just one possible example, take your pick.

[+] c.f. Any of the following and note that they're from the nation of, ahem, conventional engineering culture:

http://imranontech.com/2007/01/24/using-fizzbuzz-to-find-dev...

http://blog.codinghorror.com/why-cant-programmers-program/

http://www.globalnerdy.com/2012/11/15/fizzbuzz-still-works/

I would note that a common theme in these posts is "I thought it was a myth but then I tried hiring and the boogeyman sprung to horrifying life."