On Secretly Terrible Engineers

http://techcrunch.com/2015/03/08/on-secretly-terrible-engineers/

by minimaxir • 11 years ago

463 376 11 years ago

mkozlows5• 11 years ago

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

jdbernard• 11 years ago

He also make the assumption that secretly terrible people don't exist in other fields. In my experience there is a small set of people in every discipline that are just leeches who contribute almost nothing but somehow stay employed. There are plenty of crappy lawyers still practicing, for example.

I see little value value in being purposefully hostile, but I also see little value in this hand-holding, spoon-feed me approach he seems to want. We should encourage people and mentor junior team members, but I am not interested in extending "love" to some person I just met.

jacques_chester3• 11 years ago

Where I work, we have a two-step process.

The first is called "Rob's Pairing Interview", or RPI. We go through a very simple problem. Takes 30-60 minutes. Nothing fancy is required, nobody is getting an algo pop quiz. Just a basic smoke test to see if you have, at some point in your life, programmed at all.

The second is pairing interviews. You come in and pair with us. At work. On real software.

When I got hired I kept waiting for the shoe to drop. It was just like the interview. Exactly like the interview.

The shoe never dropped. That's just ... how we work. The pairing session were a 1:1 example of daily life. And in a pairing situation there are no Secretly Terrible Engineers. And only a few Secretly Awesome Engineers, which is why we do it that way.

fishnchips3• 11 years ago

"can't program" is such a sweeping generalisation as to necessarily be null and void. I don't really think there is such a magic binary quality. Most everyone can learn programming and it's just a matter of patience and guidance. The only hopeless cases I've seen is folks who are poor coders but are convinced otherwise.

mkozlows5• 11 years ago

That's great, but if I'm hiring a person with ten years of experience whose resume is full of "senior developer" stuff, I don't think that either of us is interested in them doing an unpaid internship while we teach them the basics of programming.

dantheman• 11 years ago

If you can't program fizzbuzz they you can't program.

HillRat• 11 years ago

I've just gone through a rather prolonged search and hiring process, which involved hiring and then having to (regretfully) release some candidates (near the end, we were bringing them on as contractors so as not to create too many expectations). After dozens of interviews and resumes and a few attempts at hiring, we finally got a great candidate fit.

But here's the thing -- only a very few of those candidates actually were "flat-out" incapable of programming, and it was pretty easy to figure that out. Of the others, most of them were capable of programming, but not capable of developing, which seemed to be the dividing line.

