10 ms·

On Secretly Terrible (Old) Engineers

69 points by leothekim 12y ago

angersock 12y ago
Author invokes comparisons with the medical industry. Look, we really really really don't want to be taking anything from those folks. The hierarchies are rubbish, the talent questionable, and the egos immense. At least in software we can show that code does or doesn't work irrespective of who wrote it.
- michaelochurch 12y ago
  Look, we really really really don't want to be taking anything from those folks. You don't want a doctor's salary? And her level of respect from society at large? I also don't believe that the industry-wide talent level, or quality-of-work level, is lower in medicine than in private-sector software. In fact, I'd be shocked if it were the case. Look, there are some very smart people in our industry (as in theirs) but there are also a lot of idiots.
  - angersock 12y ago
    Even with the salary, the shitty hours, bureaucracy, student loans, and terrible customers kind of make it a wash. The nice thing about software engineering is that we don't have to spend ten years getting educated enough to deal with customers that don't want to take our advice...we can basically start there.
    - fsk 12y ago
      But on the flip side, as a programmer, your career can be mostly over at age 35-45. Do doctors have the problem that the stuff they worked on 5-10 years ago is considered obsolete now?
bitwize 12y ago
I spend a lot of time thinking about big-O performance of my algorithm implementations. Not all the time, but the concern comes up frequently. If the job is just gluing framework bits and bobs together to stamp out CRUD apps, maybe we shouldn't be so surprised when low-skill programmers step up to take it?
- kevinpet 12y ago
  I got caught up on that line as well, especially the authors use of "we". As far as I can tell, the author has certainly studied algorithms, but has never worked as a software engineer.
tptacek 12y ago
The basic thesis as I read it is: You're a 55-year old engineer who graduated from school in '81. You're being interviewed by a 24-year old engineer who graduated 2 years ago. You're asked, in an "algorithm interview", to explain some detail of the implementation of an AVL tree. In reality, despite the fact that they're covered in CS courses, virtually nobody uses AVL trees in industry. In fact, people barely use balanced binary trees at all, and when they do, they use red-black trees, and they use someone else's implementation, because they're a bear to debug. The 24-year old has an advantage with this question because they were recently taught about, and perhaps had to do exercises/homework/tests based on, AVL trees. That this happens is stupid, because it's very unlikely that conversance with AVL trees is going to make much of a difference to your on-the-job performance. Almost all the narratives you can come up with about this involve reading tea leaves and are shot down easily by better selection/hiring/interviewing techniques that answer questions more directly. This line of questioning can go too far; I don't, for instance, think knowing the big-O characteristics of an AVL tree is unreasonable (it's a balanced binary tree, and you should have the complexity of operations on those in resident set throughout your career). (AVL trees are just the first example of algorithmic trivia that came into my head. Substitute Kruskal's Algorithm, or k-means clustering, or whatever,)
- leothekim 12y ago
  I think asking for particular details of an algorithm is pointless, and I wonder how many interviewers actually do that. The more common questions I've encountered in interviews are along the lines of "serialize a binary tree" where the data structures are basic but the problem has different possibly suboptimal ways of being solved. I'm curious if there really is an inherent and implicit bias to these sorts of questions that favors younger candidates. I'd be very sad if that's the case, as I'm more inclined to think other personal biases are in play.
  - mechanical_fish 12y ago
    You may think you're doing the candidate a favor by offering to handwave away the details, but the vaguer question might actually be worse. "Can you write a correct implementation of an AVL tree on this whiteboard, in any programming language, in the next thirty minutes" is a terrible interview question, but at least it has a factual answer. [1] "Can you riff on the subject of serializing a binary tree" is an open-ended question that will inevitably be graded on an imaginary curve. And the first rule of human psychology is: When you're asked to grade people on an imaginary curve, your intuition spits out a decision that is built on unconscious bias. [1] edit: that is to say, it has a factual answer if you ask the question and then fall totally silent. Which would be evil, of course, so in practice you and the candidate will naturally turn this question into a back-and-forth repartee, and it will reduce to the same exercise of unconscious biases as the vague question is.
rhizome 12y ago
Since the author ingratiatingly uses "we," but is actually a Public Policy student and Techcrunch writer, I predict this is part 2 in a maybe 5-part series where he ends up writing about tptacek's conclusions without mentioning him by name. That said, it's interestingly telling to push "STE" as "secretly-terrible engineer" rather than "self-taught engineer." The author's ideal is for the negative case to be the soundbite, but then again: techcrunch.
- tptacek 12y ago
  He mentioned me by name in part 1 of this series, with a link to my post, and I didn't write anything about ageism. I'm pretty OK with the props I'm getting as is.
nl 12y ago
As we enter a more mature phase of the internet’s progress, it may be time for us to reconsider our strong bias toward the new. Maintainability and reliability are increasingly the edges needed to serve internet users accustomed to highly-reliable systems. New approaches to programming will still have their place, but they are entering a more crowded market where they really have to prove their value in order to be received. We need to have a conversation about working with people of different experience and talent levels. We need to address our industry’s lust for shiny (i.e. young) over reliable. For in the process of that conversation, I believe that we will begin to address the odd inequities that plague our industry. Wow. And there exactly is a perfect example of the bias that older engineers complain about. By using the same argument for older technologies and older engineers he conflates the two, implying that older engineers are really better off working on older tech.
- blakeja 12y ago
  The slant/bias in this article was thinly veiled at best.
- tptacek 12y ago
  Yes, this is not a good example of an intrinsic structural bias against older programmers in interviews. Plenty of older programmers also hopelessly captivated by the current NoSQL-du-jour. :)
  - nl 12y ago
    Indeed. Though I think Stonebraker's VoltDB supports SQL as well.. ;)
