On Secretly Terrible Engineers(techcrunch.com)
techcrunch.com
On Secretly Terrible Engineers
http://techcrunch.com/2015/03/08/on-secretly-terrible-engineers/
379 comments
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.
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.
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.)
(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.)
> 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.
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.
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).
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).
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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?
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?
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.
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.
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.
(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.
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.
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.
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.
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.
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.
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.
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.
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.
> 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.
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.
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.
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.
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.
It strikes me that in the same day (albeit one filled with hiring articles) we get an article about the success of Greyston Bakery, which will literally hire anyone and train and support them as much as needed to be successful—and this, which is along similar lines but is about software development, which, obviously, requires special individual aptitude that only a chosen few can succeed at, and must be protected from the pretenders to the throne. /s
Somehow, it feels warm and fuzzy to support the social justice of the little bakery that could, but when it comes to our own companies, our true colors shine.
Continue to take the systematic approach. It is still the best way. Of course, of course you should hire as effectively as possible, and try to have a baseline of aptitude, but there are always going to be outliers and bad fits. It's far more effective to optimize your system for the success of all employees than to focus on weeding out the 'bad ones.' Sure, there will be people that won't fit your system, but they made it through the hiring process for some reason—figure out their true aptitude and transfer them to something they'll be effective at.
The article may be wrong about the existence of fakes and bad programmers—anyone who has filed through a stack of resumes knows that—but it's right on the unreasonableness of the fear and the weight we give it.
I say it all the time to our CEO: if hiring is really a huge problem we want to focus on, how did we get all these great people? Hm.
And if hiring is really the solution to all our problems, then, well, what do we do with all these idiots standing around here?
Ha. That really is the question. The real problem is organizational and systematic. Stop worrying so much about hiring, optimize your process and be done with it, and focus on what happens afterward instead.
Somehow, it feels warm and fuzzy to support the social justice of the little bakery that could, but when it comes to our own companies, our true colors shine.
Continue to take the systematic approach. It is still the best way. Of course, of course you should hire as effectively as possible, and try to have a baseline of aptitude, but there are always going to be outliers and bad fits. It's far more effective to optimize your system for the success of all employees than to focus on weeding out the 'bad ones.' Sure, there will be people that won't fit your system, but they made it through the hiring process for some reason—figure out their true aptitude and transfer them to something they'll be effective at.
The article may be wrong about the existence of fakes and bad programmers—anyone who has filed through a stack of resumes knows that—but it's right on the unreasonableness of the fear and the weight we give it.
I say it all the time to our CEO: if hiring is really a huge problem we want to focus on, how did we get all these great people? Hm.
And if hiring is really the solution to all our problems, then, well, what do we do with all these idiots standing around here?
Ha. That really is the question. The real problem is organizational and systematic. Stop worrying so much about hiring, optimize your process and be done with it, and focus on what happens afterward instead.
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.
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.
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.
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.
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-...
"How Elon Musk Can Tell If Job Applicants Are Lying About Their Experience"
http://www.businessinsider.com/elon-musk-job-interview-rule-...
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. :)
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. :)
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".
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".
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.