Part of my interview consisted of data-modeling exercises (from workflow documentation) and slightly more-than-basic algorithm exercises (in which I wasn't looking for good code, so much as to understand how the candidate attacked the problems). I wasn't trying to bigfoot the candidates, but it was amazing how many couldn't work their way through relatively simple modeling or algorithm design problems at all.

And yet these were professional programmers. They had degrees, sometimes graduate degrees, from good universities; they had spent years in the field; they had solid references from good employers. I refuse to believe that so many practicing programmers could simply be incompetent and never raise any kind of concerns.

Which leads me to think that there's something wrong with our discipline. (I remember an old USENIX symposium where one of the talks was, "If computers had blood, they'd call us doctors." My reply at the time was, "If computers had blood, they'd call us serial killers.") If we built bridges, we'd assign a different engineer to each leg of the bridge, start at both sides simultaneously, never bother to check flood gauges or soil samples until halfway through the project, and try to swap out the cable suspension design two weeks after opening it to traffic.

In other words, we take perfectly capable programmers and turn them into useless cogs. Programmers who can't see the forest for the trees or the trees for the leaves. Who never are exposed to systems design problems, who use HashMap as the solution for every problem because we need that code yesterday and there's no time to discuss more elegant solutions (seriously, at least half of those candidates were obsessed with HashMap, for a problem where a hash table made no sense), who are shoved into a tiny chunk of the code of a massive enterprise monstrosity and expected to keep making changes and bugfixes until the code bears no resemblance to a reasonable solution to the problem.

Bad programmers who don't learn aren't the problem. Good programmers who don't teach are. Not brilliant programmers, not rock stars or code ninjas or whatever the fuck we're calling them this week, just good, solid programmers, the sort we say we can't find. If we don't give good programmers the time, space, and incentives to teach by praxis -- if the only way to be a good programmer is to bootstrap your way up -- what right do we have to complain?

FLUX-YOU3• 11 years ago

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.

mkozlows5• 11 years ago

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.

gizmo686• 11 years ago

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.

I do not think that is even necessary to being a programmer. It is possible that someone has always worked on projects with an already existing build system, and only knew to run "make" (or equivalent) to compile. These people could be competent at actually programming, but not know how to compile something outside of an existing build system.

giaour• 11 years ago

No true Scotsman would question my definition of a "real programmer."

eichin• 11 years ago

You're missing one key thing - by the time we see the candidate they've given us a resume that says that they can and have programmed some actual things in some actual langauges. How do you explain their inability to then do some trivial thing (more trivial than fizzbuzz even) in the language that they've already claimed skill in?

I could be wrong, but these simple tasks seem to help distinguish "hung out on a team that did those things" or even "has been stuck in meetings 38 hours/week for the last 5 years and is startlingly good at powerpoint", when those are not what we're looking for.

jacques_chester3• 11 years ago

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.

leereeves2• 11 years ago

I think trivial questions meant FizzBuzz and count the A's.

What's the legal equivalent of that?

jacques_chester3• 11 years ago

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.

hiringcat2• 11 years ago

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.

ChainsawSurgery• 11 years ago

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.

straws• 11 years ago

Ah, but what about Official Scrum Master Certification panels?

patio113• 11 years ago

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.

Domenic_S2• 11 years ago

That story could have been taken directly from my own brain. People like this get hired not infrequently and it's always frustrating to get one on your team.

japhyr• 11 years ago

Is this always nepotism, or does it have something to do with the reluctance some organizations have in firing someone?

baruch• 11 years ago

I've never seen such an incompetent person hired anywhere I worked for.

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

chubot2• 11 years ago

Say what you want about Google (it seems to be common here), but you will never work with anybody like that at Google. Really never ever.

You will work with managers, PMs, and lawyers who have much more coding skill than that.

Not to say there isn't bad code. Actually the problem at Google is people write too much code... But there is a base level of competence you can expect.

pjmlp• 11 years ago

I used to think that working with harder languages, e.g. C++,Scala,...[0], would avoid such people in the team, but no, some managers always manage to cherry pick them into the projects.

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

drewblaisdell• 11 years ago

I'm curious if you have any insight into how coworker Z was hired in the first place.

angersock4• 11 years ago

Now, to place this in context--was this at a company in Japan, with (by you even!) well-documented social norms about how technically incompetent employees are dealt with, or was this with a company with more conventional engineering culture?

patio113• 11 years ago

This is not a Japanese-only thing. It is a thing so common in America that there is a named test to detect it -- FizzBuzz [+] -- and this test, or one like it, actually catches many people out.

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

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

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

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

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

Nursie• 11 years ago

We've all worked with them. A senior engineer I worked with previously, claiming 25 years experience, did not understand when I rejected his code that declared a pointer, set it to null and then proceeded to pass it to another function with a memcpy style interface to put data into a supplied buffer. It compiled and was therefore correct to his mind. After several incidents like this and lots of proclaiming "it doesn't work" when encountering a bug, which he would then proceed to make someone else's problem, I learned to think of him as a very poor tester.

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

ChuckMcM• 11 years ago

That is pretty scary. But more importantly it is really sad that the example programmer's manager doesn't know he's in capable of basic functions. I've seen programmers who were in a new place (new language, new environment) struggle and have helped them get organized, and if they weren't able to adapt move on to a company that used a more familiar environment. But that does take paying attention, and sadly some managers don't really pay attention.

angersock4• 11 years ago

I'm a bit of a fan of the mindset a few consulting companies I know have (only in this particular regard):

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

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

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

mtviewdave• 11 years ago

Agreed totally.

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

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

PhasmaFelis• 11 years ago

I had one job that, days before the interview, sent me the spec for an archival format they used, and asked me to implement an extremely basic archive generator and email them my code. At the interview, they asked me to explain what my code did. I went into detail about specific implementation decisions, things that worked for this restricted domain but would not work for a more general version, and ideas for future development.

Best job I ever had.

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

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

bbarn• 11 years ago

I was once asked "Can you do a quick fizzbuzz implementation on the white board for me" by an interviewer. I stood up, looked at the whiteboard and said "So it's, what.. multiples of three are fizz, five are buzz and both are fizzbuzz right?" and he said "Yep, nevermind, let's move on."

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

logicallee4• 11 years ago

wait, wait, wait. In your first two paragraphs, by "software engineer" do you specifically mean a coder, a programmer, someone who is paid basically to write lines of code? (As opposed to: software tester, architect or manager-type role on technologies they might not know personally, front-end designer who happens to accidentally be able to do some javascript etc.) You mean someone with nobody below them, who is not doing software testing, debugging, front-end design, or the like, but paid to put out code, but cannot write a for loop that does a character count in the specific language they are paid to code in? And who is gainfully employed "coding" in that language, for months, years?

patio113• 11 years ago

I know, you think I'm insane, right? I doubted my sanity, too. Not a software tester, nor an architect, nor a manager, nor a houseplant, nor a figment of my imagination. A software engineer.

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

Iftheshoefits4• 11 years ago

I've interviewed, and been an interviewer, in interviews with the most obnixous technical questions, interviews where the hardest technical question was equivalent to "can you code?" and interviews that were in between. In no case was there a discernable correlation between the technical difficulty of the interview and the abilities of the eventual hires.

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

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

muddyrivers3• 11 years ago

Strongly agree.

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

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

Edit: typos and grammers

wpietri2• 11 years ago

This has always mystified me. The key to any interview I do is a pair programming session. Before I hire somebody, I'd like to see what they'll be doing after I hire them. Crazy, I guess.

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

the_cat_kittles3• 11 years ago

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

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

muddyrivers3• 11 years ago

The OP's point is, unless I misread it, not that there are no incompetent engineers who can't code, but it is ridiculous to, like, ask some "fancy" algorithm questions, brain teasers, etc. that are mostly not related to the candidate's working experience at all.

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

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

morgante4• 11 years ago

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.

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

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

Gibbon1• 11 years ago

I read a really good comment by I think Nolan Bushnell about engineers. He said said he got asked all the time about how to avoid hiring unproductive engineers. And he said he found that baffling. Because an unproductive engineer just costs the company their salary. More important is ferreting out and eliminating negatively productive managers, engineers, and technicians in that order.

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

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

pkaye3• 11 years ago

An anecdotal case of the worst candidate I interviewed. He was friends of our VP. He had an engineering degree from UC Berkeley. Over 20+ years, he was a consultant for firmware development at 28 positions. The non technical portion of the interview went great and I said I wanted to ask a few coding questions. He was really resistant and used all kinds of excuses. I told him to humor me and code something simple like draw how a linked list works and how the to write the insert function in C. At the point I was totally caught off guard. He knew not a single like of C syntax and just made things up. He didn't understand the concept of pointers at all. Later when I talked with my co-workers they had the same feedback. He didn't know how to program at all. We wondered how he consulted at 28 companies for the last two decades!

ioddly• 11 years ago

Probably explains why he went through 28 of them!

Twirrim• 11 years ago

Terrible $whatever make it in to every field imaginable. The tech industry is nothing unique at all. Bad doctors exist (despite the frameworks for professional exist) for example. I bet almost everyone has dealt with bad customer support people or bad secretaries.

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

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

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

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

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

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

stcredzero3• 11 years ago

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

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

calinet62• 11 years ago

This is a good systematic approach.

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

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

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

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

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

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

TheOtherHobbes• 11 years ago

When I hear a story like this I have to ask - how did no one else notice?

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

x0x04• 11 years ago

I asked someone with a PhD in statistics to, "Explain regression to me like I know some math but have never used statistics." For those of you who don't know, regression can be taught to people either with a single course in calculus or people with a single course in linear algebra. It is also a, maybe the, fundamental statistical tool. I'm generally satisfied with people drawing some points on a 2-variable graph, explaining we're trying to calculate the least error fit, then telling me what that the error specifically is squared error. If the candidate can discuss penalties and outliers and glms and exponential family distributions and IRLS and sampling distributions and gauss-markov then great, but I'm satisfied with a really basic understanding. This guy couldn't get any of it. I simply don't understand how you can have a phd in statistics and not be able to explain in 60 seconds roughly what regression is, how one interprets the betas, and at least one basic inference method.

jghn4• 11 years ago

FWIW I've come across many PhDs (I've worked in PhD-rich environments for the last 15 years) who are surprisingly poor at fundamental level stuff in their field. They're so far beyond it and so specialized that they just don't really remember how the basic stuff works.