deleted 12y ago
[deleted]
codeonfire 12y ago
If companies actually tracked the exact questions that are asked and how they are asked, then bias would be easy to spot. People they want to hire get softball binary tree or linked list questions. People they don't want to hire get disqualifier questions that are not in any textbook (and not in journals either) which definitely can't be white-boarded to their satisfaction in 40-45 minutes. I've gotten both. The latter I research afterwards to make sure that it's in none of the 30-40 textbooks I have or in any journals, ACM library, Dr Dobbs, etc. The worst are interviewers who refuse to accept a correct answer. "Oops, I didn't expect the person to have the answer so I better make it more complicated." It's so ridiculous that it's hard to believe people would sink that low. Until you've experienced it though, you won't believe. I think it suffices to say anything that deals with distribution of money, which employment does, is going to have lots of bullshit.
- fnordfnordfnord 12y ago
  That's just the interviewer's way of signalling "I'm a huge shithead, and you wouldn't like working for/with me anyway."
- bcg1 12y ago
  Couldn't agree more. These type of questions/interviews are a total waste of time, and probably poison to most development teams. I've been on more than one interview where I know that I've hit it out of the park, and I swear that the lead dev torpedoed my prospects out of fear that somebody might know enough to call him out on his BS. Even in the best of scenarios, I think that this type of questioning has little value. Unless it is the most basic of questions to determine if the candidate actually knows the languages that they've listed on their resumes, what value is there in testing if someone knows something can be easily looked up and/or researched in a relatively short period of time if it was really important for the task at hand? Please don't take my comments as minimizing the high level of detailed technical knowledge necessary for some tasks... but for most I would take a humble hacker who can quickly inhale new knowledge over the goofballs who end up doing these interviews, hands down.
- mreiland 12y ago
  I've never experienced that, although I once had someone give feedback that I didn't get hired because I didn't bring a notebook and a pen to take notes during the interview. I did bring a few extra copies of my resume, mind you. Just not a notebook. I actually laughed.
deleted 12y ago
[deleted]
jasonlotito 12y ago
Reading this, I couldn't help but think of why there is a shortage of programmers. I think a large part of it is the technical interview. So many places intend it to be a challenge, as if getting through it should be considered a right of passage. "We only hire the best." No, you only hire people who apply, get through the process, and accept your offer. That's the best you can do. People who interview a lot are going to be good at interviews. People that spend years at places will look at a job offer and see the process of proving themselves to new people. And that's a giant hurdle. A part of me wants to do an interview, just to throw the interviewer a technical question back at them. I have a few good ones in my back pocket. When they start with whatever challenge they have, I stop them politely and say: "Wait a minute. You invited me here, so before we go any further, I want to see if your company is worth my time." And hit them with my question. Oh, that would be fun.
analog31 12y ago
I wonder if, instead of focusing on the secretly terrible engineer, we focus on the secretly good engineer. This is the good engineer who you hire, despite your elaborate hiring process. Your entire business could be staffed with SGE's, and you would never know it.
madengr 12y ago
So why don't programming jobs have the equivalent of technicians like most other engineering fields?
- jayvanguard 12y ago
  This is a good point. It would be useful to have a lower skilled, named role for a lot of the rote programming jobs that just involve gluing frameworks together.
