On Secretly Terrible Engineers - <AUTHOR> http://techcrunch.com/2015/03/08/on-secretly-terrible-engineers/ <comment><USER2> It is, regrettably, not the case that all people who work as software engineers can e.g. code a for loop which counts the numbers of lower-case As in a string. This is true even if you spot them the syntax for a for loop and finding the Nth character in a string. It is equally true if you allow them to complete the task in isolation, at their own computer, given an arbitrary amount of time to complete it.

I am, naturally, constrained from saying "Here's a list of three of them." It would not be difficult.

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.

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 remember, rather vividly, the first time I figured out that an engineer couldn't program. I was attempting to tell him where a value was being assigned in a program. After failing to do so over email, I went over to his desk and asked him to navigate to the file at issue. He was unable to do so. I told him I would do it, assuming that he was unfamiliar with the directory structure in that part of the program, and opened the file. I then said "So you see, the assignment is made in the fooBar subroutine." He couldn't find the fooBar subroutine. I said "It is the third method on your screen." He couldn't find it. I said "It is this one, here, which I am pointing to with my finger." He said "OK, that one. Where is the assignment?"

The fooBar subroutine was one statement long.

A coworker, having overheard the conversation, stopped at my desk later, and explained to me that, if I had pressing engineering issues, coworkers X and Y would be excellent senior systems engineers to address them to, but that Z should be allowed to "continue to devote his full attention to work which he is well-suited for."

The industry has many destructively untrue beliefs about hiring practices. That there exist at least some people who are not presently capable of doing productive engineering work is not one of these beliefs.

<comment><USER3> > I am, naturally, constrained from saying "Here's a list of three of them." > It would not be difficult.

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.

<comment><USER4> The Matasano hiring process (to which this article refers) was designed in part because of this bad experience you've never had. I've seen it happen repeatedly over my career; people who'd pass interviews and then, over 15-20 minutes of face-to-face discussion a couple weeks on the job, not be able to comprehend the idea that a C pointer needs to point to valid memory.

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.