alecco• 11 years ago

But maybe he wasn't good at explaining things. Did you try asking if he could apply regression to a simple problem?

lkrubner• 11 years ago

Is there any chance the bad programmer was new to whatever language you were working with? Stuff like this:

"The fooBar subroutine was one statement long."

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

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

ajuc• 11 years ago

I heard this many times, and yet I've never encountered them in my career. I was even interviewing for a while and none of the candidates were as bad as people say.

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

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

ZoFreX• 11 years ago

I'd say somewhere between 1 in 3 and 1 in 6 people that graduated with me (from a decent university!) could not actually program at the end of their three or four years.

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

raverbashing2• 11 years ago

The real question is why wasn't this coworker fired on the spot.

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

vonmoltke2• 11 years ago

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.

cafard• 11 years ago

Raytheon must have been doing something right, and I would be curious to learn what that is.

dfox• 11 years ago

The problem is not that these people "cannot code", the problem is that they cannot implement even the simplest things when it cannot be done by using existing libraries and frameworks they already know of with designing any kind of problem-specific data structure or algorithm being completely out of the picture.

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

tptacek7• 11 years ago

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.

Consultant32452• 11 years ago

I've been coding professionally for 15 years and only have one such story. I once worked with a guy who had supposedly been coding professionally for over 10 years, the most recent 5 of those in Java. He, in all seriousness, asked me how to sort a List. I can forgive not knowing the Collections interface in Java, but not being able to google it and figure it out as a senior developer and team lead is troubling.

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

bane2• 11 years ago

My wife ended up with an employee like that one time. He was absolutely incompetent at even basic development tasks.

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

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

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

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

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

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

Yelwis• 11 years ago

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

How common is this?

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

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

stcredzero3• 11 years ago

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

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

Apofis• 11 years ago

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

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