- Spooky23 12y ago
  Those are the contract guys from body shops.
michaelochurch 12y ago
I would like the difficult interviews if there were upside to them. Let's say that I'm a Level 6 engineer (on an abstract scale) and you're hiring me for a Level 7 position-- a small promotion to offset the risk of changing jobs. If the technical interview, I might fail (false negative). If that came with upside-- really nailing that machine learning brainteaser would make me eligible for Level 8 or 9 and the comp increase along with it-- then I'd be fine. My issue with the tough, multi-day interview processes is that there's often only downside. Why throw 4 hours into a company's take-home code test just to (possibly) get the same standard-issue, market-level offer I could get somewhere else? A few years ago, I submitted a code sample that was ranked among the top 3 submissions ever-- I worked hard on that fucker-- only to receive a junior-level offer with <0.05% equity. So what was the point of doing the code sample? On age and the quality of engineers, I generally find that older engineers are very good. That said, I'd be skeptical of someone who did "regular old" corporate engineering for 20 years. Why didn't he get out? I completely understand not wanting to move into management, but why didn't he look for an R&D job or move into an architectural role or try to become a consultant? (He may have good reasons, like wanting to stay in Ohio with his family, and therefore having fewer career options; I'd just try to figure out what they are.) Corporate engineering has a low ceiling and anyone good is going to have at least the desire (some may not have the ability, like someone tied to a geographical area) to break through it. The cult of neoteny-- Agile and open-plan offices and the all of the other subtle signs of an age-discrimination/permanent-junior culture-- is somewhat of a self-fulfilling prophecy. Mainstream engineering, in most organizations, is a user-story ridden ghetto, a backlog-retrospective meeting that never ends. By 35 or so, the good engineers have either gotten out of it (possibly moving into R&D, data science, management, or independent consulting roles) or left the industry entirely. The culture of short-termism, open-plan offices, and business-driven engineering provides no exit. You don't get to escape it, in most companies, by being good at your job-- unless you become a manager. What's happening is that tech's "thought leaders" are creating conditions that are hostile to older talent (which is necessary if you want your technology to be any good) with "Agile"/Scrum micromanagement and bullpen office layouts, then saying, "See, no one over 40 is any good". (In fact, there are a lot of good people over 40; they just don't want to work for jackasses.) This is congealing into a pernicious cultural assumption, based on shitty data, when we should actually be blaming the VCs and the mediocre middle-managers-I-mean-founders they fund instead of "old programmers".
killface 12y ago
Shitty interviewers ask: 1. Anything related to trees 2. Big-O trivia and errata 3. Reinventing the wheel 4. Bit-twiddling operations Seriously. If I go into your interview and you ask me to reverse a string, and it's not <string>.reverse(), I'm not taking your stupid job. I don't care if you want me to know the tricks for an in-place string reverse with no temporary variables, that just shows that you don't have a clue how to interview. Good interviewers? The best I've found so far: 1. Ask people to do real-life problems 2. No "gotcha" questions 3. Let people use the environment they'll be using for the job -- this means an IDE, the internet (including stack overflow), and any library they want. What I want to see when I'm interviewing is whether or not you have the ability to solve a problem. I'm going to look at how you abstract and break down problems, how you solve them, and at what point you say, "I think this is done." Yes, I expect good engineers to know when to use a tree or a list or set -- but if you're explicitly quizzing for that, you're probably filtering in more terrible developers than you're filtering out.
- balls187 12y ago
  > Shitty interviewers ask: Google does none of what you prescribe for "good interviews" and they have interviewing down to a science. Yes they've admitted they err on false negatives, but that is acceptable because they have little to no false positives. From what I gather you want an easy interview. What you wrote is impractical (though I agree gotcha questions can be a bit much). As a candidate, I get 1-hour with you and I need to accomplish the following: 1. Does your resume reflect your experience? 2. Can you code? 3. What is it like to work with you to solve a challenge? 4. Sell you on joining us. Real life problems may fit in an hour, but may not. There are so many resources on programming interviews that spending an hour or two during the week prior would pay off dividends in a candidates success rate.
  - deciplex 12y ago
    I interviewed with Google last year and the interviewer did two of the four things listed in killface's post. I actually do not agree with killface that those four things are necessarily bad (programmers should at least be able to make really good guesses at complexity, and know about trees), but at any rate, Google definitely had no fucking idea what my capabilities are as a developer after that interview, so incompetent was the interviewer. It was actually one of the more terrible interviews I've been a part of, and I was not disappointed by the negative result. Google certainly believes they have interviewing down to a science, but I suspect that belief is itself not scientific, and instead just the usual bullshit and collective delusion.