<comment><USER5> The software industry is broken for older engineers. Look at the typical algo/CS heavy interview today. It favors and selects for these characteristics:

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...](http://www.quora.com/How-much-time-did-you-spend-preparing- for-Googles-interviews) 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.

<comment><USER4> Interestingly, the author of that book also wrote the top comment on the TechCrunch story, disagreeing pretty strongly with me about hiring processes. I got to talk to her a bit about it on Twitter:

[http://www.conweets.com/tqbf/gayle/](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).

<comment><USER6> Bummer. Her career seems to be predicated on a correlation between algorithm tests and performance. Can't expect her to seriously entertain disagreement as long as the current model is profitable for her.

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.

<comment><USER7> Your assumptions are false.

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.

<comment><USER8> "To be clear: my experience is that the algorithm interviews, when done properly, work reasonably well to identify intelligence/problem solving and coding skills."

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.

<comment><USER7> >> 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?

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.

<comment><USER8> It may be that the studies were flawed, and that the reporting was bad, but that flavor of study has been replicated in other venues besides Google. Given that, it essentially comes down to culture being the deciding factor in these interviews. Given the stark cultural skew at Google, it's possible that the pseudo-analytic SWE interview is actually masking systematic bias in the hiring process.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER9> I've gotten interviewed by people who thought they were great but didn't know what they were doing. And I mean for serious companies like Pebble. 22 year olds who can't even properly phrase interview questions.

Whose the terrible engineer? Me with a patent and 25 years of innovation in key major products like the playstation network? Or the guy who interviewed me who gave me a thumbs down for being "terrible"? Or maybe it was just cause I have grey hair in my beard?

I see a lot of attitude about how there are "bad engineers" that seems to come from younger people who are very ... proud ... of their skills, but are more bluster than brains in my opinion.

I don't think they're terrible- I think they have potential. But they have the wrong attitude.

<comment><USER10> _" 25 years of innovation in key major products like the playstation network?"_

So, I'm going to have to come off as the punk-nosed kid here, but I've gotta ask: What does that mean? That literally read like biztalk.

What algorithms did you develop? What code did you write? What systems did you architect? How did you make design tradeoffs?

I can't tell a "stakeholder" who did real engineering work apart from a "stakeholder" who got their name attached to the patent for political reasons.

<comment><USER11> Lets say the dude invented something important? are you to have a better follow up question?

If your point is that they commenter is delusional, and at once over- estimating himself and under-estimating others, you should come up with a better way communicating it.

A _proper_ punk-nosed-kid would certainly be more clever.

<comment><USER12> He asked some pretty straightforward questions, like what the poster's concrete contributions to the project were.

<comment><USER11> It adds nothing to the discussion. If the guy did something major (case#1), the discussion is over. It just makes the person asking the question look like an ass.

The other issue is that anyone who would have a reply of that caliber most likely wouldn't reply...why bother...? Thats the (#2) second case. Again, the discussion is over.

The third best case is that the guy is bluffing, and doesn't bother to answer the question. This is case (#3) but isn't really any different in motivating the discussion than case #2. Game theory says the bluff plays to look like the win, right? So just don't answer (and mimic #2).

So there are no rational replies to this question.

As an interrogation-style question its a failure.

</comment></comment></comment></comment></comment><comment><USER13> It's notable, and obvious, that this guy has never actually tried to hire a developer. He has the luxury of thinking that these "secretly terrible" people are rare and misjudged. He's wrong, though.

(That's not to say that industry standard interviewing techniques are perfect -- they're definitely not, and they're often awful -- but "lots of professional programmers simply flat-out can't program" is a true fact, and a hiring process needs to deal with that reality.)

<comment> FLUX-YOU >simply flat-out can't program

This phrase is seriously abused and it needs to stop because our field has anything but standardized and well-known competencies that we expect people to know before they commit anything.

Compiling main() with an assignment and a print is technically programming, but has extremely little to do with what is actually being developed in real products. You aren't going to give anyone a job if this is all they can do. As soon as you get out of the absolute basics (IMO, if/for/assignment/operators), your demands are simply arbitrary with what you think will indicate that someone can do the job.

You might only consider someone who can pass FizzBuzz as a 'real programmer'. Someone else might only consider someone who knows and can implement advanced patterns and quickly absorb an unfamiliar API as a 'real programmer'. Programming-Genius-32 might only think someone's a 'real programmer' when he can implement every algorithm from MIT's curriculum from scratch.

And if I had to make a wild guess, I would guess that people create their own standards of what a 'real programmer' is based on things they have already solved or things they read from someone else. Then they go make hiring decisions based on this standard. It is very likely that someone can look down on many of us and call us fake programmers because they're just so much further ahead.

Convincing someone that you are a real programmer of a certain skill level is a social exercise, not a technical one.

<comment><USER13> No, I mean it literally, as in can't do do a loop/if/assignment level operation. ("Write a function that returns the sum of the two largest numbers in an array" is the literal question I would ask that the majority of candidates -- all with years of experience doing software dev -- were unable to answer.)

They simply flat-out could not program. Full stop.

<comment> FLUX-YOU And if I did this in your interview, how would you feel about that?

        List<int> blah = new List<int> { 3, 8, 2, 1, 5, 9, 0, 12, 14 };
        // pretend I don't know the numbers :)

        blah.Sort();
        blah.Reverse();

        return blah[0] + blah[1];

<comment><USER13> Congratulations, you are now better than 2/3 of applicants I saw.

I'd follow up by asking whether there's another way you could have done this (the obvious loop and store method); if you didn't come up with it, I'd explain it to you, paying attention to how well you seemed to understand it. I'd go on to ask about what characteristics make one of those solutions better than the other, hoping you'll mention the performance characteristics of sort vs. simple iteration, and maybe also the maintainability/extensibility of the two methods.

And then I'd move on to my next question with cautious hope.

<comment><USER14> 2/3 is generous. That implementation probably puts you in the top-90% of candidates that make it to a technical interview.

<comment><USER15> You mean the top 10%?

</comment></comment></comment></comment></comment></comment></comment><comment><USER16> > doctors are asked trivial questions just a handful of times in their careers > during their bar examinations and boards.

This is incredibly inaccurate. Physicians have to take a series of comprehensive, extremely difficult licensing exams just to graduate medical school and get a residency. Then, to be board certified, you have to take and pass comprehensive and expensive board exams in your specialty every couple of years, depending upon the specialty. Furthermore, they keep increasing the frequency of the required examinations. Doctors take tests to prove their knowledge their entire careers.

<comment><USER17> You are too polite. Where I come from, we call this "a pile of horse shit."

<comment><USER16> You said it, not me :-)

</comment></comment></comment><comment><USER18> It's painfully obvious that the author has never tried to hire developers and, in fact, has never worked on an engineering team.

This line, in particular, is blatantly false:

> In all my years immersed in the tech industry, I have never once heard a > firm talk about the idiots lurking in their own offices.

Firms might not talk about it (nobody wants to say they have bad employees). But people certainly will. Nearly every developer I know has horror stories of working with incompetent colleagues who literally couldn't program. And there are even more incompetent churning out job applications—FizzBuzz exists for a reason.

So it's clear to me that we need some sort of clear technical test before hiring people. But I also think FizzBuzz could be sufficient for that test. There's no need to administer an algorithms exam if all you're trying to do is find out if someone is an incompetent engineer or not (there are plenty of competent engineers, including myself, who would have trouble writing a trie on the spot).

</comment><comment><USER19> This article is juxtaposing our fear of hiring an incompetent developer, vs. our indifference to the skills of developers once they join our organization. That's what he's saying when he says that everyone's afraid of secretly terrible engineers.

If each company spent a (comparatively miniscule) amount of resources on consistently training their current developers, then the team would be constantly improving.

We think that miraculously, good developers become good, sometimes by heroically hacking on their own, sometimes by going to a prestigious school, never by practice within a big company. Then, one we hire them, their skill level freezes. This is why it's important to hire good people.

This is the same illusion that keeps the US public school system focused on hiring good teachers and even more focused on firing bad ones, without focusing on improving current teachers' skills. We, as an industry, need to focus on practice within the organizations we control, we need to focus on making everyone better, and we need to kill with fire the idea that hiring good people is all you have to do to have a good team.

<comment><USER20> This is also the same problem with the entire H1B situation and why Google, Apple et al. have made some pretty poor justifications of the price-fixing collusion: because they've avoided investing in on-going education to such an an extent that the only thing they've been able to imagine for getting talent is poaching it from other companies (leading to the on-going upwards price war).

They could easily solve their problems if they actually wanted to train people, and promoted those who would/could mentor more aggressively.

</comment></comment><comment><USER21> One of my co-workers is a terrible engineer.

The thing is, he's very smart. He talks like a smart person, and he's very knowledgeable. And he can code well, and destroyed every question when we interviewed him. He even works long hours, to the point where he broke up with his girlfriend.

The problem with him is that every feature he has worked on is buggy and ends up causing more work to fix because his implementations are terrible. This is something that doesn't come up in interview questions.

I don't understand, because he's a smart guy. But he worked on 3 features in 2014, and all of them are disasters. A year later, we still run into bugs caused by poor implementation.

The thing that really boggles my mind is that people don't realize it, and think he's a guru. Even in a company filled with people that I think are smart, they can't see through his ruse and realize that for the most part, the work he does is not good, and the decisions he makes are poor. He even got a raise and a promotion. It's infuriating, but I guess things like this happen all the time.

<comment><USER22> Cue impostor's syndrome kicking in for many HN'ers:

"Crap, do I work with this guy? Is he talking about me? Did I miss any bugs in the code I shipped this week?"

</comment></comment><comment><USER23> I have worked with a few Secretly Terrible Engineers over the past couple of years. One of those was hired before we had instituted any kind of standardized technical screen, another was senior enough that we decided to skip the technical screen (and regretted that decision later), and a third passed the technical screen but was unable to get anything done, in large part because he spent most of his time on Reddit and HN. That of course indicates that passing a technical screen is not a guarantee of success, but it does seem to be at least one good filter.

Our technical screen consists of 6 questions on a few different topics, and is designed to probe a variety of different areas. I consider it fine if someone fails one or two, as I don't expect someone to be strong in all areas; some people may be really good at actually coding, but not know what big-O notation is, or someone may be fresh out of college and so not have much hands on experience yet but if they do well at the algorithms and data structures questions it indicates they were paying attention and absorbing their classwork.

But people who don't know the big-O complexity of basic operations on basic data structures they use every day, and can't put together a coherent class hierarchy for modelling files and directories, and don't know how to interpret a system call that they see in a stacktrace, don't know what TCP is, and can't write a simple program on demand with access to Google, StackOverflow, in any language they want, using any tools they want, are definitely going to be more work to bring up to speed than they are going to be worth. And I've talked to people who have degrees in CS and several years worth of experience who have failed every one of these questions.

<comment><USER24> Mainly because a lot of the things you just listed are incredibly stupid requirements.

If I spent my life doing ruby sites that save basic data into a mysqldb, why does it matter whether I use sometching that takes 100,000 operations or 10,000 ones, when the web page still opens in 0.5 vs 0.51 seconds?

Or who gives a damn about system traces when I can put echo's in a PHP page and just view source?

Who gives a fuck about TCP when the browser abstracted that all away?

And when you say write a program, you clearly mean a console app, which again, unless you've written one, which junior programmers may never have done because someone else always wrote the helper & utility apps, it's pretty daunting the first time if you don't even know about main. Which suddenly makes it pretty easy. Imagine asking a front end developer to make a console app in their interview.

You do a particular type of programming. You seem to want to judge everyone else by your niche without understanding that a lot of the skills you list as essential are actually almost completely irrelevant to huge swathes of programmers. And they haven't learnt about them, because they don't need them.

<comment><USER25> They're really really not stupid requirements.

The poster you're replying to isn't narrowing to a niche, he/she is simply trying to catch a red flag. You're right to be concerned that there are many interviewers who will climb way down the ladder of abstraction to their own particular niche and then crucify a candidate. But this isn't one of them. The poster even explained that it was only really a negative if all were wrong. I use a similar process as a quick pre screen.

Sailing through all questions allows us to proceed at a relaxed pace. Having nothing to say for one or two questions tells me nothing (it could easily be a fault of my question rather than the candidate). But no coherent answer to any question? Red flag.

<comment><USER23> Exactly. I've had several candidates that I have passed who on the TCP question have said "I don't know, networking is not my strong point." That's great! Knowing when you don't know something and should just move in is a real strength.

As long as someone does fine on most of the rest of the questions, having one or two gaps in knowledge is not a problem, I can tell from the other questions that they'll be able to pick it up if they need it, or ask for help when they need it.

</comment></comment></comment></comment><comment><USER26> I think one thing the author fails to realize is how much worse it is to hire a terrible engineer than not hire a good engineer. I've seen a terrible hire cause more than $1M of damage in the year it took for him to get fired.

While I think that these sorts of people are rather rare within the population of engineers at large, they appear much more often in the interview process as they are more likely to need a job, and probably have to interview many more times before they find their way into a company.

That said, I do agree with the author that extremely deep technical interviews are also unreasonable. Variants of FizzBuzz are generally enough to weed out the terrible engineers and it's pretty hard to tell the good from the great until you've actually worked together.

<comment><USER3> > I've seen a terrible hire cause more than $1M of damage in the year it took > for him to get fired.

As I have said in these discussions before, that sounds like a process problem. What does it say about the competency of management and the maturity of processes if it took a year to figure this out? I don't think you can lay most, let alone all, of the blame on the engineer and the hiring decision.

<comment><USER26> It took a year for management to figure it out. It took much less time for his coworkers to figure it out. You're definitely right. "Blame" for the damage done falls mainly on management inaction.

I definitely learned a ton from that job.

</comment></comment></comment><comment><USER27> I've worked with secretly terrible engineers. I've seen _lots_ of code samples submitted by secretly terrible engineers. I've been told that putting asserts in the code is bad practice because it means that the code is making assumptions, and I've seen my co-workers exult because they were successfully able to change the simple implementation of an interface without having to change the client code. I've heard software project managers claim they'd never seen a project fail for technical reasons, and I've seen them openly promoting waterfall development. And if you look at the kind of abysmal nonsense that fills sites like w3schools and developerWorks, not to mention the questions on StackExchange, it's obvious that there's such a huge volume of Openly Terrible Engineers out there that they frequently don't know _any_ reasonably good engineers _at all_.

I've also had the privilege of working with a lot of really super awesome people. They didn't work at the same companies as the total incompetents, for the most part. And they weren't all geniuses. A lot of them were just regular schmoes who worked every day to get a little bit better.

In almost 20 years in the field, I've also actually _been_ the "secretly terrible engineer" — although I've been pretty successful in most of my jobs, I've also had a couple where I just stunk.

Different people do well in different environments, and software development is a wide enough field that it has a wide variety of environments in it.

</comment><comment><USER28> One solution to all of this is for the applicant to do a few things to avoid being confused for a terrible engineer. The last time I looked for a job, more and more companies were asking for an engineering design portfolio. Instead of waiting for the employer to ask you to talk intelligently about things you haven't learned yet, show up to the interview with a portfolio of things you can discuss on a detailed level for hours on end.

I've only been working professionally for a little under 4 years, but I've encountered a handful of terrible engineers - engineers who only know one solution and apply it to every problem that presents itself, very smart, technical people who know enough to hack something together and leave the difficult, last 20% for other people to solve, etc.

Another issue, especially in larger companies, is you have to allow a bad engineer to fail in order to justify firing them. In a fast paced environment, sometimes you can't allow a project to fail simply to provide cause to fire an engineer. And even after the failure, HR will require you to implement a performance improvement plan, etc.

<comment><USER18> The problem with the portfolio approach is that many incompetent engineers can easily point to code that they "wrote." Often it was part of a larger team carrying them, but sometimes they wholesale copy it.

A similar problem applies to pure project interviews: the total incompetents are also the ones most likely to get someone else to "help" them with it.

<comment><USER28> Yep, there also needs to be a way to detect bat-boy syndrome (where the team goes to the world series, but the guy you interviewed was just there to lug the equipment around).

I've always heard that you learn more in an hour of playing(as in a sport) with someone than you will in ten hours of conversation. I like the idea of being paired with an engineer to solve a problem because it let's someone see how you think, what your process is, and, most importantly, how you learn.

</comment></comment></comment><comment><USER29> I think the article starts to highlight the real issue, when it compares with other industries, but then ducks out at the last moment. So I will try my best to fill in:

In all industries, in all professions, there are a range of abilities for those working within it. From the truly gifted, to the hard-working reliable folk who mostly deliver consistently, to those who need support and guidance to deliver well consistently, to those who deliver sometimes, to those who frankly cannot and will not deliver despite support time and guidance.

I have met incompetent doctors, unreliable engineers, lawyers you would not trust to compile a shopping list, and programmers you would not ask to develop any kind of program beyond hello world.

I have also met people I could always learn from, and they too remain fixed on the idea they too are always learning, improving, on a knowledge and experience journey, without a fixed endpoint.

A final point - no one is truly useless, you just cannot find a good match for their skills and experience within your team at that point in time.

</comment><comment><USER30> The article started ranting, so I stopped reading it after getting through about two thirds of it. But one difference between software and the other mentioned professions is that software developers can earn $140K just by _doing_ , by performing. And they can often start soon out of high school. And it doesn't matter where they learned it. It's about doing.

I don't know much about dance, but maybe software engineers should be compared to dancers, and the technical interview should be compared with an audition. Actors and dancers still audition for roles, years after they have made it. And the audition is still as far removed from day-to-day work as a technical interview is from the job. I guess the reason that it's done is because the work is like a performance.

</comment><comment><USER31> The article spends most of its time criticizing interview techniques that focus on knowledge of particular facts, which is fine - I agree that's generally not a good predictor of job success. But somehow the article concludes that since bad interviews can exclude good candidates, there's no such thing as a truly bad candidates.

The existence of bad interview techniques at some companies doesn't preclude the simultaneous existence of bad candidates in the market.

Yes, good people can fall through the cracks, and otherwise-talented people may not be good at being interviewed. Those are unfortunate realities that you should be aware of and vigilant about if you're involved in hiring. But there are also bad candidates out there, and they're capable of doing a huge amount of damage (anyone who has worked on even a medium-sized engineering team can verify this) so the ugly truth is that being conservative with hiring makes a lot of sense.

<comment><USER32> Why is asking about particular facts considered a reliable way of finding bad candidates?

<comment><USER33> It is not. That's the point of the comment you're replying to.

There exist _good_ interview questions, where you give lots of facts to the candidate and make it clear that they can ask if they don't remember the order of arguments to reduce(). (In fact, a good way to put them at ease is to admit that _you_ don't remember either, and are just looking up the documentation :-P )

But if, given those bare facts, they can't write a legible and correct binary search even over multiple iterations, or reason about O() complexity of an algorithm they either just implemented, or just _came up with_ , they are probably an STE.

In my experience, these people fall into one of two categories: new graduates who just barely scraped through their college classes, and people misrepresenting their past jobs in QA or product management as programming experience. (That isn't to say that non-CS-majors shifting into coding can't be great engineers - I know several! But when interviewing one, you can't make the assumption of basic competence, and it's a red flag if they play up their non-programming work rather than talk about actual coding experience/studies.)

</comment></comment></comment><comment><USER34> This is bizarre to me. Yeah, I've worked on teams with people who couldn't ship code, and they got fired. But I'm looking for work now. Let me tell you what it's like. There are companies who provide automated coding tests that require you to pull out bizarre algorithms that I haven't needed in 15+ years of shipping code and creating MM's of value for employers.

After weeks of searching, I'm finally at a second-stage interview with a company where they intend to hand me a spec, put me in a room, and see if I can come out a few hours later with a functioning prototype. And it's a relief; that's a sane test. Can I produce or not?

</comment><comment><USER35> The really horrifying thing about FizzBuzz is that it actually has useful power as a screening tool. No, I don't know how the hell these people accumulated years on their CV while being literally unable to even approximately code a FizzBuzz. But they're out there.

(I suspect Joel Spolsky's theory that it's the same 100 terrible guys applying for _all_ the jobs.)

It's the same for sysadmins, by the way. We just went through a hiring round for a good Windows sysadmin. (Us Unix guys could all do Windows to pointy- click level, but needed someone who knew its evil little ways when something went _subtly_ wrong.) Holy crap, you would not believe how many clearly useless bastards have literally twenty years as a Windows admin on their CV. We got someone who's great (and picked up the Linux side in short order), but it was slightly trepidatious.

<comment><USER36> Or perhaps they have learned the solution to FizzBuzz, and simply don't code well under stress.

<comment><USER37> FizzBuzz has to be the simplest coding exercise out there after hello world. No matter how much pressure you feel it can't be hard to figure that out?

<comment><USER38> I believe this should cover all bases: [https://bitbucket.org/iopq/fizzbuzz- in-rust](https://bitbucket.org/iopq/fizzbuzz-in-rust)

<comment><USER39> Or if that fails: [https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...](https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition)

</comment></comment></comment></comment></comment><comment><USER40> I was talking to a team a couple of years ago. This team had a bad reputation at the organization, and I was supposed to come help them.

So I did a day of light training. Then I offered some free books -- with the caveat that they email or ask me for them.

Nobody asked for the books. Out of 20 folks, 2 of them bought the books (instead of getting them for free). They didn't want the rest of the team to know they were interested!

I firmly believe two things: 1) just about anybody can become a programmer given the right environment, and 2) Due to social issues, teams get "out of whack" and suck really big time. And when #2 happens, the other programmers always blame it on technical skills.

At a recent conference, I saw a guy talk about "mob programming". Mob programming is where you take the entire team, say 3-7 guys, and work on one story at a time. There's one terminal. One guy is typing and everybody else is planning and navigating.

He said it created a huge training opportunity for everybody because everybody was involved in every little detail all at once. People got the chance to compare notes. Poor programmers got better. Good programmers learned cool stuff from each other.

But the really interesting part was when he described doing this _in teams where not everybody was a programmer_. He said out of several experiments, in every case within a few hours the noobs were picking up how to program in that language. Within a week they were able to actively and helpfully participate along with everybody else. It wasn't just that weak programmers got better, _it was that most anybody could learn how to program_.

I don't think most people in the industry are ready to hear that.

</comment><comment><USER41> No question in my mind that completely inept engineers are everywhere. It's mind numbing how many people will respond to a opening for an experienced coder and literally cannot code in any capacity.

In a previous life we were hiring C# WinForms guys, and I would always ask to code "Explorer". Some people couldn't get past creating the solution in Visual Studio, others couldn't figure out how to get the directory listing at C:\, but some got _remarkably_ far along in just an hour or so, with directly & file listings, navigation up/down the tree, context menus, rename, copy/paste, etc..

I never ask trick questions, I just come up with cute apps. I think my new interview question forever henceforth will be to code and launch "Magic", I'll be back when it's time to get lunch, and help yourself to the espresso. Write it in whatever language you want, using whatever tools you want, on your laptop, with a full internet connection. If you want external keyboard and monitors, please use them.

The only rule is you can't claim someone else's solution as yours. You _can_ use Stackoverflow, or any other resource you want to build up the parts, but you have to cite any code which carries a license.

Find a task which you can describe at 30,000 ft in 2 or 3 sentences, then spend 5 minutes sketching out ideas (not code!) on the whiteboard of what the components are and how they fit together. Then, probably best to leave them to it and not stare over their shoulder making them nervous.

</comment><comment><USER42> Quite a few times, after getting a technical screen, the interviewer's attitude was "You loser! Why are you wasting my time interviewing here?" But I know that I'm really productive and really know my stuff.

When my employer was interviewing, the two best candidates (by my analysis) failed their technical screening.

I don't see any easy solution.

It also seems weird that employers complain of a talent shortage, but they always are looking for every little excuse to reject someone.

</comment><comment><USER43> You know those college groups and side projects where there was a group of people and then only a couple or a few actually did anything and the rest attached on for the easy layup? Yep those people end up doing the same thing in the workplace and probably in life.

If you were the deliverer in the college group or project then you will have the same thing in the workplace. Usually people who don't want to be doing it at the time, they might be good but uninterested. I imagine it is extremely unsatisfying to just sit around and not contribute. I work to create and ship, otherwise why do it?

A bad part of this is it isn't always the shippers and doers that get the credit or the notice either, same people like this jump up and take credit to justify their contributions.

Some people go full Costanza.

<comment><USER44> Ugh, you're right, and this is exactly why I _hated_ group projects in school. 4-6 people taking credit for the work of 1-2, and everyone gets the same grade.

</comment></comment><comment><USER45> Pair the candidate with an interviewing engineer, give them an hour or two to solve a problem as a team. The interviewer isn't an adversary; their job is to assist the candidate like they would if they were working on a real problem.

Repeat this process if necessary.

Get everyone together and talk about past projects the candidate has worked on. Have the interviewers evaluate the candidate, and make your decision.

You know whether the candidate can code, and you've removed the adversarial nature and unnecessary stress from the interview process. Most importantly, you got to see them work in a much less artificial environment that's closer to what they'll be doing day to day.

<comment><USER46> I'd be over-the-moon thrilled to interview at a company that does this. Any recommendations for this front-end dev in California?

</comment></comment><comment><USER47> > _Lawyers and doctors are asked trivial questions just a handful of times in > their careers during their bar examinations and boards._

I get the very real sense that this person has never sat a law exam.

A law exam is based on applying case law to a set of facts, which corresponds to the day-to-day work of millions of lawyers. What the author calls "trivia" is literally _the law_.

<comment><USER36> I think trivial questions meant FizzBuzz and count the A's.

What's the legal equivalent of that?

<comment><USER47> In your introductory course you might be asked what precedent is, but after that it's cases, statutes and IRAC: Issues, Rules, Application and Conclusion.

</comment></comment></comment><comment><USER48> I think the biggest issue with this article is that most places aren't trying to hire people who aren't bad, they're trying to hire people that are _good_. You might use fizzbuzz as a weed-out question, but then you have to determine whether the person is good or not. I don't think there's a pervasive fear that terrible engineers will accidentally be hired. There's a desire to weed those people out and then sift through what's left for the best.

</comment><comment><USER49> This article is incorrect from beginning to end. As a simple counterpoint to this idea that "I have never once heard a firm talk about the idiots lurking in their own offices"

Here is the well documented _policy_ held by major (not just tech companies mind you) firms to fire the bottom 10% of their employees. [http://en.wikipedia.org/wiki/Vitality_curve](http://en.wikipedia.org/wiki/Vitality_curve)

By the way a form of that is used at Microsoft and Google, probably others as well, but the idea that Silicon Valley and Computer Programming are the only place where people are on the look out for "Secretly Terrible Engineers" is absurd, its just as absurd as the comments I am reading where no one has ever worked with one of them. As a hiring manager I turn away over 95% of candidates and even with a very selective hiring process you get people we need to let go because they can't perform at the level I expect them to even after passing a rigorous interview process, so to say they don't exist is stupid, its like claiming that no one ever gets fired for not performing their job well enough.

</comment><comment><USER50> 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 individual aptitude that only a chosen few can succeed at, and must be protected from the pretenders to the throne. /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.

And if hiring is really the solution to all our problems, then, well, what do we do with all these idiots standing around here?

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

</comment><comment><USER51> Something getting lost in the responses here is the "stress" factor of these interviews. When encountering a difficult architectural or algorithm decision, experience has taught me to develop slowly, prototype often, investigate previous work, and even step away from the issue. Meanwhile, engineering interviews require you to code immediately, in isolation, and then be judged on the first solution you crap out of your brain.

In a recent interview, my solution to a question was bad, I knew it was bad, and I informed my interviewees it was bad. It was difficult for me to come up with other solutions on the spot under pressure of judging eyes and limited time. Immediately after getting off the phone I was able to assess better ways to approach and solve the problem, but too late, those 45 minutes were more important to them than my many years of provable, directly related experience.

</comment><comment><USER52> I was on the interviewer side of the developer interview equation once. This guy came in, mid-40s, claimed to have a long and storied career designing radar imaging systems and the like. Even claimed to have a patent to his name.

He was a fucking idiot.

We gave him our standard simple programming task, which requires a trivial amount of quasi-low-level byte-banging in C(++). But even a fresh-out-of- college kid who only knew Java could get it with a bit of prompting and a few hints.

This guy came nowhere near a workable solution, but he could generate mountains of chatter and BS about what pattern to use and such.

I had never encountered such a flagrant BS artist trying to land a developer role wver in my life. I doubt that most "secretly terrible engineers" even approach his level. But the experience was a teachable one.

</comment><comment><USER53> Elon Musk's rule works pretty good for finding a "terrible engineer"

"How Elon Musk Can Tell If Job Applicants Are Lying About Their Experience"

[http://www.businessinsider.com/elon-musk-job-interview- rule-...](http://www.businessinsider.com/elon-musk-job-interview-rule-2013-12)

</comment><comment><USER54> Similar issues arise in finance.

I started as a stock analyst in 1981 at a fairly elite firm (PaineWebber, usually top 5 and always top 10 in the equity research rankings). We didn't get computers and spreadsheets -- Visicalc! -- until I'd been there a few months.

After a while I started publishing annual growth rates, based on formulas like (EndValue/StartValue) ^ (1/5) - 1, formatted in percent. Multiple colleagues asked me to teach them this amazing trick.

And by the way -- when writing this comment, I made a mistake in the formula above until I rechecked my work. :)

</comment><comment><USER55> What a terrible article! Writing code is not about good vs. bad, incompetent vs. incompetent, great vs. garbage. It's about communication between people.

The best programmers I've known are never happy with their work. We ALL write terrible code! Anyone who says different is lying.

Good coders are those who welcome critique, who push themselves through self- set goals and challenges. My fav quote from Dan Kubb is "if I'm not embarrassed by code I wrote 6 months ago, I'm not pushing myself hard enough".

<comment><USER56> And then some day you'll have to visit a psychotherapist. Not being happy is destructive, being happy and greedy in your happiness is not. Attain a level of expertise where you can reliably predict task durations and then go lead a team to teach every team member the same. Then be a CTO. Then the world will be a calm, happy and steadily progressing place.

</comment></comment><comment><USER57> I think one thing that really bugs me about this article (and a lot of the stuff coming out of the valley in general) is the unqualified use of "engineer" when describing developers. Most software development seems to lack the rigors of what (atleast used to) fall under the domain of engineering (EE, ME, ChemE, etc.); I also don't think the culture is this antagonistic in other engineering fields, especially where people are licensed as professional engineers (ME, Civil, etc.).

</comment><comment><USER58> Side point: The author throughout nearly all of the article uses engineer (without any further qualification) and programmer interchangeably. A vast range of engineering has nothing to do with the design of software, and engineering is not programming.

<comment><USER59> It's an interesting point, since I don't know how much other engineering fields are beset with this problem. The article features a photo of a collapsed bridge, but obviously its topic is software. Do civil or aerospace engineering firms have the same problem of incompetent coworkers who manage to pass all their interviewing hurdles? It seems hard to imagine -- I don't know how I'd fake the math on static and dynamic loads without actually knowing what I was doing. Why is software so different, lacking basic shared and provable prerequisite skills?

<comment><USER60> "Why is software so different, lacking basic shared and provable prerequisite skills?"

It shouldn't be; I think we generally don't have enough people that yet recognize this as a Real Problem(tm), and therefore don't know how to do good filtering/interviewing up front. I think it may be another generation or two before there's really enough pushback to start demanding the same level of scrutiny other industries may have.

Now, a bad doctor, lawyer, engineer, etc might slip through the cracks now and then, but there's pretty strong proof that at one point they did Know Something (tm) about their field, more through professional licensing than standard higher ed, for example, but it was there.

I have so little faith in the value of most higher-ed degrees as higher-ed seems primarily profit and ratings driven, vs capabilities driven. Professional orgs like bar associations actually have some economic incentives to keep people _out_ of practicing law. Universities seem to have no incentive to fail people out, and every incentive to continue grade inflation.

<comment><USER61> > Universities seem to have no incentive to fail people out, and every > incentive to continue grade inflation.

Ostensibly, the idea is that if you don't weed out the idiots, you are going to end up with people with degrees from your university who are garbage, and this hurts your brand. You see this happening with for-profit colleges, where grade inflation is particularly egregious. "Well, we've given a bunch of DeVry grads a chance, and they've all done terribly. We're not going to be considering DeVry grads anymore unless they can really, really prove that they're any good."

This should, in turn, get back to prospective students, who won't go to a college if it can't get them a job.

Unfortunately, you're now at three steps that are pretty opaque and difficult to measure, and the rewards for lowering standards are immediate and vast.

<comment><USER60> > You see this happening with for-profit colleges, where grade inflation is > particularly egregious

I see it happening with people all sorts of colleges and universities. It's gotten to the point where if/when I meet a young graduate who has good communication and thinking skills, I consider them an anomaly, or suspect strongly that they already had these skills before college.

</comment></comment></comment></comment></comment><comment><USER37> We send out a coding test to candidates that pass a phone screening. We provide a template file and a run file that contains tests.

I'd say 1/3 of the entries we receive (from people that have passed a semi- technical phone screening!) return an answer along the lines of 'if input = test1, return answer1' and another 1/3, who submit code that is also 'fakes' the correct results, they just pad it out with a bunch of filler code to make it look like they'd done more.

We rate each entry out of 10, its insanely frustrating how many 0's I had out.

I assume that they assume we just check the tests pass and thats that. (Do any companies do this without checking the code? The sheer amount of people that try suggest it must work sometimes!)

<comment><USER62> Presumably you also have other tests that you run the code on too, that are not sent to the candidates right? That would save some time, say if the code passes all 10 tests sent to the person, and fails all 20 tests that you keep for yourself, then that person's resume would go in the trashbin with little time wasted.

</comment></comment><comment><USER63> Where I work we have a "programming test". You get a simple problem, two hours, your own laptop (or one provided to you, as you like), full access to the internet, and a room by yourself.

The problems are doable in about 1/2 the time.

Still not quite like a real situation where you bounce ideas off other folks, take a break and go for a walk when you're stuck, etc, but it's closer than the whiteboard coding nonesense.

But I have seen folks coming highly recommended with "architect potential", "top of the heap", etc, who turn out to be 100% useless. And I mean useless as in "it's more work overall when they work on something than if they wouldn't have worked on it in the first place".

<comment><USER64> > I have seen folks coming highly recommended

Who did recommend those useless candidates to you? A recruiter, perhaps? Read this horror story: [http://bostik.iki.fi/aivoituksia/pages/recruiter- anxiety.htm...](http://bostik.iki.fi/aivoituksia/pages/recruiter-anxiety.html)

 _The good developers generally have no trouble finding jobs, and therefore don 't need recruiters' help. With the best and the brightest taken off the pool, the recruiters are mostly left with merely the mediocre and the bad ones. This in turn has collateral effects: any developer coming in via a recruiter already carries the stigma of "not good enough to find job on their own"._

</comment></comment><comment><USER65> > Lawyers and doctors are asked trivial questions just a handful of times in > their careers during their bar examinations and boards.

Of course, this obviously means there are examinations and governing boards that certify laywers and doctors as fit to practice. I doubt most people in the industry would prefer that we start moving towards that.

Or maybe not. I dunno. Those of us who went through traditional CS programs would certainly benefit from such a system greatly. But the lack of formal entry barriers is part of what makes the industry fantastic, and perhaps the very fluid and sometimes irritating interview process is just part of keeping those entry barriers away from tech.

<comment><USER66> Ah, but what about Official Scrum Master Certification panels?

</comment></comment><comment><USER67> I've been seeing the same basic topic come to the top of hacker news over and over. I thought the with the advent of GitHub, Stack Overflow and easily sharable web and app projects that this would make vetting software developers easier. Are these resources not being utilized at all in the hiring process? Am I to believe that a software developer with several years of professional experience, references, and some sort of work portfolio can't code at all? I don't get it.

<comment><USER13> Many, many dev candidates do not have a Github account with any code on it, nor do they have an SO account with any answers on it. And past work often belongs to the employer (and was written by a team anyway), so.

If you want to say "don't hire those people," you're being far more restrictive than those who want to do fizzbuzz-style weed outs.

<comment><USER68> Github-centric candidate filtering is _great_ for the tiny percentage of programmers who get paid to work on open source, and _terrible_ for the much larger percentage who can't write open source code _even on their own time_ without risking a lawsuit from their employer. Only way to fix that's unionization or getting an awful lot of laws passed in a an awful lot of states (for US devs, anyway), thanks to employer/employee power imbalances and incentives to defect from any strictly voluntary resistance movement.

<comment><USER69> Wow most programmers aren't allowed to have any sort of hobby involving programming without risking a lawsuit from their employer? That seems pretty crazy, I'm surprised places like California permit that.

Any ideas what companies tend to have such onerous conditions in their employment contracts? I've never seen something similar but I've only ever worked for smaller (less than 500 people) companies.

<comment><USER70> It's the default state in English and American Labour law hint on one of the key legal acts is named "Masters and Servants Acts"

And this is from some one I worked with was a GC and a lawyer.

<comment><USER69> That doesn't seem right, at least in America. All companies I've worked for have required me to sign an agreement giving them ownership over any work or inventions produced using their technology or on their time.

If that was the default state why would everyone require those too?

<comment><USER70> Lawyers covering their asses mostly and it also makes it much harder to try and fight any disputes.

America is a tiny bit more liberal than the UK but of course most people can't afford the lawyers to dispute.

</comment></comment></comment></comment></comment></comment></comment><comment><USER71> _We need to move beyond the algorithm bravado to engage more fundamentally with the craft. If people are wired for engineering logic and have programmed in some capacity in the past, they almost certainly can get up to speed in any other part of the field. Let them learn, or even better, help them learn._

What you want are people who are able to perceive the functioning of the entire group, and act in ways that optimize _that_. Bands of highly talented musical savants that don't like each other and don't "gel" can still sound worse than a group of friends with "pretty good" talent who have become really good at playing with each other.

After having interviewed and taught, I now realize that interviewing and teaching are involved and deep disciplines, that take significant insight in order to do them well. (Including some personal insight.) Most programmers haven't been concentrating in the areas that would make them good at either. In fact, my experience suggests to me that a great many programmers use the occasions of teaching and interviewing to vent aggression against "the stupids" of this world.

</comment><comment><USER72> I'll pile in here to note that I worked with someone back in in junior year of college on a group project. This person insisted that our entire project (which was quite large) needed exactly four classes as we identified four types of users for our classes. "J., we also discussed how Smith over here was going to build a database access layer, which means at least one more class. What you are saying does not make any sense." He refused to see reason. Not only did he graduate, but he is now overseeing a team of engineers at a corporation where he was first an engineer for 3 years. I pity them.

I also worked with an individual who could not code to save his life and had to "work with" (read: copy) a friend to complete even the simplest assignments. This person went on to work for a major US financial institution. In fairness, he only works in IT, but I am sure his software incompetencies can't be good for the company.

</comment><comment><USER73> Most fields have reached the right conclusion. Colleges do not adequately prepare candidates for work. If tech employers never train or improve their employees and the employees don't take responsibility outside of work, then it's possible for starting programmers to be passed from job to job without ever learning core concepts.

There needs to be an understanding that a Computer Science degree often does not teach job skills and that addressing the problem early with extra reading or training is critical. There is a tendency for people to start CS majors who have no abilities or interest in the subject other than liking the money involved.

When I was in college, I took CS electives as an English major undergrad and routinely had CS graduate students attempting to cheat off of me during exams. Anecdotally, a lot of tech leads seem dumbfounded by the results of programming candidates with CS versus unrelated degrees.

<comment><USER74> > Anecdotally, a lot of tech leads seem dumbfounded by the results of > programming candidates with CS versus unrelated degrees.

Are you saying people with degrees other than CS tend to be better programmers?

</comment></comment><comment><USER75> I think that article makes a number of faulty assumptions, but one stuck out to me:

>We need to start with the assumption that engineers are smart learners eager to know more about their craft

I have encountered many people in the field that do not support this assumption. Code reviews for these people always end up with them defensive - you will see a lot of remarks along the lines of, "isn't it good enough though?", "it works with the one input I tried", "yeah that would be better but that would require me to do more work to change something, vs just hit merge on the pull request", etc.

You can try and help improve their workflow, give tips, point out faster or better ways of doing something, only to come by to help them 2 weeks later and see them still stubbornly doing something the slow way.

They treat code they don't write as a black box, or "owned" by the person that wrote it. You will encounter, "Hey, I was having a problem with X, and I traced it down to this function in the Foo subsystem. I think I heard you wrote the Foo subsystem. Could you take a look at this?" When you try to help, you realize they navigated to this point and then didn't spend 1 minute trying to read the code and see what's going on. You might take time and give a good overview of it, how it works, offer to answer further questions, etc. It goes in one ear, out the other. Three days later the exact same question comes up.

I've seen a programmer get thrust into the node.js world without prior experience. I offered a few suggestions for learning resources, and offered to loan a book. He said, "Yeah, I really try not to read books like that or spend that kinda time outside the office. I'll figure it out."

I could go on and on with anecdotes, but I think the reality is there are people who are very into the craft, and WILL be quick learners (of that which they don't already know), and there are plenty that don't. For those of us that do strive to improve and get better, working with the former is a terrible demotivator.

A step further, I think that the former group will slowly attribute to technical debt, or just over time make your code base harder to work with. You can't micromanage forever, and having to harp on the same things time and time again in code reviews is draining for both parties. Eventually you start giving in, and letting sub-standard work through, because to do otherwise will make you seem like a nagger, nit-picker, etc. Then one day you have to edit something they touched, and your own task takes 10 times longer due to tons of coupling, faulty assumptions, things they didn't bother to learn about how the overall component works, etc.

The "hazing" style of interview surely does suck, and I myself don't go for standard library trivia, or ask algorithm questions that would never come up on the job. But more and more, I feel that they are used throughout the valley for lack of a better way to defend against someone joining the team that's going to be a net negative. I think the thought might be that it's extremely hard to detect the person that can't be bothered to read through the code base, and figure out how things work a little before giving up and asking someone else to hold there hand - yet if one can make it through one of these tough interviews, there's a higher chance they aren't that person.

Another aspect is that I feel like once people get IN in tech, few companies are willing to make corrections. Someone can consistently write bugs, or submit code to the repo it was clear they didn't even test against the base cases of input/usage, give estimates that are WAY long for simple tasks, not pay attention in meetings, etc - but many companies are afraid to fire, or give harsh feedback. From what I've read, Netflix is one company that does not seem to operate this way.

Perhaps we'd all be more trusting in our interviews if we didn't know that the false positive would be so hard to correct.

<comment><USER10> _When you try to help, you realize they navigated to this point and then didn 't spend 1 minute trying to read the code and see what's going on._

I'll take the other side here...

I track my problem to a particular part of a submodule. The person that owns it didn't document it well, didn't write an overview of how the thing works, and generally has made "just reading the code" a poor and error-prone substitute for asking them directly about context they've chosen not to share with anyone else.

The person becomes annoyed at my continued questioning instead of "reading the code", and eventually complains about my lack of motivation. The code, meanwhile, never gets fixed, and is a ticking timebomb of technical debt.

Whose fault is this? Mine for not "reading the code" and breaking encapsulation, and changing my code to match undocumented behavior? Or the other person's, for failing to behave professionally like an engineer and identify that they are knowledge-hoarding?

Who's to say, really. It doesn't matter...I've got another gig lined up.

<comment><USER75> I think what you described exists, it's just not what I was referring to. Quite the opposite, I've seen this happen when there WAS very clear documentation, possibly a link to a wiki or readme file in a comment that points to an overview, and yet the person clearly hadn't bothered to read any of it.

</comment></comment></comment><comment><USER76> There is a large pool of incompetent developers going from one job interview to another. Finding the decent developers amongst this herd is painful.

It's not that there are loads of awful developers lurking in companies (although there are a few). It's that awful developers pollute the waters when hiring.

</comment><comment><USER77> Sure, you can ask companies to give their new hires books to read and pointers on what to learn. However, it's even better if the new hires _already_ read books to improve their craft. On their own initiative. There is still plenty of stuff to learn when you start at a new place, the new codebase for example (and possible the domain). So it is good if you are already up to speed on the programming part.

This is an example of the three dimensions of programmer knowledge: Programming, Domain and Codebase. I recently wrote more about this in "Programmer Knowledge" here: [http://henrikwarne.com/2014/12/15/programmer- knowledge/](http://henrikwarne.com/2014/12/15/programmer-knowledge/)

</comment><comment><USER78> It's probably a systematic issue with how programming work is paid for. There are lots of 'software companies', but there are orders of magnitude more contracting and consulting and IT companies - companies that charge work based on what some sales guy can get through the front door. After that point, it's about filling in seats with whomever can charge the most.

Software companies need people who can code, as well as do other things. Other types of companies that do 'IT' need people who can look good in a seat. This causes lots of incompetent people to get jobs for many years.

</comment><comment><USER79> The idea that there are lots of great engineers out there who just need mentoring and guidance to excel sounds great, but the reality of the industry seems to be that people dont stay in one place very long.

I think there is an opportunity there, but you would need to use contracts or something to make sure the time and effort you are putting into making this person great isnt just a gift you are giving to the company they move to next year. Also, I dont think startups are at all well placed to do this, given their time pressures. Google, Apple and Facebook could totally be doing this though.

</comment><comment><USER80> I think it is far more useful to build a process for software engineering that continually reviews itself and makes things better. A fizzBuzz test is useful to figure out how a person approaches a coding problem and something like that should be part of hiring new developers, but most whiteboard interviews take the whole thing way too far and approach it as an exam that you have to pass.

Fact is that everyone has their 10X moments and their doldrums. Only by working on processes and team building, can you create an environment that lifts your engineers to the 10X level more often.

</comment><comment><USER81> I read this article, and I think to myself: "My goodness. This sounds just like graduate school."

In CS grad school, impostor syndrome is everywhere. Nobody talks about it. Everyone -- from the professors to the masters students -- is _strongly_ affected by it.

The more you advance, the more taboo it is to talk about it, even though it doesn't go away. I understand the successful people just "get used to it" after a while.

Or maybe it's just me. If it is, wouldn't that be a certain kind of delicious irony?

</comment><comment><USER82> For starters we shouldn't be allowed to run around calling ourselves "Engineers" just because we feel like it.

Secretly Terrible Doctor exposed: Not actually a Doctor!

</comment><comment><USER83> > Lawyers and doctors are asked trivial questions just a handful of times in > their careers during their bar examinations and boards.

True, but they are also asked lots of tough questions when they go to interview for jobs. It's not like you walk into a law firm, say "I passed the bar", and they hire you. Comparing the legal/medical licensing requirements to the software engineer interview process is apples-and-oranges.

</comment><comment><USER84> I'm not sure I've ever interviewed anybody who can't program _at all_ , but a large number of people I interview are shockingly bad.

My go-to question to detect this is to remove the odd numbers from a dynamic array of integers in-place, in their language of choice.

The ideal candidate writes an O(n) function, a less ideal (but still good) candidate writes an O(n^2) function, and if they're struggling I say that they can return copy of the array with the odds removed (this is worse, but they could easily make up for it later).

Not only can most candidates not do any of these, but most _don 't even know how to tell if a number is odd_. I had one suggest that maybe he needed a loop (I don't know what he was planning, because immediately I told him he didn't need a loop to know if a number is odd).

This is for a game programming position, and most of these are people who have (or claim to have) programmed games. Every game has a loop like this somewhere. Most have many! I feel like all I do is iterate over arrays and remove things from them, and yet, this is one of those questions that over 95% of people don't get. It boggles my mind.

<comment><USER62> How is making a returning a new dynamic array worse than doing a O(n^2) implementation? The former would be perfectly fine in production, the slight increase in memory use is negligible, the n^2 solution would lead to me wanting to fire said person.

Edit:

In addition if the O(n) in place solution that I am thinking of is the same as what you are thinking of, the downside is that the remaining even elements do not remain in the same order. So overall it is hard to imagine ever wanting to use this solution over the standard create new array with just the even elements.

<comment><USER85> You can easily make an O(n) solution without reordering them by using two pointers; one to read numbers and the other to keep track of where to put the next even number.

</comment></comment></comment><comment><USER86> I can think of one that I worked with briefly, but not at my current company.

Ten years ago, today's interviewing style wasn't standard and we saw them more. They seem pretty rare today, so perhaps we should be focusing on other problems in the interview process rather than fighting the last war?

</comment><comment><USER87> Reminds me of another article:

Do Tech employers want too much from Candidates?

[http://news.dice.com/2015/03/09/do-employers-want-too- much-f...](http://news.dice.com/2015/03/09/do-employers-want-too-much-from- candidates/)

</comment><comment><USER88> Some percentage of the population are incompetent, so they end up in _every_ business in _every_ field, _everywhere_ on the planet. In other words, it's reality. Why does it still surprise people?

</comment><comment> mark-r This needs to be highlighted:

> "We expect every employee to be ready on day one." What a scary proposition! > Even McDonalds doesn't expect its burger flippers to be ready from day one.

There's no other explanation for the buzzword bingo.

</comment><comment><USER89> Rather than working against the interviewer I work with them. Rather than picking a pitiful problem I pick real ones. The only way to know who you want to work with is to work with them.

</comment><comment><USER90> Engineers have engineering degrees. Programmers are programmers. I have gone to school for, and worked as, both. They are two different worlds.

<comment><USER91> More succinctly: there should be no term "software engineer", unless people need certifications to become them, and face legal consequences when their engineering product breaks and kills people.

<comment><USER64> Okay, but real engineers can rely on the quality of their building materials, like mortar, brick, concrete and iron, with constant quality through decades or even hundreds of years.

Contrast that with the building blocks the 'software engineer' has to work with. Microsoft might upgrade some DLLs your product depends on, overnight. Will your product still work? Your application probably relies on components written by others. Are they infallible? Can you even inspect the components for defects?

I sometimes have the idea that software is built upon quicksand, and the building blocks can and probably will change before the project is completed.

<comment><USER91> I don't think real engineers can rely on the quality of their building materials. They do calculations to specify what quality of building materials and assembly is sufficient to surpass a safety threshold, then contractors use the specs are used to procure materials and assemble to meet the threshold.

Real problems occur when an engineers specifies a particular quality and lower quality is used. Or the engineer designs for a set of conditions, and that set is exceeded.

</comment></comment></comment></comment><comment><USER92> I wonder what this guy would have thought about Dustin Moskovitz when he was learning to code while launching FB in the early days...

</comment><comment><USER93> I think technical interviews will be obsolete in the future, your technical competence will be evaluated with GitHub or other public projects. So the interviews will be only about culture fit. I don't know if I will ever be in a position to hire anyone or even if I'll ever work as a programmer, but this is how I would interview. Send me a link to your GitHub, if I like what I see, I want to know if we would get along well, if we do your hired.

<comment><USER94> You're effectively eliminating 99% of your potential candidates then, as most developers do not do public open source work, including many talented ones. I can't imagine any sane company doing this, yet there are some that do indeed.

<comment><USER70> And in Anglo Saxon legal system code you do at work belongs to your employer and so possibly does anything related to your job you do out of work.

I would be breaking my contact with my employer if at an interview I showed you for example the Ml code I wrote to optimise our clients Ad words Campaigns.

</comment></comment></comment><comment><USER95> My heart goes out to the author and is someone I will dub the "Harvey Milk" of the computer software industry.

</comment><comment><USER87> Honestly, I did not get the gist of the article. I am combing through the comments to understand more.

</comment><comment><USER96> In no way is it true that the CA bar exam is an exercise in "trivial questions."

</comment><comment><USER97> There's too many egos, creative flakes and the alike for this to be ever called a stable work environment/career. Especially in the agency world!

Just speaking from my experiences, where I was given trials and then told I rock, then many months later being let go because we no longer clicked and or my side projects hurt their egos.

For me this field and my side projects has been soul crushing!

 __* Loved if developers /designers could be apart of a union, one that provided a shield from all the bullcrap noted above. Thus, providing better job security and life/work balance.

</comment><comment><USER98> There are two separate points here. One is the false-positive problem: people whose social skills and connections get them a series of good jobs despite a lack of merit. And even in companies like Google those people can make $500k and up if they become managers, PMs, or non-programming celebrity engineers whose code sucks but who are good at making executive types (who value confidence over ability, because they can judge the former) listen to them. The other problem raised is the false-negative rate that comes from finicky and stressful (for some; I always liked hard technical interviews) interview tactics, due to our internalized low status.

These problems may be related but they're superficially opposite and this should probably be two separate essays. One about our industry's severe false positive problem (especially in management and PM roles) and another about why our extreme but mostly cosmetic selectivity (doesn't know MongoDB? Worked at Oracle? Forty-seven? No hire!) is so stupidly ineffective.

</comment><comment><USER94> "If people are wired for engineering logic and have programmed in some capacity in the past, they almost certainly can get up to speed in any other part of the field. Let them learn, or even better, help them learn."

I couldn't agree more with this and the article in general. So many people who have the capacity and potential to continue to be good engineers are overlooked because they don't know a specific framework or language or because they worked with unpopular tools in the past. It seems to be a trend to do absolutely zero training these days and expect the engineer to not only learn on his own, but to teach himself outside of the job. Some companies even expect extensive open source work from candidates while at the same time requiring incredibly long hours. The idea that candidates might be doing other, non-programming things outside of work, want time to do those, and might not be interested in pursuing their craft 24/7 is looked down upon. I can't think of a single profession that's so demanding.

The irony is that most jobs in the field are incredibly easy for someone who is even moderately skilled and hardly ever use the skills being tested for. When these things are eventually needed, all that one needs to do is a bit of research to come up with a good solution, but somehow this is looked down upon. Most programming jobs and professions that do not require knowing how to build algorithms, jobs in which if you're writing search algorithms or any other kind you're simply doing it wrong and wasting time. Why would we expect all programmers to know how to write certain algorithms or solve certain unfamiliar problems off the top of their head when that isn't what they've focused on in years, if ever? You wouldn't expect a cardiologist to be an expert in neurology, yet many software companies are really only seeking the equivalent of neurology experts when they actually need a variety of expertise. Sure, a general background is good, and most good developers will have a broad understanding of many topics, but expecting a deep understanding of every topic is simply ridiculous. The companies with such expectations end up hiring the same type of expert while ignoring a ton of talent.

Let's not forget that in the end, this is a job. Despite all the rhetoric about loving the work and other such nonsense, 99% of programming positions are just another job that no one would do if they didn't pay well. It's not in the workers' best interests to be emotionally invested in their work as this only benefits the employer to the detriment of the employee. Thus, most things will still be learned on the job, either with the support of or more commonly, in spite of the employer. People work the job because they want to provide for themselves and their family. If the job is enjoyable, it's mutually beneficial, but that's not something that can generally be expected. Yet many employers expect employees to both love their job and love the profession enough to put in a ton of additional time outside of work learning and coding for free because they are too cheap to provide proper training and their working conditions are generally to abysmal for them to retain workers long- term.

The solution here is to hire people with a good general background and invest in their education on the job. To do so, employers need to find people who can actually see the potential in others and who know how to interview, not people whose idea of a good interview is asking whiteboard questions and insisting the candidates talk them through the problem instead of letting them think it through and actually solve it. This requires employers to actually respect employees once they are hired so they can be retained long-term and their training is worth the investment. This would be an even bigger change than changing the interview process. Employers would have to stop asking employees to work for free (salaried overtime). They would have to stop being childish themselves and literally yell at or threaten employees. Employers would have to afford their employees basic human respect, something that is severely lacking in technology companies, especially in Silicon Valley. Those changes would indeed be radical, and employers who implement them quickly find out what the rest of us have known for years: there is no shortage of talent or good engineers.

</comment><comment><USER99> If you hire someone and they can't code then you're the first person who should lose their job. Sorry to say.

</comment><comment><USER100> > _In all my years immersed in the tech industry, I have never once heard a > firm talk about the idiots lurking in their own offices. They always seem to > be elsewhere. For everyone._

When you point one finger, there are three fingers pointing back to you. Hey author, _you_ are on of them!</comment>


We Are Closing Down the CppCat Project - <AUTHOR> http://www.viva64.com/en/b/0320/ <comment><USER2> What they thought wrong about the student licenses is that students typically don't spread a word, but instead get used to the software and will (if they like it) ask their employer in the future to buy licenses for the company, so that they can still use it at work.

The cycle from student to employee takes a few years - so you would expect gains from giving licenses away for free to students earliest a few years from this offer.

<comment><USER3> I can't imagine starting such an effort, in this field, while giving it only one year to make money at net; just about breaking even is amazing and shows there's serious demand. They really shouldn't have bothered in the first place, especially since they've created hard feelings and distrust from the users they're abandoning so quickly (assuming they weren't up front about this).

</comment></comment><comment><USER4> Interesting perspective for anyone considering moving down market. Note that they almost broke even, but that wasn't profitable enough compared to their other business:

        During its short lifetime, this project has brought us almost as much money as we had put into its development, promotion, and maintenance.

In other situations, almost breaking even after only a year with a new product would be considered a huge win, but I understand they had considerable opportunity cost.

<comment><USER5> I also find it interesting, that as far as I can tell, the only pricing info on their main product is that it is more expensive than $500 (the high point to which they were advised to drop the price for CPPCAT).

I suppose it's fine to only cater to a high market from a business perspective, but I'd much rather just have them list the price at some high- point they usually charge (eg: 3000$/developer/year ?) with an added caveat of "contact us to negotiate a better price".

Why would I spend hours evaluating a tool I have no idea what costs? I also really can't stand the pricing model of pay-as-much-as-you-can -- then again, I don't use Oracle either.

Not that it really matters -- currently I'm not their target demographic anyway.

</comment></comment><comment><USER6> I just started using CPPCAT for a small safety critical embedded project. I'm a "indie" developer so even at $250 a year it was the most expensive software I use. [I use Visual Studio but that costs less _per year_.]

I can't blame them for leaving the low cost market. Customers with small budgets often (usually?) have a lower ROI than customers with large budgets.

</comment><comment><USER7> tldr: Products that solve enterprise problems can't always be scaled down, because the low end of the market might not have the problem in the first place.

In my mind, PVS Studio is the perfect product for a freemium model. I don't know enough about it to say what functionality should be put behind a paywall (maybe a limit on the number of lines of code it can analyze?) but it seems one of those things where you can create demand at the high end of the market by giving the product away at the low end. If people learn to use it on their hobbies, they'll ask to be able to use it at work too.

</comment><comment><USER8> It's really hard to sell programming tools today. Everyone now expect them to be free.

</comment><comment><USER9> The static analysis business is really hard from the monetization perspective.

<comment><USER4> Isn't monetization hard for most tools aimed at developers (rather than at companies with teams of developers)?

I think that books and book packages that solve a certain problem for a reasonable price point (<$100) are the only developer tools that get bought by small developers--see Nathan Barry, etc: [http://nathanbarry.com/](http://nathanbarry.com/)

<comment><USER9> It is really interesting. You pointed that the static analysis tools are aimed at developers but even the guys from PVS-Studio admit their main customers are big companies with teams of developers and I agree. From my experience such companies "force" their developers to use these kind of tools. It is somehow paradoxical that such tools are so technical only developers understand their results but only managers want (or think they want) to consume them.

<comment><USER10> Pretty much any large open-source project uses Clang's Static Analyzer. So there is a demand for such tools

<comment><USER9> Maybe you meant "there is a demand for such tools as long as they are free"...

</comment></comment></comment></comment></comment><comment><USER11> I've tried it and it really has some nice catches that other tools miss. Now their PVS Studio still remains.

</comment><comment><USER12> Damn!</comment>


Show HN: Tired of entering map directions on Android? I've streamlined it - <AUTHOR> https://play.google.com/store/apps/details?id=com.pheelicks.quickmaps

<comment><AUTHOR> I originally built this after getting tired at how many actions it takes to enter directions in Maps on iPhone. Often I just wanted to navigate from the current location to a common place (eg home, work). With Quickmaps, all I have to do is launch the app and with single gesture I'm done.

After posting the iPhone version to HN 2 weeks ago, one of the most common requests was an Android port. For those on iPhones: [http://itunes.apple.com/us/app/quickmaps/id506283203?ls=1...](http://itunes.apple.com/us/app/quickmaps/id506283203?ls=1&mt=8)

Feedback is most welcome

<comment><USER2> The question occurred to me when you posted the iPhone version, but why do you include both source and destination? Wouldn't "current location to destination" make more sense? Or is there a use case I'm missing?

<comment><AUTHOR> Only half of user queries start with the current location, the other with a pre-defined location.

A common use case I can think of is Home -> Work using public transport.

<comment><USER2> Okay, I can see the public transit case, since that might help for planning. I live in a place without any real public transit to speak of, so it didn't even occur to me!

</comment></comment></comment></comment><comment><USER3> I've had pretty good luck just saying "Navigate to: 123 MyHouse, San Jose" etc...

At least for me it almost always works.

<comment><USER4> Having moved to an iPhone, this is the feature I miss the most aside from google navigation not really having a solid competitor on iOS

</comment></comment><comment><USER5> Nice feature! Saved locations + easy way to navigate/use. The only time I use Maps is when I'm driving, and this is a nice layover. Thanks for the app.

One item: the "edit" button wasn't obvious that it was for editing locations. Rather, I thought it was associated with the types of directions -- driving, walking, transit, etc. If I could make a suggestion, make the destination circles editable by bringing up a menu when holding the circle for an extended amount of time. It's what I did initially.

</comment><comment><USER6> One feature that would be nice if when adding addresses you could choose your current location, preferably saved as Lat/Long coordinates.

I'm thrilled to use this program for public transit, but I've noticed that the nearest street address to some bus stops (particular park & ride lots) don't match well.

This way I could add those stops as one of my saved locations.

</comment><comment><USER7> How often do people need directions to a place where they have been before? Most of the time I don't need directions once I've driven there. However, I have gotten stuck in traffic because I didn't check if it the regular route was the fastest way there.

<comment><USER8> Your last sentence -- I use GPS almost everywhere I'm driving because of the real-time traffic data.

<comment><USER9> Same here. I use Google Nav everywhere I go, even when I know how to get to the location. I even use it on the ride home from work _every day_ because the exit closest to my apartment (Balboa/Garnet on the 5, for those in the San Diego area) has a tendency to clog up easily due to multiple red lights right off the exit.

Google Nav lets me know if I should get off there (most direct route) or take the 52 to Clairemont Dr and circle around (less direct, less likely to be traffic clogged), depending upon the real-time traffic data.

</comment></comment></comment><comment><USER10> Nice app! I think the iPhone version of this made a lot of sense, but on Android, you've always been able to add a directions widget right onto the desktop to launch directions or navigation with a single touch.

<comment><USER2> It chews a ton of battery if you do, though, since it gives you time-to- destination, which means GPS.

<comment><USER11> Or you could just add a location shortcut to the desktop, which doesn't use any extra battery power.

</comment></comment></comment><comment><USER12> I have the iPhone version of this app and it is much simpler than typing addresses. Still not a great solution for new addresses, but that may not be solveable with a third party app..

</comment><comment><USER13> When editing the locations, I'd rather find places on a map than go through the agonizing process of entering the addresses with the phone's keyboard.

</comment><comment><USER14> i just create shortcuts to my home or frequent addresses. The major use case is not from frequent location A to frequent location B. The major use case is from random place A to frequent location B. Creating shortcuts on the dashboard to navigation has been the simplest solution, pretty much what you're doing here. Hold down on dashboard, create shortcut to location.

</comment><comment><USER15> I like the grid layout, maybe additional places could be saved by having 'pages' of locations?

</comment><comment><USER16> I have your iPhone app. It is pretty cool. Thanks!

</comment><comment><USER17> good man</comment>


Tech takes a softer initial stance on Trump's latest executive order - <AUTHOR> https://techcrunch.com/2017/03/06/tech-takes-a-softer-initial-stance-on-trumps-latest-executive-order/ <comment><AUTHOR> Mods: What is the current rule on political-related stories? The lack of them on the front page can't be coincidence. Users would like to know ...

If it's was stated in a discussion somewhere, as has been the case in the past ... perhaps we could use a better way to communicate these things. Nobody can read every comment in every discussion.</comment>