jessaustin• 11 years ago

Reading and commenting on HN? b^)

baddox• 11 years ago

Could you at least give us some hints about these supposedly utterly incompetent software engineers? Since I've never encountered anything close to that level of incompetence, I'm assuming there is some variable that predicts it and that I have managed to avoid that variable. Is it a certain type of company that employees these engineers? Is it possible that the issue is not even with the employee's competence at performing his or her job, but rather just a bad job title that doesn't reflect their actual role at the company?

Nitramp• 11 years ago

I've seen people leave University with all As in their degrees who couldn't parse a string into a number, and were pretty sure that that was in fact impossible.

pnathan2• 11 years ago

Part of my standard phone screen approach is to open up an etherpad or other collaborative coding tool and ask the candidate to perform a Fizzbuzz variant (variant enough that memorizing Fizzbuzz wouldn't save you). This is entirely intended for failing people who can't code at all.

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

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

obi1one• 11 years ago

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.

thanatosmin3• 11 years ago

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.

Domenic_S2• 11 years ago

Needlessly pedantic.

thanatosmin3• 11 years ago

Really? As a non-software engineer, the title and bridge picture suggested this would be relevant to me, much more so than an article about programmer interviews.

etimberg• 11 years ago

Except if you're somewhere where it does matter. Take Canada for instance, you cannot call yourself an engineer without being a licensed Professional Engineer.

rpcope13• 11 years ago

I strongly disagree; it seems rather perverse to label many developers and programmers as engineers, because most of what occurs in development and programming, especially because of the lack of rigor involved, could scarcely be passed off under the heading of traditional engineering, and should not be confused as such.

sgustard• 11 years ago

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?

mgkimsal2• 11 years ago

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

thanatosmin3• 11 years ago

In my experience (biomedical), this concern does not exist in other engineering fields. That may be because incompetent engineers are just accepted, or because they don't exist--I don't know. Other engineering fields also generally don't engage in extensive quizzing during interviews.

TwiztidK• 11 years ago

Similar to the title MD for doctors or JD for lawyers, engineers have the PE (Professional Engineer) title. It requires a bachelors degree from an ABET accredited school, 4 years of experience, and pass two day long exams. It's pretty rigorous.

Also, based on my experience with engineering interviews, they rarely have what I would call "hurdles." It's not a gauntlet that they have pass, usually it's just a relaxed conversation about their skills and experience to make sure they fit the position and will work well with our team.

mkeeter• 11 years ago

There are a series of licensing exams for the (non-software) engineering fields: one typically takes the Engineer-In-Training exam at the end of undergrad, then can take the Professional Engineer exam after a few years of working under a licensed PE (exact regulations vary from state to state).

These exams are more common for civil than electrical engineers; if I remember correctly, there are regulations that require a Professional Engineer to sign off on blueprints.

auxym• 11 years ago

I've interned in big, international company, doing finite element analysis, a method for structural analysis on computers.

As an intern, I didn't get the formal training on the software suites used, I came in with a bit of experience on another software, and a bit of theoretical knowledge from school. I managed to pick up enough in 4-6 weeks using tutorials, manuals, and the engineers around me that I think I was as productive as you could expect an entry-level engineer to be (fwiw, I had a job offer on the table before finishing that internship).

I clearly remember two guys there. One was contractor, late-20ish and I think had started not too long before I did. The other was middle-aged and I think had been working for the company for quite a couple years. Both quite incompetent. At first I thought it was me, if I couldn't explain something to them there must be something I'm getting wrong right? By the end of my term I had picked up enough, underhandedly, from other engineers, that these guys were incompetent. It was never openly admitted though. But these guys were given only the most basic, boring, tedious work requiring absolutely no actual engineering analysis.

Don't get me wrong, these were 2 guys out of 150ish people doing FEA there, and all the others were absolutely brilliant and I learned a lot. But there are incompetent people everywhere, I think. In my graduating class there was definitely a 5% ish of people which everyone else knew were not going to be doing engineering work. These people often end up as production supervisors and such, never get their PE.

Even in grad school, they are tougher to find, but there's definitely people graduating with MSc's and PhD's who couldn't engineer their way out of a bag. Generally recruited by bad profs who do all the actual thinking and just give them narrow, grunt work to do. There's safeguards in place at the University level to prevent that, especially for PhDs, but it does happen, unfortunately.

I should probably have taken that job offer, but I really wanted to see what academia/research was like.

mockery• 11 years ago

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.

pekk• 11 years ago

Why is asking about particular facts considered a reliable way of finding bad candidates?

azernik• 11 years ago

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

habitue• 11 years ago

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.

michaelochurch• 11 years ago

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.

gnicholas• 11 years ago

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.

davidgerard2• 11 years ago

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.

leereeves2• 11 years ago

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

davidgerard2• 11 years ago

Perhaps, but that's not even close to the balance of probabilities.

rogy2• 11 years ago

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?

bsdpython2• 11 years ago

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.

mkozlows5• 11 years ago

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.

ashark• 11 years ago

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.

bsdpython2• 11 years ago

No side projects even? I used to be one one of those big corporate programmers with no side projects to show off and while I was decently good I wouldn't hire my old self to work on my startup. Also, an interesting idea - ask candidates to find any 3 unanswered questions on stack overflow and answer them. It would at least provide a useful exercise for the candidate and the community at large.

MCRed• 11 years ago

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.

angersock4• 11 years ago

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

toomuchtodo• 11 years ago

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.

Neither can most interviewers.

001sky2• 11 years ago

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.

endergen• 11 years ago

As someone who's in their late 30s and has accomplished a lot, I can agree with the experienced dev above's attitude. But also having interviewed a lot of candidates at scale much of these tests are just filtering tests to reduce the amount of interviews team members must do. We always have the majority of our team members interview candidates so that everyone has buy in, but if everyone had to interview every single resume that looked good on paper (I'm assuming we all at least agree on filtering out bad resumes) this would get cumbersome.

It is frustrating as you get older to deal with the fear of ageism, I haven't experienced it yet, but I'm starting to expect it's arrival.

I actually think the testing you on problem solving is the right way, not necessarily knowing the Big O notation, but at least being able to attempt an answer to difficult questions and explaining your thought process is very telling to intelligence and ability. Definitely there is much cargo cult behavior going on at companies.

GFK_of_xmaspast• 11 years ago

"A" patent in 25 years?

endtime• 11 years ago

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

Possibly neither, possibly both. Having been involved with something that launched at a company I've heard of doesn't necessarily mean you aren't a terrible engineer.

Peaker3• 11 years ago

"Me with a patent and 25 years of innovation in key major products like the playstation network?"

You might be an excellent engineer, but this is a terrible pitch for yourself.

A software patent is meaningless to most software developers. Most software patents are nonsense. Many of us are listed as inventors on plenty of silly patents, and that isn't very impressive. To me, the mention of a patent in this manner is a negative signal.

25 years of experience is nice, but just mentioning that is hard to differentiate from the case of 25 times 1 year of experience. Just mentioning that work was done on something like the PlayStation network is in itself not very impressive: need to spice it up with some actual details.

Zombieball2• 11 years ago

Not trying to put down the parent comment by MCRed, but my experience is very much in line with what you say and in fact getting a patent is even easier if you work at large company (such as Sony). Those technical writers in the patent divisions of orgs are amazing at their job:

1) Submit a thin, whacky idea, with loose documentation to the patent department. 2) Hold a 1 hour phone call with technical writers. 3) Two weeks later you get emailed a 10 page patent application of your idea complete with diagrams asking you to review it.