unoti 12y ago
Here's an often overlooked technique for older, self-taught engineers like me: study. Go get this book, The Algorithm Design Manual by Skienna. Also pick up a whiteboard, and a nice set of dry-erase markers. Read the book, and do whatever exercises you can from the book on the whiteboard. Talk out loud, the way you will in the interviews. After a few weeks and 60 hours of doing this, you'll be ready to blow the minds of the people interviewing you. When you go to your interview, you will bring your own markers. Then you don't have to deal with the fat, half dried out stuff you encounter during the interview. Also, warm up for an hour or two before you go to the interview, by doing problems from the book on the whiteboard, out loud. This helps you leave nothing to chance, and be ready for whatever they throw at you. Yeah, it's a waste of time. But you have to play the game. Similarly, when they ask you why you left your last job, lie and tell them you'd accomplished all your goals there, got everything lined up and nailed down, and you're ready to make something happen somewhere else. Don't tell the truth if it's because your managers couldn't care less about doing what's best for the business. If you want to work at the circus, sometimes you gotta jump through some hoops. Big deal, you'll be ok! Yes, the interview process is broken, but you can actually work at it and do well, even if you're old. Buy this book even if you're not planning to take my advice and study. Even if you don't study, this should become one of your most treasured books. I myself was amazed at how many things turn out to be graph problems, and had a great time going through this book. [1] http://www.amazon.com/Algorithm-Design-Manual-Steven-Skiena/dp/1849967202 http://www.amazon.com/Algorithm-Design-Manual-Steven-Skiena/...
- balls187 12y ago
  > Here's an often overlooked technique for [...] engineers like me: study. This is fantastic advice, for everyone. Preparing for interviews isn't wasted time, because ultimately the goal is to land a job that furthers your own personal goals in some fashion. I wouldn't recommend lying. If you're leaving a job, you should stand by your convictions. In my market, it's small and everyone knows everyone, so claiming you nailed everything down is easy enough to verify. Just remember one simple truth: "You are the only common link between all your failed jobs."
  - 12y ago
