5 ms·

I spent most of my college evening getting drunk with philosophy majors and pretending my math degree meant more than my CS fallback -- but I haven't found the

I spent most of my college evening getting drunk with philosophy majors and pretending my math degree meant more than my CS fallback -- but I haven't found the corporate interview system to be that terrible. I do however think it's a game that conflicts with certain personality types, including myself early in my career. I'm always curious what you (or anyone else!) think could be done better.

hinkley 8y ago
The all day interview process selects for a kind of person who is confortable with arduous processes. With poor scalability. IMO any team with an SLA should be avoiding these people like the plague, because they will tolerate bullshit manual processes that take all day. They have no motivation to make foolproof automated processes with good visibility and repeatability. The smartest of them will fight attempts to change the status quo because the status quo makes them look good and everybody else look like idiots. Three of my favorite bosses were from the Fire All Heroes school of management. Two actually gave a speech to that effect in front of the entire engineering dept. They helped me get out of the hero racket. It’s great to be needed. But it sucks being the bottleneck.
- timr 8y ago
  My problem is that it's all cargo cult, and none of it is rationally thought through to pursue desirable qualities in an engineer. Even within Google, Facebook, Amazon, and Microsoft, you're usually being interviewed by a fresh-out-of-school 20-something who has no idea how to do much of anything, let alone evaluate candidates fairly. And yes, they "train" these kids -- but you basically can't train someone to do something that relies heavily on intuition. That requires experience, but 20-somethings don't have experience. So instead, they're "trained" to do the one thing you can do repeatably: ask coding puzzle questions from a book, and reject anyone who doesn't regurgitate answers with 100% fidelity. It's the McDonald's food of interviewing: not the best (or even good), but consistent across a large organization. Sort of. So while big companies need people who can work on a team, exercise good judgment, communicate clearly, write clean code and not be racist/sexist/evil jerks, they get...people who can memorize questions from a big book of programming questions. I can easily come up with tests that get to each of those properties...but they rely on interviewers having good judgment, and most do not.
  - hinkley 8y ago
    I get itchy when I get asked to write code that I would veto in a code review. My internal dialog when asked things like a linked list or a hash table is "Oh god, does this mean they like code like this? I bet some 'clever person' at this company wrote their own hash table/event queue/template engine* and forces everybody else to use it." * Unfortunately my current employer is just like this but I didn't pick up on that in the interview process.
    - IggleSniggle 8y ago
      You and me both. And it feeds itself, too, because every line of code is an opportunity to reinvent the wheel or do something clever (it sometimes seems like they want to see that, or else this class of question wouldn’t be asked??).
- mcguire 8y ago
  The downsides of avoiding the algorithmic interview process is that you will end up hiring people who talk a very good game, but cannot write code to get out of a paper bag. One of the most painful interviews I have ever seen was a guy who had a resume listing a number of interesting projects. He could talk energetically and in detail about them. Then we asked him to write some code to solve a simple problem. He said he didn't know our primary language, but was very familiar with Python. I know Python, I was good with that. He didn't know Python. I tried to help him, but he didn't get much farther. I eventually called the interview, with a complete 180 of my hiring opinion. Nice guy, but he couldn't be what we needed.
  - hodgesrm 8y ago
    This is a real problem. If you are hiring coders you have to have a couple people in the team go deep on coding chops to ferret out the charlatans. Personally I like to show people a piece of code from a big system they've never seen and let them walk me through what it does and what they would change to make it work better. Some teams I work with also give 'homework' exercises, which I believe is fairer than trying to do it in front of somebody else. (Unless that's how you actually write code on a day to day basis.) Good interview processes reflect complementary broad and deep concerns. It's kind of analogous to the way a strong team is better than the sum its parts.
    - evacchi 8y ago
      > Personally I like to show people a piece of code from a big system they've never seen and let them walk me through what it does and what they would change to make it work better. This could be the first coding interview style that actually makes sense to me
  - gbear605 8y ago
    You can easily do programming problems without algorithm questions.
  - hinkley 8y ago
    I don’t think I’m against the algorithm part as strenuously as I am against the gauntlet part. You shouldn’t be locking someone in a room for 6-7 hours and then judging them on how they keep their cool, for many reasons, including those I mentioned above. As I mentioned elsewhere I think you can ask questions that look like work but aren’t (go too far the other way and you’re into IP problems)