throwawaykf053• 11 years ago

A software patent is meaningless to most software developers.

This might seem so if you don't leave the HN bubble (which, along with tech media as a whole, has no idea how patents really work yet and so harbor notions like "most software patents are nonsense").

But really it's impossible to generalize a statement like this to any significant portion of our industry. Right here grandparent is an engineer who obviously doesn't agree. There's another comment just below that actually thinks one patent in 25 years is low. The overwhelming majority of software engineers I personally know are proud of their patents. Anytime somebody posts a new patent to their LinkedIn profile, I see nothing but a cascade of congratulatory comments.

Not to say that all the patents out there are awesome, but the notions most people here have about them are far from commonplace.

MichaelGG2• 11 years ago

I interviewed a "Senior Architect" from a large company, and he had a masters in compsci. Very impressive sounding, much more than me. I asked a simple question on searching a sorted array and literally got a laugh. He was incredulous that anyone would be expected to know basic, and I mean basic, data structures and algorithms.

People dismiss these questions with a "I'm not gonna be writing a stdlib". No, but the concepts appear everywhere. Someone that doesn't understand them is likely to, I dunno, use a SQL DB, then put a separate index on each column to " make it fast ". Whereas someone that understands the basics will stop and think a bit before assuming platforms are pure magic.

(And BTW, I've seen enough people with patents to know that just having one is more a measure of going through the process than necessarily having technical invention capability.)

analogwzrd2• 11 years ago

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.

morgante4• 11 years ago

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.

learc836• 11 years ago

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.

Have them walk you through it, or ask specific questions about 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.

The best interview I've ever seen is where they pair you with another engineer and give you an hour or 2 to solve a problem. The other engineer is there to help you and you actually work as a team.

At the end that engineer evaluates you.

analogwzrd2• 11 years ago

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.

fsk• 11 years ago

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.

kragen• 11 years ago

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.

LargeCompanies• 11 years ago

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.

barrkel• 11 years ago

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.

optimusclimb2• 11 years ago

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.

angersock4• 11 years ago

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.

optimusclimb2• 11 years ago

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.

dmansen• 11 years ago

This description is uncanny. Having this person on your team is far worse than someone who flat-out can't code. You can fire someone who knows nothing. Everyone knows what the problem is, and it's easy to talk about. If your team is competent, they'll recognize incompetence.

It's almost impossible to fire someone with the more sinister qualities described here. You always hope they'll catch on: they're smart and they've successfully written working software in the past (this is why you hired them). You end up waiting forever for them to 'click' with the team. It doesn't happen. They're a constant drain and their mistakes compound until your code is unmaintainable.

Note that I'm not picking and choosing any of OP's complaints. They come as a complete package. I've worked with a person who had every single bad quality listed. As I read the OP, I was thinking we must be talking about the same person. I couldn't have described it better.

logicallee4• 11 years ago

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.

rapidally2• 11 years ago

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

dekhn2• 11 years ago

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.

Luyt7• 11 years ago

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.

lambda7• 11 years ago

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.

bkeroack• 11 years ago

If your technically astute hire spent too much time on HN or Reddit, it sounds to me like you failed to engage her with interesting work.

lambda7• 11 years ago

No, we gave him plenty of interesting work. And as we discovered, the above described interview was actually a fairly low bar; when faced with problems slightly more challenging, he would fall apart and give up in frustration. And he was very touchy, so wouldn't accept help when he hit those kinds of situations; he would just spend all of his time reading Reddit and HN instead of getting the help he needed. He was essentially impossible to work with.

We had overlooked his personality quirks when hiring him, as we didn't want filter out someone who was technically sharp but was simply personally quite weird, but it turns out that in practice we just could not work with him.

lgas• 11 years ago

That's possible, but it's equally possible from the information given that she (*he as it turns out) was just lazy and unmotivated or was in some other way actually the problem. Both types of people exist in great numbers.

mattmanser6• 11 years ago

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.

ac2u2• 11 years ago

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.

rpcope13• 11 years ago

This sort of attitude is part of why I suspect that even with all the incredible advances in computer hardware, that all of our applications seem to be just as slow and bloated as their equivalents were 20-30 years ago.

lambda7• 11 years ago

  Mainly because a lot of the things you just listed are 
  incredibly stupid requirements.

Do you know the job I'm hiring for? Perhaps I'm hiring for something a little more complicated than a front-end developer over a CRUD app.

  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?

Because sometimes, those 100,000 operations actually wind up pushing it from 0.5 to 5 seconds. Or even worse, something that works with 1,000 records in .5 seconds, once you go up to 100,000 records takes over an hour, because you're doing something that takes O(n^2) time, so a hundredfold increase in number of records leads to it taking ten thousand times longer. If you don't even know what big-O notation is, or how to think about an algorithm like that, you may not even realize why everything has suddenly gotten so slow; or even worse, you may have designed and implemented a large system with that O(n^2) baked in to the very fundamental design, so it would require a huge rewrite to eliminate it.

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

It is not always abstracted away as cleanly as you would like. For example, here is a bug that occurred when Firefox sent an HTTP request in several smaller packets rather than one larger one, and that caused it to break when talking to IIS:

https://bugzilla.mozilla.org/show_bug.cgi?id=137155

How would someone impacted by that be able to even figure out what's going on, if they don't know anything about what HTTP is built upon?

  Imagine asking a front end developer to make a console 
  app in their interview

Hey, it's a good thing this isn't my front-end developer interview; in that, I give people a basic REST API to program against, and have them write a simple frond-end for it, using any toolkit they like. No console apps at all in my front-end interview.

This is my back end, systems interview, for people working on a network attached storage system, where we frequently need to debug complex problems in a distributed environment, solve compatibility problems with third party proprietary software in which the options for debugging it are slogging through syscall traces or stepping through it in IDA, where we've had performance problems where tweaking the kernel's TCP retransmit timeout for systems that we knew were on the local network has made a huge improvement.

  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.

Or maybe my interview is tailored for the job that I'm hiring for? As I said, this is my back-end, systems interview, and I have a different one for front-end developers.

And as I said, I don't expect every developer to pass every question. I do still ask the TCP and algorithmic complexity questions to front-end developers, but if they do poorly on those while being able to write up a front-end to spec based on the API I give them, and being able to describe intelligently how they would design a more complex interface with richer interactivity, then I know that they can do the job assigned and we have sufficient other people who can do review to ensure that they don't write themselves into a corner complexity-wise or help them debug weird problems due to something in the networking stack. Or if they do well at the TCP and algorithmic complexity, but are relatively new to front-end development, I know that they have a good base of background knowledge and analytic mind, which means they should be able to pick up the rest of the skills they need without too much difficulty.

But if someone does poorly on everything, or more than a couple of the questions, it means that we would basically be flying blind hiring them; we would need to train them up on everything they need to do, and in the end, there's no guarantee that they'd actually be able to perform.

gargarplex• 11 years ago

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?

ExpiredLink• 11 years ago

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!

rpcope13• 11 years ago

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

cornellwright2• 11 years ago

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.

vonmoltke2• 11 years ago

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.

cornellwright2• 11 years ago

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.

namuol• 11 years ago

It's easy to blame this on hiring when in reality it's a complex combination of employee oversight, team building, scheduling, budget, "culture", etc...

et2o3• 11 years ago

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.

gfodor• 11 years ago

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

et2o3• 11 years ago

You said it, not me :-)