swatow 12y ago
I think algorithmic interviews are good, because they are a kind of intelligence test. In spite of liberal dogma, some people are more talented and intellegent than others, and tests can shed light on this. However, the article does expose some flaws. Here are two bad kind of algorithm questions 1) Questions that rely too much on background knowledge. Knowing the exact properties or implementation of the more complex algorithms in the canon of undergraduate CS knowledge is not a particularly useful skill in itself. 2) Questions that have some trick that you either get or don't get. These aren't always terrible, but they give a big advantage to someone who has seen the question before. So what is a good algorithm based question? 1) Implementing something basic but non-trivial, like N-Queens with backtracking. Basically, something anyone should be able to do. 2) Something that mixes in domain knowledge. E.g. problems calculating probabilities than can be solved with dynamic programming. 3) Pure domain knowledge, but in programming form. E.g. how to implement k-means clustering.
dreamfactory2 12y ago
The main problem I see with technical interviews is that they are based on an assumption of individual technical knowledge adding value to an organisation. Working instead from an assumption that the whole is greater than sum when it comes to groups of people - I'd be far more interested in what a candidate is like to work with and what unique qualities they bring that we don't already have and which can act as a multiplier for the organisation.
richardjordan 12y ago
There's definitely inherent bias in much of the interviewing process, whether deliberate or not, for many tech startups. But there's also a high degree of bias once inside them. Older engineers with families often can't really do a team bonding that involves Saturday night playing games getting drunk and stoned, for example. Many startups, as they grow, provide things like health insurance plans optimized for 25 year old healthy males, that are just not that good for families and make it harder on older employees. And there are a lot of younger engineering managers who feel uncomfortable leading teams with older more experienced members in them. I've seen teams grow and older engineers pushed out for fairly arbitrary reasons, despite being good coders. And yes, even in this crazy environment where it's hard to hire. (And yes when I was young and early in my career I never really paid much attention to it and shrugged it off, but now it's my friends and I see myself getting up there in age now, it is so very obvious, and a lot more prevalent than I ever noticed.) When someone has nearly 20 years engineering experience (not talking about me, I don't) it is ridiculous to make them jump through some of these interviewing hoops. Sure, some kid fresh out of college might pad his resume - because there's not much to it. But an older veteran with a long resume, not so much. Experience does count. The ins and outs of the latest technology might vary slightly, but the patterns repeat. So much of engineering goes beyond the code on the screen anyway.

69 points by leothekim 12y ago

Author invokes comparisons with the medical industry. Look, we really really really don't want to be taking anything from those folks. The hierarchies are rubbish, the talent questionable, and the egos immense. At least in software we can show that code does or doesn't work irrespective of who wrote it.

michaelochurch 12y ago
Look, we really really really don't want to be taking anything from those folks. You don't want a doctor's salary? And her level of respect from society at large? I also don't believe that the industry-wide talent level, or quality-of-work level, is lower in medicine than in private-sector software. In fact, I'd be shocked if it were the case. Look, there are some very smart people in our industry (as in theirs) but there are also a lot of idiots.
- angersock 12y ago
  Even with the salary, the shitty hours, bureaucracy, student loans, and terrible customers kind of make it a wash. The nice thing about software engineering is that we don't have to spend ten years getting educated enough to deal with customers that don't want to take our advice...we can basically start there.
  - fsk 12y ago
    But on the flip side, as a programmer, your career can be mostly over at age 35-45. Do doctors have the problem that the stuff they worked on 5-10 years ago is considered obsolete now?

bitwize 12y ago

I spend a lot of time thinking about big-O performance of my algorithm implementations. Not all the time, but the concern comes up frequently. If the job is just gluing framework bits and bobs together to stamp out CRUD apps, maybe we shouldn't be so surprised when low-skill programmers step up to take it?

kevinpet 12y ago
I got caught up on that line as well, especially the authors use of "we". As far as I can tell, the author has certainly studied algorithms, but has never worked as a software engineer.

tptacek 12y ago

The basic thesis as I read it is: You're a 55-year old engineer who graduated from school in '81. You're being interviewed by a 24-year old engineer who graduated 2 years ago. You're asked, in an "algorithm interview", to explain some detail of the implementation of an AVL tree. In reality, despite the fact that they're covered in CS courses, virtually nobody uses AVL trees in industry. In fact, people barely use balanced binary trees at all, and when they do, they use red-black trees, and they use someone else's implementation, because they're a bear to debug. The 24-year old has an advantage with this question because they were recently taught about, and perhaps had to do exercises/homework/tests based on, AVL trees. That this happens is stupid, because it's very unlikely that conversance with AVL trees is going to make much of a difference to your on-the-job performance. Almost all the narratives you can come up with about this involve reading tea leaves and are shot down easily by better selection/hiring/interviewing techniques that answer questions more directly. This line of questioning can go too far; I don't, for instance, think knowing the big-O characteristics of an AVL tree is unreasonable (it's a balanced binary tree, and you should have the complexity of operations on those in resident set throughout your career). (AVL trees are just the first example of algorithmic trivia that came into my head. Substitute Kruskal's Algorithm, or k-means clustering, or whatever,)

leothekim 12y ago
I think asking for particular details of an algorithm is pointless, and I wonder how many interviewers actually do that. The more common questions I've encountered in interviews are along the lines of "serialize a binary tree" where the data structures are basic but the problem has different possibly suboptimal ways of being solved. I'm curious if there really is an inherent and implicit bias to these sorts of questions that favors younger candidates. I'd be very sad if that's the case, as I'm more inclined to think other personal biases are in play.
- mechanical_fish 12y ago
  You may think you're doing the candidate a favor by offering to handwave away the details, but the vaguer question might actually be worse. "Can you write a correct implementation of an AVL tree on this whiteboard, in any programming language, in the next thirty minutes" is a terrible interview question, but at least it has a factual answer. [1] "Can you riff on the subject of serializing a binary tree" is an open-ended question that will inevitably be graded on an imaginary curve. And the first rule of human psychology is: When you're asked to grade people on an imaginary curve, your intuition spits out a decision that is built on unconscious bias. [1] edit: that is to say, it has a factual answer if you ask the question and then fall totally silent. Which would be evil, of course, so in practice you and the candidate will naturally turn this question into a back-and-forth repartee, and it will reduce to the same exercise of unconscious biases as the vague question is.

rhizome 12y ago

Since the author ingratiatingly uses "we," but is actually a Public Policy student and Techcrunch writer, I predict this is part 2 in a maybe 5-part series where he ends up writing about tptacek's conclusions without mentioning him by name. That said, it's interestingly telling to push "STE" as "secretly-terrible engineer" rather than "self-taught engineer." The author's ideal is for the negative case to be the soundbite, but then again: techcrunch.

tptacek 12y ago
He mentioned me by name in part 1 of this series, with a link to my post, and I didn't write anything about ageism. I'm pretty OK with the props I'm getting as is.

nl 12y ago

As we enter a more mature phase of the internet’s progress, it may be time for us to reconsider our strong bias toward the new. Maintainability and reliability are increasingly the edges needed to serve internet users accustomed to highly-reliable systems. New approaches to programming will still have their place, but they are entering a more crowded market where they really have to prove their value in order to be received. We need to have a conversation about working with people of different experience and talent levels. We need to address our industry’s lust for shiny (i.e. young) over reliable. For in the process of that conversation, I believe that we will begin to address the odd inequities that plague our industry. Wow. And there exactly is a perfect example of the bias that older engineers complain about. By using the same argument for older technologies and older engineers he conflates the two, implying that older engineers are really better off working on older tech.

blakeja 12y ago
The slant/bias in this article was thinly veiled at best.
tptacek 12y ago
Yes, this is not a good example of an intrinsic structural bias against older programmers in interviews. Plenty of older programmers also hopelessly captivated by the current NoSQL-du-jour. :)
- nl 12y ago
  Indeed. Though I think Stonebraker's VoltDB supports SQL as well.. ;)