- fooddood 8y ago
  Can you please elaborate more on the Fire All Heroes philosophy? I looked into it and couldn't find anything describing it in depth
  - hinkley 8y ago
    I’ve only met a couple people who say “fire”. That’s a little overwrought. The less dramatic version is “we are too big for heroes” which unpacks into something like this: You don’t want an organization that relies on one or two or three people to swoop in and save the company every time there’s an emergency. A production issue should look like disaster preparedness. Document, train, drill, prevent. More concretely, make the important parts as obvious as you can, as similar to production as you can, so anyone can set up a system and try to repro the problem. Config, build, and deploy should be push button (very robust scripts with every cheap sanity and safety check you can manage). No flakiness is okay. Nor obscurity. Everybody should understand how it works. Document everywhere diagnostic data comes from and goes to. Don’t let your most senior people solve production issues; assign them to people one step down (and throw in some promising mid-level team members for diversity and longevity). Five why’s every outage and be sure your resolutions always involve making the problem easier to detect next time, not just prevent.
    - fooddood 8y ago
      Thank you! That was a great explanation. I like it wrapped up in such a memorable phrase
hodgesrm 8y ago
In my experience SV corporate interview processes are biased in a couple of ways that lead to more homogeneneous and potentially weaker teams. 1.) They select using criteria that are easy to test, such as writing quicksort on the fly. That's a small part of engineering --you also want people who can recognize big-picture patterns and communicate them clearly. This is a lot harder to evaluate so many interviewers simply don't. 2.) They select for people who are already in similar positions. For instance, white-boarding kubernetes application design is pretty easy if you are already doing it. As an interviewer it does not really tell me much about your ability to think originally or whether you can adapt. Getting around these biases is hard. One way I test people now is to ask them to show me their favorite design or code and explain exactly how it works. That starts them off on comfortable ground. Then I start to tweak the boundary conditions to see if they can adjust creatively. It removes the stress factor and is a lot more illuminating than coding up something totally new from scratch, especially if you only have 45 minutes to extract as much information as possible about somebody's thought processes. Very interested in other thoughts on this topic. It's a hard problem.

hinkley 8y ago

The all day interview process selects for a kind of person who is confortable with arduous processes. With poor scalability. IMO any team with an SLA should be avoiding these people like the plague, because they will tolerate bullshit manual processes that take all day. They have no motivation to make foolproof automated processes with good visibility and repeatability. The smartest of them will fight attempts to change the status quo because the status quo makes them look good and everybody else look like idiots. Three of my favorite bosses were from the Fire All Heroes school of management. Two actually gave a speech to that effect in front of the entire engineering dept. They helped me get out of the hero racket. It’s great to be needed. But it sucks being the bottleneck.

timr 8y ago
My problem is that it's all cargo cult, and none of it is rationally thought through to pursue desirable qualities in an engineer. Even within Google, Facebook, Amazon, and Microsoft, you're usually being interviewed by a fresh-out-of-school 20-something who has no idea how to do much of anything, let alone evaluate candidates fairly. And yes, they "train" these kids -- but you basically can't train someone to do something that relies heavily on intuition. That requires experience, but 20-somethings don't have experience. So instead, they're "trained" to do the one thing you can do repeatably: ask coding puzzle questions from a book, and reject anyone who doesn't regurgitate answers with 100% fidelity. It's the McDonald's food of interviewing: not the best (or even good), but consistent across a large organization. Sort of. So while big companies need people who can work on a team, exercise good judgment, communicate clearly, write clean code and not be racist/sexist/evil jerks, they get...people who can memorize questions from a big book of programming questions. I can easily come up with tests that get to each of those properties...but they rely on interviewers having good judgment, and most do not.
- hinkley 8y ago
  I get itchy when I get asked to write code that I would veto in a code review. My internal dialog when asked things like a linked list or a hash table is "Oh god, does this mean they like code like this? I bet some 'clever person' at this company wrote their own hash table/event queue/template engine* and forces everybody else to use it." * Unfortunately my current employer is just like this but I didn't pick up on that in the interview process.
  - IggleSniggle 8y ago
    You and me both. And it feeds itself, too, because every line of code is an opportunity to reinvent the wheel or do something clever (it sometimes seems like they want to see that, or else this class of question wouldn’t be asked??).