lukeasrodgers• 11 years ago

Maybe the point was about specifically "trivial" questions. The article's author may have been attempting to draw an analogy between the questions we ask in interviews, and asking a doctor to state the normal range for human body temperature (e.g.), which probably only happens once during early-stages of training.

et2o3• 11 years ago

I think that is a possible interpretation of this sentence, but I'm not sure that I agree with it in the larger context of the piece.

In the preceding paragraph, he states that applicants are expected to know "the latest RB tree research." In the following paragraph, he states that applicants are asked "technical minutiae." These examples to me don't seem to imply he thinks that "trivial" questions are being asked in interviews. The entire piece seems to argue that questions which are too difficult are being asked in order to unfairly weed out engineers who cannot answer them, which seems to me to be the opposite of trivial.

To contrast, he explicitly used physicians as an example where occasional questions (which are 'trivial') have to be answered early in training in order to be licensed, a statement which I submit is false. There doesn't seem to be a corollary either stated or implied that physicians are otherwise asked nontrivial questions when they are not asked trivial questions.

geebee• 11 years ago

I was a little unhappy to read this line as well. I thought this blog post was insightful and addresses an important topic, and I do think that the difference between the interview process in medicine and programming is worth investigating.

For starters, yes, you're absolutely right. Doctors must pass very difficult exams, and the statement is too inaccurate to go unchallenged.