deleted 12y ago

[deleted]

codeonfire 12y ago

If companies actually tracked the exact questions that are asked and how they are asked, then bias would be easy to spot. People they want to hire get softball binary tree or linked list questions. People they don't want to hire get disqualifier questions that are not in any textbook (and not in journals either) which definitely can't be white-boarded to their satisfaction in 40-45 minutes. I've gotten both. The latter I research afterwards to make sure that it's in none of the 30-40 textbooks I have or in any journals, ACM library, Dr Dobbs, etc. The worst are interviewers who refuse to accept a correct answer. "Oops, I didn't expect the person to have the answer so I better make it more complicated." It's so ridiculous that it's hard to believe people would sink that low. Until you've experienced it though, you won't believe. I think it suffices to say anything that deals with distribution of money, which employment does, is going to have lots of bullshit.

fnordfnordfnord 12y ago
That's just the interviewer's way of signalling "I'm a huge shithead, and you wouldn't like working for/with me anyway."
bcg1 12y ago
Couldn't agree more. These type of questions/interviews are a total waste of time, and probably poison to most development teams. I've been on more than one interview where I know that I've hit it out of the park, and I swear that the lead dev torpedoed my prospects out of fear that somebody might know enough to call him out on his BS. Even in the best of scenarios, I think that this type of questioning has little value. Unless it is the most basic of questions to determine if the candidate actually knows the languages that they've listed on their resumes, what value is there in testing if someone knows something can be easily looked up and/or researched in a relatively short period of time if it was really important for the task at hand? Please don't take my comments as minimizing the high level of detailed technical knowledge necessary for some tasks... but for most I would take a humble hacker who can quickly inhale new knowledge over the goofballs who end up doing these interviews, hands down.
mreiland 12y ago
I've never experienced that, although I once had someone give feedback that I didn't get hired because I didn't bring a notebook and a pen to take notes during the interview. I did bring a few extra copies of my resume, mind you. Just not a notebook. I actually laughed.

deleted 12y ago

[deleted]

jasonlotito 12y ago

Reading this, I couldn't help but think of why there is a shortage of programmers. I think a large part of it is the technical interview. So many places intend it to be a challenge, as if getting through it should be considered a right of passage. "We only hire the best." No, you only hire people who apply, get through the process, and accept your offer. That's the best you can do. People who interview a lot are going to be good at interviews. People that spend years at places will look at a job offer and see the process of proving themselves to new people. And that's a giant hurdle. A part of me wants to do an interview, just to throw the interviewer a technical question back at them. I have a few good ones in my back pocket. When they start with whatever challenge they have, I stop them politely and say: "Wait a minute. You invited me here, so before we go any further, I want to see if your company is worth my time." And hit them with my question. Oh, that would be fun.

analog31 12y ago

I wonder if, instead of focusing on the secretly terrible engineer, we focus on the secretly good engineer. This is the good engineer who you hire, despite your elaborate hiring process. Your entire business could be staffed with SGE's, and you would never know it.

madengr 12y ago

So why don't programming jobs have the equivalent of technicians like most other engineering fields?

jayvanguard 12y ago
This is a good point. It would be useful to have a lower skilled, named role for a lot of the rote programming jobs that just involve gluing frameworks together.
Spooky23 12y ago
Those are the contract guys from body shops.