mcguire 8y ago
The downsides of avoiding the algorithmic interview process is that you will end up hiring people who talk a very good game, but cannot write code to get out of a paper bag. One of the most painful interviews I have ever seen was a guy who had a resume listing a number of interesting projects. He could talk energetically and in detail about them. Then we asked him to write some code to solve a simple problem. He said he didn't know our primary language, but was very familiar with Python. I know Python, I was good with that. He didn't know Python. I tried to help him, but he didn't get much farther. I eventually called the interview, with a complete 180 of my hiring opinion. Nice guy, but he couldn't be what we needed.
- hodgesrm 8y ago
  This is a real problem. If you are hiring coders you have to have a couple people in the team go deep on coding chops to ferret out the charlatans. Personally I like to show people a piece of code from a big system they've never seen and let them walk me through what it does and what they would change to make it work better. Some teams I work with also give 'homework' exercises, which I believe is fairer than trying to do it in front of somebody else. (Unless that's how you actually write code on a day to day basis.) Good interview processes reflect complementary broad and deep concerns. It's kind of analogous to the way a strong team is better than the sum its parts.
  - evacchi 8y ago
    > Personally I like to show people a piece of code from a big system they've never seen and let them walk me through what it does and what they would change to make it work better. This could be the first coding interview style that actually makes sense to me
- gbear605 8y ago
  You can easily do programming problems without algorithm questions.
- hinkley 8y ago
  I don’t think I’m against the algorithm part as strenuously as I am against the gauntlet part. You shouldn’t be locking someone in a room for 6-7 hours and then judging them on how they keep their cool, for many reasons, including those I mentioned above. As I mentioned elsewhere I think you can ask questions that look like work but aren’t (go too far the other way and you’re into IP problems)
fooddood 8y ago
Can you please elaborate more on the Fire All Heroes philosophy? I looked into it and couldn't find anything describing it in depth
- hinkley 8y ago
  I’ve only met a couple people who say “fire”. That’s a little overwrought. The less dramatic version is “we are too big for heroes” which unpacks into something like this: You don’t want an organization that relies on one or two or three people to swoop in and save the company every time there’s an emergency. A production issue should look like disaster preparedness. Document, train, drill, prevent. More concretely, make the important parts as obvious as you can, as similar to production as you can, so anyone can set up a system and try to repro the problem. Config, build, and deploy should be push button (very robust scripts with every cheap sanity and safety check you can manage). No flakiness is okay. Nor obscurity. Everybody should understand how it works. Document everywhere diagnostic data comes from and goes to. Don’t let your most senior people solve production issues; assign them to people one step down (and throw in some promising mid-level team members for diversity and longevity). Five why’s every outage and be sure your resolutions always involve making the problem easier to detect next time, not just prevent.
  - fooddood 8y ago
    Thank you! That was a great explanation. I like it wrapped up in such a memorable phrase

hodgesrm 8y ago

In my experience SV corporate interview processes are biased in a couple of ways that lead to more homogeneneous and potentially weaker teams. 1.) They select using criteria that are easy to test, such as writing quicksort on the fly. That's a small part of engineering --you also want people who can recognize big-picture patterns and communicate them clearly. This is a lot harder to evaluate so many interviewers simply don't. 2.) They select for people who are already in similar positions. For instance, white-boarding kubernetes application design is pretty easy if you are already doing it. As an interviewer it does not really tell me much about your ability to think originally or whether you can adapt. Getting around these biases is hard. One way I test people now is to ask them to show me their favorite design or code and explain exactly how it works. That starts them off on comfortable ground. Then I start to tweak the boundary conditions to see if they can adjust creatively. It removes the stress factor and is a lot more illuminating than coding up something totally new from scratch, especially if you only have 45 minutes to extract as much information as possible about somebody's thought processes. Very interested in other thoughts on this topic. It's a hard problem.