But please consider the next statement as well: "These fields have the benefit of well-defined bodies of knowledge and monopolies over their skill, so in that regards I guess they have a huge organizational advantage to prevent incompetents from walking through the door."

I think there's so much of importance to consider here that I hope we don't stop after rebutting an exaggeration that I will fully acknowledge is very inaccurate.

Of course, it's always going to be difficult for a mid-career programmer to comment intelligently on interviews for mid-career physicians and vice versa. But my impression is that while physicians do take rigorous exams (and must continue to do so throughout their lives), the career and study path is much better defined, at least in part because Physicians are in far greater control of their profession than programmers are.

For instance, when a physician interviews, is the candidate possibly facing back-of-textbook questions about organic chemistry? Do they need to keep that book around and study it for 40 hours (or more) when they change jobs? If there are additional training requirements as the field evolves, how well defined is the study and exam path?

The impact of this particular blog post was weakened a bit by the inaccurate depiction of what it takes to be a physician. But let's still consider the issues. In other HN discussions about this topic (interviews), someone wrote that they'd happily take a brutal "Bar" exam for software if it meant that they could finally be free, for once, from the highly unpredictable exams they must take every time they interview.

For final thoughts - I was a math major (with some CS coursework) and I have an MS in Industrial Engineering. I interviewed for a company that does software in this area. During my interview, I was asked (from memory here)

Prove the dual of the primal is the primal of the dual; Now, with matrix notation; Various binary tree operations; Print all permutations of a string; Find the long term state probabilities in a Markov chain; Write a query testing to see if I know outer joins; Swap two integers without creating a third integer (asked over lunch); Refactor code with lots of if-then (to demonstrate that I know what a factory and strategy patterns are); Detect a cycle in a linked list; …

That wasn't all, because I interviewed at three companies over the course of a week and a half, but I think I'll stop there. At one point or other, in my life, I've taken exams on all this. I wasn't sure of what would and wouldn't be asked, and of course, I don't walk around with all this loaded into exam-ready memory. My guess is that a physician wouldn't have equivalent coursework loaded into short term memory either, and wouldn't be grilled on it in interviews, but what do I know?