michaelochurch 12y ago

I would like the difficult interviews if there were upside to them. Let's say that I'm a Level 6 engineer (on an abstract scale) and you're hiring me for a Level 7 position-- a small promotion to offset the risk of changing jobs. If the technical interview, I might fail (false negative). If that came with upside-- really nailing that machine learning brainteaser would make me eligible for Level 8 or 9 and the comp increase along with it-- then I'd be fine. My issue with the tough, multi-day interview processes is that there's often only downside. Why throw 4 hours into a company's take-home code test just to (possibly) get the same standard-issue, market-level offer I could get somewhere else? A few years ago, I submitted a code sample that was ranked among the top 3 submissions ever-- I worked hard on that fucker-- only to receive a junior-level offer with <0.05% equity. So what was the point of doing the code sample? On age and the quality of engineers, I generally find that older engineers are very good. That said, I'd be skeptical of someone who did "regular old" corporate engineering for 20 years. Why didn't he get out? I completely understand not wanting to move into management, but why didn't he look for an R&D job or move into an architectural role or try to become a consultant? (He may have good reasons, like wanting to stay in Ohio with his family, and therefore having fewer career options; I'd just try to figure out what they are.) Corporate engineering has a low ceiling and anyone good is going to have at least the desire (some may not have the ability, like someone tied to a geographical area) to break through it. The cult of neoteny-- Agile and open-plan offices and the all of the other subtle signs of an age-discrimination/permanent-junior culture-- is somewhat of a self-fulfilling prophecy. Mainstream engineering, in most organizations, is a user-story ridden ghetto, a backlog-retrospective meeting that never ends. By 35 or so, the good engineers have either gotten out of it (possibly moving into R&D, data science, management, or independent consulting roles) or left the industry entirely. The culture of short-termism, open-plan offices, and business-driven engineering provides no exit. You don't get to escape it, in most companies, by being good at your job-- unless you become a manager. What's happening is that tech's "thought leaders" are creating conditions that are hostile to older talent (which is necessary if you want your technology to be any good) with "Agile"/Scrum micromanagement and bullpen office layouts, then saying, "See, no one over 40 is any good". (In fact, there are a lot of good people over 40; they just don't want to work for jackasses.) This is congealing into a pernicious cultural assumption, based on shitty data, when we should actually be blaming the VCs and the mediocre middle-managers-I-mean-founders they fund instead of "old programmers".

killface 12y ago

Shitty interviewers ask: 1. Anything related to trees 2. Big-O trivia and errata 3. Reinventing the wheel 4. Bit-twiddling operations Seriously. If I go into your interview and you ask me to reverse a string, and it's not <string>.reverse(), I'm not taking your stupid job. I don't care if you want me to know the tricks for an in-place string reverse with no temporary variables, that just shows that you don't have a clue how to interview. Good interviewers? The best I've found so far: 1. Ask people to do real-life problems 2. No "gotcha" questions 3. Let people use the environment they'll be using for the job -- this means an IDE, the internet (including stack overflow), and any library they want. What I want to see when I'm interviewing is whether or not you have the ability to solve a problem. I'm going to look at how you abstract and break down problems, how you solve them, and at what point you say, "I think this is done." Yes, I expect good engineers to know when to use a tree or a list or set -- but if you're explicitly quizzing for that, you're probably filtering in more terrible developers than you're filtering out.

balls187 12y ago
> Shitty interviewers ask: Google does none of what you prescribe for "good interviews" and they have interviewing down to a science. Yes they've admitted they err on false negatives, but that is acceptable because they have little to no false positives. From what I gather you want an easy interview. What you wrote is impractical (though I agree gotcha questions can be a bit much). As a candidate, I get 1-hour with you and I need to accomplish the following: 1. Does your resume reflect your experience? 2. Can you code? 3. What is it like to work with you to solve a challenge? 4. Sell you on joining us. Real life problems may fit in an hour, but may not. There are so many resources on programming interviews that spending an hour or two during the week prior would pay off dividends in a candidates success rate.
- deciplex 12y ago
  I interviewed with Google last year and the interviewer did two of the four things listed in killface's post. I actually do not agree with killface that those four things are necessarily bad (programmers should at least be able to make really good guesses at complexity, and know about trees), but at any rate, Google definitely had no fucking idea what my capabilities are as a developer after that interview, so incompetent was the interviewer. It was actually one of the more terrible interviews I've been a part of, and I was not disappointed by the negative result. Google certainly believes they have interviewing down to a science, but I suspect that belief is itself not scientific, and instead just the usual bullshit and collective delusion.

