6 ms·

This is one of the many pernicious effects of the Standard Developer Interview™. Despite the fact that older developers may have years of proven experience at o

This is one of the many pernicious effects of the Standard Developer Interview™. Despite the fact that older developers may have years of proven experience at other companies, pretty much every interview goes in assuming the interviewee is no better qualified than a random person picked off of the street. Focusing so heavily on computer science trivia questions favor those who recently went to college, since those tidbits are so rarely needed at the drop of a hat in industry those neurons wither away with more time away from academia. Older developers know you can just look it up. Take home quizzes and side projects require significant time investments. People tend to have less free time as they get older due to family obligations, changing priorities, and so on. People directly out of college likely have less of these external time pressures and would have less of a problem solving your so-clever little project that only takes 20 hours. Until we, as an industry, get over the lie that hiring must be incredibly accurate and therefore favor the so-called "false negative", we won't get rid of this kind of discrimination and we'll continue to harm people simply because they're older; not to mention losing out on potential co-workers with a plethora of knowledge and experience. It's bizarre to me that ageism exists. Other forms of discrimination can be traced to othering someone because they are dissimilar to you. Every single human will become an older person one day, barring early death. Perpetuating this cycle is self defeating in the end.

vkou 9y ago
> This is one of the many pernicious effects of the Standard Developer Interview™. Despite the fact that older developers may have years of proven experience at other companies, pretty much every interview goes in assuming the interviewee is no better qualified than a random person picked off of the street. Many people who interview feel like random people off the street. You really can't tell if the resume's completely bullshit until you ask them to sit down and implement fizz-buzz. > Focusing so heavily on computer science trivia questions favor those who recently went to college, since those tidbits are so rarely needed at the drop of a hat in industry those neurons wither away with more time away from academia. Older developers know you can just look it up. Is this still a common practice? Neither Facebook, Google, nor Amazon trains its interviewers to ask bullshit trivia questions to non-intern candidates (I don't know if they train them to ask, or not ask those questions to intern candidates.) I mean, it's entirely possible that particular interviewers at those companies do, but I have skimmed through many, many interview transcripts. None of them focused on bullshit trivia. (Unless you feel that 'Is it possible to have a memory leak in a language like Java or C#?' is bullshit trivia. I've had people who have spent five years programming in those languages answer, with full conviction, 'No'. After some more prodding, they sometimes say yes, if there was a bug in the garbage collector.) At this point, this feels like a meme that has been ten years out of date (Because all it takes is one person having a bad interview experience to revive it.)
- jquery 9y ago
  It’s not a meme. I just interviewed at FB (3 onsites) and the one interview that sunk me was a CS-algo question. I’ve never had to do that my entire career and I even though I got the answer in the end, I was told afterwards that my answer was too slow. The other tech interviews focused on real web dev experience I destroyed. Still got rejected even though I answered every question correctly, just not fast (or optimal?) enough. The recruiter said I was a “great culture fit” afterwards so that wasn’t the issue. You wouldn’t consider the question “trivia” because it was something you might do once or twice in an entire web dev career. But it’s still a question that will favor new grads who have been trained to pattern match algos and share questions amongst each other. So even if there’s not explicit bias against older devs there is implicit bias by favoring quick whiteboard speed (memorization/practice) over the practiced thoughtfulness of older devs. And a one-off interview focused heavily on algos can sink anyone. It only takes one. This isn’t limited to FB. The $Elite companies I got offers from are the ones where I lucked through that one tricky interview by knowing it offhand. I worry as I get older, even as I become a stronger developer, I will become less and less able to marathon through these interviews. No wonder so many older devs switch to management.
  - vkou 9y ago
    There's a world of difference between remember some bullshit trivia about how to do fast matrix multiplication, that requires some esoteric algorithmic or mathematical trick, and 'implement a data structure that does X'. Yet, when blasting interviews, I have found that people tend to conflate the two. I agree that 60 minutes on a whiteboard or a laptop is not the best way to ask someone to solve a coding problem. Homework is worse, though. Maybe 90 minutes is a better time slot.
    - jquery 9y ago
      There’s a middle ground between those two which usually ends up being the one tricky question—there’s only one right answer and the task is something non-straightforward. I find junior devs to be far more likely to ask this type of question.
    - 9y ago
erik_seaberg 9y ago
My proven experience only counts if you trust the people I proved it to. If my references are your drinking buddies, sure, you can probably skip the interview, but when it's a stranger I could have coached an actor for all you know.
- jakebasile 9y ago
  What is the end game in this hypothetical fraud situation? - Fraudster gets hired and cannot do the job. They get let go. - Fraudster gets hired and can do the job. No harm. - Fraudster gets hired and can kind of do the job. They get placed on a performance improvement plan, and you train them until they either can or cannot do the job. Think of this from the perspective of both parties. I think the risk of this type of bad actor is wildly overstated.
  - nicolashahn 9y ago
    In scenario 1, fraudster is also getting paid, ties up members of your team attempting to train them, and your timeline of getting an actual hire is pushed out until the company figures out they messed up. Seems worth the effort to prevent.
    - jakebasile 9y ago
      Some effort? Sure. Raking prospects over coals in discriminatory interviews that don’t actually test for coding ability? Nah. Bad hires are bad, not disastrous and the response in the industry is wildly out of proportion.
  - mythrwy 9y ago
    -Fraudster gets hired and starts committing code. There is some disagreement as to whether the fraudster is a fraudster or not, but the non-technical boss sure loves him and they often go to lunch together. More code committed. Then he starts making major design decisions.
    - jakebasile 9y ago
CodeMage 9y ago
Not that I disagree with all of your points, but I can't say I've seen any evidence that there is such a thing as Standard Developer Interview™. Over the past month, I've been interviewing with 8 different companies, 3 of which are in the game development industry. They have all had substantially different approaches to their recruitment process and interviewing. I've identified some common elements, but each of the companies mixed and matched them in different ways and degrees. The techniques used were: - timed online test (e.g. HackerRank or Codility), reviewed later by the team - online, real-time coding during the phone screen (e.g. HackerRank or CollabEdit) - take-home project with a deadline (usually up to 2 weeks), reviewed later by the team - phone, video-conference or on-site discussion about employment history and experience - phone, video-conference or on-site discussion about technical problems - on-site whiteboard coding - on-site coding on company-provided box - on-site coding on candidate's own box - coffee-shop conversation about behavioral topics The topics for technical discussions were: - algorithms, data structures and complexity (big-O notation, trees, hash tables, lists, circular buffers, breadth-first and depth-first traversal, binary search, recursion) - scalability (caching, load-balancing, sharding) - concurrency (locks, conditional variables, contention, memory fences) - mathematics (vectors and matrices, linear algebra, computational geometry, combinatorics and probability) - low-level concepts (manual memory management, cache locality, specifics of garbage collection, VMTs in C++) - object-oriented design (inheritance, polymorphism, fragile base class, composition over inheritance) - API design (specifying constraints, changing API based on requirement changes, paging results, increasing or decreasing operation granularity) Now, I know that this is just 8 companies. I know that this is a drop in the ocean. I know that the plural of "anecdote" is not "data". But over and over again, I've seen the same claim on HN: our industry focuses too much on computer science "trivia" questions. For an audience that usually requires quality, sourced data to support arguments, we seem to be awfully quick to draw generalized conclusions about this specific topic.

vkou 9y ago

> This is one of the many pernicious effects of the Standard Developer Interview™. Despite the fact that older developers may have years of proven experience at other companies, pretty much every interview goes in assuming the interviewee is no better qualified than a random person picked off of the street. Many people who interview feel like random people off the street. You really can't tell if the resume's completely bullshit until you ask them to sit down and implement fizz-buzz. > Focusing so heavily on computer science trivia questions favor those who recently went to college, since those tidbits are so rarely needed at the drop of a hat in industry those neurons wither away with more time away from academia. Older developers know you can just look it up. Is this still a common practice? Neither Facebook, Google, nor Amazon trains its interviewers to ask bullshit trivia questions to non-intern candidates (I don't know if they train them to ask, or not ask those questions to intern candidates.) I mean, it's entirely possible that particular interviewers at those companies do, but I have skimmed through many, many interview transcripts. None of them focused on bullshit trivia. (Unless you feel that 'Is it possible to have a memory leak in a language like Java or C#?' is bullshit trivia. I've had people who have spent five years programming in those languages answer, with full conviction, 'No'. After some more prodding, they sometimes say yes, if there was a bug in the garbage collector.) At this point, this feels like a meme that has been ten years out of date (Because all it takes is one person having a bad interview experience to revive it.)

jquery 9y ago
It’s not a meme. I just interviewed at FB (3 onsites) and the one interview that sunk me was a CS-algo question. I’ve never had to do that my entire career and I even though I got the answer in the end, I was told afterwards that my answer was too slow. The other tech interviews focused on real web dev experience I destroyed. Still got rejected even though I answered every question correctly, just not fast (or optimal?) enough. The recruiter said I was a “great culture fit” afterwards so that wasn’t the issue. You wouldn’t consider the question “trivia” because it was something you might do once or twice in an entire web dev career. But it’s still a question that will favor new grads who have been trained to pattern match algos and share questions amongst each other. So even if there’s not explicit bias against older devs there is implicit bias by favoring quick whiteboard speed (memorization/practice) over the practiced thoughtfulness of older devs. And a one-off interview focused heavily on algos can sink anyone. It only takes one. This isn’t limited to FB. The $Elite companies I got offers from are the ones where I lucked through that one tricky interview by knowing it offhand. I worry as I get older, even as I become a stronger developer, I will become less and less able to marathon through these interviews. No wonder so many older devs switch to management.
- vkou 9y ago
  There's a world of difference between remember some bullshit trivia about how to do fast matrix multiplication, that requires some esoteric algorithmic or mathematical trick, and 'implement a data structure that does X'. Yet, when blasting interviews, I have found that people tend to conflate the two. I agree that 60 minutes on a whiteboard or a laptop is not the best way to ask someone to solve a coding problem. Homework is worse, though. Maybe 90 minutes is a better time slot.
  - jquery 9y ago
    There’s a middle ground between those two which usually ends up being the one tricky question—there’s only one right answer and the task is something non-straightforward. I find junior devs to be far more likely to ask this type of question.
  - 9y ago

erik_seaberg 9y ago

My proven experience only counts if you trust the people I proved it to. If my references are your drinking buddies, sure, you can probably skip the interview, but when it's a stranger I could have coached an actor for all you know.

jakebasile 9y ago
What is the end game in this hypothetical fraud situation? - Fraudster gets hired and cannot do the job. They get let go. - Fraudster gets hired and can do the job. No harm. - Fraudster gets hired and can kind of do the job. They get placed on a performance improvement plan, and you train them until they either can or cannot do the job. Think of this from the perspective of both parties. I think the risk of this type of bad actor is wildly overstated.
- nicolashahn 9y ago
  In scenario 1, fraudster is also getting paid, ties up members of your team attempting to train them, and your timeline of getting an actual hire is pushed out until the company figures out they messed up. Seems worth the effort to prevent.
  - jakebasile 9y ago
    Some effort? Sure. Raking prospects over coals in discriminatory interviews that don’t actually test for coding ability? Nah. Bad hires are bad, not disastrous and the response in the industry is wildly out of proportion.
- mythrwy 9y ago
  -Fraudster gets hired and starts committing code. There is some disagreement as to whether the fraudster is a fraudster or not, but the non-technical boss sure loves him and they often go to lunch together. More code committed. Then he starts making major design decisions.
  - jakebasile 9y ago

CodeMage 9y ago

Not that I disagree with all of your points, but I can't say I've seen any evidence that there is such a thing as Standard Developer Interview™. Over the past month, I've been interviewing with 8 different companies, 3 of which are in the game development industry. They have all had substantially different approaches to their recruitment process and interviewing. I've identified some common elements, but each of the companies mixed and matched them in different ways and degrees. The techniques used were: - timed online test (e.g. HackerRank or Codility), reviewed later by the team - online, real-time coding during the phone screen (e.g. HackerRank or CollabEdit) - take-home project with a deadline (usually up to 2 weeks), reviewed later by the team - phone, video-conference or on-site discussion about employment history and experience - phone, video-conference or on-site discussion about technical problems - on-site whiteboard coding - on-site coding on company-provided box - on-site coding on candidate's own box - coffee-shop conversation about behavioral topics The topics for technical discussions were: - algorithms, data structures and complexity (big-O notation, trees, hash tables, lists, circular buffers, breadth-first and depth-first traversal, binary search, recursion) - scalability (caching, load-balancing, sharding) - concurrency (locks, conditional variables, contention, memory fences) - mathematics (vectors and matrices, linear algebra, computational geometry, combinatorics and probability) - low-level concepts (manual memory management, cache locality, specifics of garbage collection, VMTs in C++) - object-oriented design (inheritance, polymorphism, fragile base class, composition over inheritance) - API design (specifying constraints, changing API based on requirement changes, paging results, increasing or decreasing operation granularity) Now, I know that this is just 8 companies. I know that this is a drop in the ocean. I know that the plural of "anecdote" is not "data". But over and over again, I've seen the same claim on HN: our industry focuses too much on computer science "trivia" questions. For an audience that usually requires quality, sourced data to support arguments, we seem to be awfully quick to draw generalized conclusions about this specific topic.