I don't know what the solution (if any) will be, but I think it's a good start to recognize that 1) it's horrible, and 2) other professions - even ones that require massive amounts of education - don't apply the process so arbitrarily and capriciously (for instance, I had no idea I'd be asked about strategy patterns or asked about optimization math proofs. The next week, I was asked about database transactions and locking).

frou_dh• 11 years ago

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!

henrik_w• 11 years ago

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/

morgante4• 11 years ago

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

Firegarden• 11 years ago

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

neaanopri• 11 years ago

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.

XorNot• 11 years ago

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.

mseebach3• 11 years ago

We're not talking about only hiring the top 0.1% programming talent at the expense of the top 1%. We're talking about the people that either can't program, or are very, very bad at programming.

Dealing with those isn't a "comparatively miniscule" task, it's an extraordinary drain on productivity and morale.

We think that miraculously, good developers become good [...] never by practice within a big company. Then, one we hire them, their skill level freezes.

This is patently false. Are you familiar with the concepts of "experience", "promotion", "pay raise" or "bonus"?

jorgecastillo• 11 years ago

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.

joesmo3• 11 years ago

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.

walshemj3• 11 years ago

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.

BSousa3• 11 years ago

You see this a lot in these kinds of discussions, but I can guarantee you will overlook a lot (most?) of excellent developers as many can't open source code (due to employment contract) or just don't really want to be coding 24/7 when their jobs fulfil and challenge them already and they have family/friends/sports/whatever to do outside work.

These seems to be a trend from younger developers from what I've seen, which assume every developer will have a GitHub account to show (like young non-developers nowadays can phantom people that don't use facebook or don't have a smartphone ;)

joesmo3• 11 years ago

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

ap22213• 11 years ago

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.

learc836• 11 years ago

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.

locahost• 11 years ago

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

rogy2• 11 years ago

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

poikniok2• 11 years ago

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.

linuxhansl• 11 years ago

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

Luyt7• 11 years ago

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

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

milesf• 11 years ago

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

ansgri• 11 years ago

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.

zerr• 11 years ago

Totally agree! I hate questions asking about your "great" achievements, code that you're "proud of"...

We're not proud... It's always possible to reiterate the code your wrote and make it better (and again, and again) - but the question is: is this the most priority for today?

skybrian• 11 years ago

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?

hnnewguy3• 11 years ago

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?

stcredzero3• 11 years ago

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.

joeyspn• 11 years ago

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

DanielBMarkham• 11 years ago

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.

yoklov2• 11 years ago

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.

poikniok2• 11 years ago

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.

Klockan2• 11 years ago

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.

yoklov2• 11 years ago

How is making a returning a new dynamic array worse than doing a O(n^2) implementation

Avoiding unnecessary allocations can easily mean the difference between missing a frame and not. Keep in mind that we frequently have to deal with bad mallocs and OSes/hardware without virtual memory capabilities.

The main reason I'd prefer O(n^2) vs O(n)+allocation is that I asked for an in-place solution, and there are definitely situations where you'd need to be able to do this (because of pointers to the array base, or because the caller doesn't have access to the allocator to release it, or you're using an arena and then allocating a new array means wasting the memory of the old one...).

Another reason that's a bit more subtle is that the O(n^2) is that it's much more likely to show up when profiling, unlike the allocation which will likely just make everything else slightly slower due to fragmentation.

neurotech1• 11 years ago

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

dkhenry• 11 years ago

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

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.

alanh• 11 years ago

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.

mncolinlee• 11 years ago

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.

TazeTSchnitzel• 11 years ago

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?

calinet62• 11 years ago

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.

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.

dominostars• 11 years ago

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.

bitwize• 11 years ago

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.

steven2012• 11 years ago

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.

daenz• 11 years ago

I also work with someone like this. They get jobs easily because they nail interviews and talk intelligently about problems. But when it comes to implementing actual code to solve real world problems, he can't scale it intelligently at all. Duplicate logic all over the place, hard coded values, refusal to research and use frameworks' best practices...it's all there. It's incredibly frustrating, and because he's so knowledgeable, it makes him even more stubborn to constructive criticism. Many times his arguments boil down to "I don't feel like doing it that way", in the face of valid arguments. The facts remain, his code is difficult to maintain, difficult to scale, and buggy.

the_cat_kittles3• 11 years ago

some people have very asymmetrical perception of code they write vs code other people write. every bug in their code is "just a small edge case, whoops let me fix that", and every bug in someone else's is idiotic and the library is useless. just like how some people cant hear that they suck at music because they cant be as objective about their own stuff.

it is actually a hard, underrated skill to acquire. i hope i have it.

Klockan2• 11 years ago

Sounds like you hired someone who spent 200 hours studying interview questions instead of learning how to program.

Zombieball2• 11 years ago

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

minusSeven• 11 years ago

If I was in your place I would go further than that and try to figure out what he is missing. If his programs don't work how does it work in interviews. Making buggy programs are after all things we all do from time to time. Ensuring that you don't repeat such mistakes are utmost essential.

BSousa3• 11 years ago

Can it be he just doesn't care about the work assigned to him so he just half-asses it? Not saying it is a good excuse, but I have seen good developers that are indeed good, when moved to projects they have no interest at all, become like your co-worker.

raverbashing2• 11 years ago

Why doesn't someone sits with him and mentor him in good practices?

sjg007• 11 years ago

Do you not do code reviews? Can you make comments/suggestions?

drawkbox• 11 years ago

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.

kyllo• 11 years ago

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.

CurtMonash• 11 years ago

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

mark-r• 11 years ago

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.

morninj• 11 years ago

In no way is it true that the CA bar exam is an exercise in "trivial questions."

alexnewman• 11 years ago

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.

idibidiart• 11 years ago

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

sidcool2• 11 years ago

Honestly, I did not get the gist of the article. I am combing through the comments to understand more.

memracom2• 11 years ago

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.

zaroth• 11 years ago

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.

sidcool2• 11 years ago

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

gcr• 11 years ago

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?

On Secretly Terrible Engineers

Related Stories