unoti 12y ago

Here's an often overlooked technique for older, self-taught engineers like me: study. Go get this book, The Algorithm Design Manual by Skienna. Also pick up a whiteboard, and a nice set of dry-erase markers. Read the book, and do whatever exercises you can from the book on the whiteboard. Talk out loud, the way you will in the interviews. After a few weeks and 60 hours of doing this, you'll be ready to blow the minds of the people interviewing you. When you go to your interview, you will bring your own markers. Then you don't have to deal with the fat, half dried out stuff you encounter during the interview. Also, warm up for an hour or two before you go to the interview, by doing problems from the book on the whiteboard, out loud. This helps you leave nothing to chance, and be ready for whatever they throw at you. Yeah, it's a waste of time. But you have to play the game. Similarly, when they ask you why you left your last job, lie and tell them you'd accomplished all your goals there, got everything lined up and nailed down, and you're ready to make something happen somewhere else. Don't tell the truth if it's because your managers couldn't care less about doing what's best for the business. If you want to work at the circus, sometimes you gotta jump through some hoops. Big deal, you'll be ok! Yes, the interview process is broken, but you can actually work at it and do well, even if you're old. Buy this book even if you're not planning to take my advice and study. Even if you don't study, this should become one of your most treasured books. I myself was amazed at how many things turn out to be graph problems, and had a great time going through this book. [1] http://www.amazon.com/Algorithm-Design-Manual-Steven-Skiena/dp/1849967202 http://www.amazon.com/Algorithm-Design-Manual-Steven-Skiena/...

balls187 12y ago
> Here's an often overlooked technique for [...] engineers like me: study. This is fantastic advice, for everyone. Preparing for interviews isn't wasted time, because ultimately the goal is to land a job that furthers your own personal goals in some fashion. I wouldn't recommend lying. If you're leaving a job, you should stand by your convictions. In my market, it's small and everyone knows everyone, so claiming you nailed everything down is easy enough to verify. Just remember one simple truth: "You are the only common link between all your failed jobs."
- 12y ago

swatow 12y ago

I think algorithmic interviews are good, because they are a kind of intelligence test. In spite of liberal dogma, some people are more talented and intellegent than others, and tests can shed light on this. However, the article does expose some flaws. Here are two bad kind of algorithm questions 1) Questions that rely too much on background knowledge. Knowing the exact properties or implementation of the more complex algorithms in the canon of undergraduate CS knowledge is not a particularly useful skill in itself. 2) Questions that have some trick that you either get or don't get. These aren't always terrible, but they give a big advantage to someone who has seen the question before. So what is a good algorithm based question? 1) Implementing something basic but non-trivial, like N-Queens with backtracking. Basically, something anyone should be able to do. 2) Something that mixes in domain knowledge. E.g. problems calculating probabilities than can be solved with dynamic programming. 3) Pure domain knowledge, but in programming form. E.g. how to implement k-means clustering.

dreamfactory2 12y ago

The main problem I see with technical interviews is that they are based on an assumption of individual technical knowledge adding value to an organisation. Working instead from an assumption that the whole is greater than sum when it comes to groups of people - I'd be far more interested in what a candidate is like to work with and what unique qualities they bring that we don't already have and which can act as a multiplier for the organisation.

richardjordan 12y ago

There's definitely inherent bias in much of the interviewing process, whether deliberate or not, for many tech startups. But there's also a high degree of bias once inside them. Older engineers with families often can't really do a team bonding that involves Saturday night playing games getting drunk and stoned, for example. Many startups, as they grow, provide things like health insurance plans optimized for 25 year old healthy males, that are just not that good for families and make it harder on older employees. And there are a lot of younger engineering managers who feel uncomfortable leading teams with older more experienced members in them. I've seen teams grow and older engineers pushed out for fairly arbitrary reasons, despite being good coders. And yes, even in this crazy environment where it's hard to hire. (And yes when I was young and early in my career I never really paid much attention to it and shrugged it off, but now it's my friends and I see myself getting up there in age now, it is so very obvious, and a lot more prevalent than I ever noticed.) When someone has nearly 20 years engineering experience (not talking about me, I don't) it is ridiculous to make them jump through some of these interviewing hoops. Sure, some kid fresh out of college might pad his resume - because there's not much to it. But an older veteran with a long resume, not so much. Experience does count. The ins and outs of the latest technology might vary slightly, but the patterns repeat. So much of engineering goes beyond the code on the screen anyway.