4 ms·

Every few weeks, someone posts an article about how broken tech interviews are, and the articles always follow the same formula: but I’m really good at REAL eng

Every few weeks, someone posts an article about how broken tech interviews are, and the articles always follow the same formula: but I’m really good at REAL engineering… it’s the INTERVIEWS that are wrong! It sounds like the author may have faced a bad interviewer, but I’d be curious to see their feedback on the author so we get both sides. As I comment each time: you’re not being asked to sort a million item array because it represents the job, you’re being asked to sort a million item array because I want to see how you think, how you solve problems, and how good your underlying CS fundamentals are. Yes - that means regardless of seniority, I expect you to know CAP theorem. Sure, knowing CAP theorem does not imply you are a good engineer, but being a good engineer DOES imply you know CAP theorem. The job will change from project to project, but the CS skills should carry through.

wakawaka28 1y ago
>Yes - that means regardless of seniority, I expect you to know CAP theorem. Sure, knowing CAP theorem does not imply you are a good engineer, but being a good engineer DOES imply you know CAP theorem. There are lots of good engineers who don't encounter this, but who will understand the CAP theorem to the same level you and most other people you consider "good engineers" do, after simply reading the top of the Wikipedia article about it. Ultimately you need to be the kind of person who can understand such a thing to be a good engineer, not someone who knows any particular random thing. On the other hand I would like to know that the candidate knows the CAP theorem if we are working on a distributed database or massive web service. In that case it is actually relevant. >Every few weeks, someone posts an article about how broken tech interviews are, and the articles always follow the same formula: but I’m really good at REAL engineering… it’s the INTERVIEWS that are wrong! Interviewing is mostly a different skillset from day to day work. That is why everyone complains about it. Knowing that you are good at the job you're applying for, perhaps better than the smug interviewer, yet blocked because you can't produce an optimal solution to their puzzle (that they probably stole from someone else and/or could not solve themselves in an interview), is hella frustrating. If you urgently need a job, it is even worse.
- Esophagus4 1y ago
  > Interviewing is mostly a different skillset from day to day work. It’s not, really: this could be true if your day to day work is writing very basic websites without real performance or scale constraints, but if you are building large, performant systems, a good technical interview will give you a chance to show those skills. There are plenty of places that have lower bars for hiring if you can call a JSON API in Python and run some Linux commands - but for the places everyone wants to work, you should expect a high bar. And that’s a good thing! A players want to work with A players. I would not want to work at a place that has a low technical bar for hiring. > Knowing that you are good at the job you're applying for, perhaps better than the smug interviewer, yet blocked because you can't produce an optimal solution to their puzzle (that they probably stole from someone else and/or could not solve themselves in an interview) It goes without saying that interviewer successfully passed that interview process to get hired there. So they have demonstrated at some point that they can do the problems they’re asking you to do. Blowing a technical interview sucks, I get it - I have blown dozens of them. It’s humiliating, I’m aware, and so people find all sorts of copes (I would’ve been better than my interviewer at the actual job if I had just been given a chance! They couldn’t solve that problem anyway!) but they don’t want people that can just do the job - they want really talented engineers that can grow with the company and build all sorts of things. Being a good engineer does not imply you’ll pass the interview (there are plenty of reasons good engineers fail interviews) but passing an interview does imply you’re a good engineer. (Edit: I’m assuming the interviewer is competent.) And that’s the point: hiring a bad engineer is one of the worst mistakes a company can make. They’re expensive, take a long time to manage out, drain team productivity and morale, and can destabilize systems. You want a process that would rather say no to a good engineer than say yes to a bad one.
  - barchar 1y ago
    > It goes without saying that interviewer successfully passed that interview process to get hired there It does not. Also, even at the places with the most consistent interviews difficulty is pretty all over the place (or questions are well-known). Anyway, for me the answer to my interviewing woes was a propranolol prescription
  - 1y ago
siva7 1y ago
> Sure, knowing CAP theorem does not imply you are a good engineer, but being a good engineer DOES imply you know CAP theorem. Eh, no it doesn't? I guess it's one of those questions - what makes a good software engineer - that people will never universally agree on like many other topics in the field but still think their own truth is universal.
- Esophagus4 1y ago
  Those that don’t know CS fundamentals end up making bad technology decisions. I can’t tell you the number of times I’ve failed a “senior” level engineer because when I asked, “Tell me why you chose X database on Y project,” the only thing they could come up with was, “Well, we were storing JSON data, so we used Mongo.” I don’t want to be left cleaning up the mess that guy makes.
Herring 1y ago
The interviews are wrong. Check with your favorite frontier LLM. There has been a lot of research on what's predictive for job performance and what's not, but it's largely ignored. An easy example: Google's "Project Aristotle" - https://psychsafety.com/googles-project-aristotle/ https://psychsafety.com/googles-project-aristotle/ tl;dr: psychological safety was the determining factor of highly effective teams. Then Google goes and does large-scale layoffs. Think about your workplace, do you feel safe? Do you think these interviews help people feel safe?
- Esophagus4 1y ago
  Great idea. So we’ll do both: have a high bar for technical interviews and a culture of psychological safety. That should be the best of all worlds and create a high performing team. I’m not sure your point here. Yes, high performing teams have psychological safety.
  - Herring 1y ago
    Ironically, that's my point right there. Zero real thought, zero follow-through. There's plenty of research but nope, it's all vibes no data.
sharts 1y ago
The problem is you want a proxy for that which you really can’t evaluate and you think the proxy is accurate because it provides some feel-good binary. Fundamentally, you can’t really figure out the things you are interested that way. This is the underlying problem with tech and CS bros which results in the broken system being even more broken. If anything these types of interviews are really only to validate the interviewers bias which is that they think they are smarter than everyone else and anyone else that came before them. Otherwise why would they have been entrusted to being the gatekeeper of shiny job and privilege to work along the interviewer. One may as well just defer to SAT scores, GPA, or the fact that a person actually graduated from a reputable CS program, or dare we say, the fact that a person actually had the same or similar jobs successfully over many years. The reason people bomb these are precisely because they don’t need to exercise that “deep knowledge” that often in the first place. It doesn’t mean they aren’t capable it just means they’ll need to walk thru it longer than possible in a contrived situation. And the fact that they haven’t needed it is telling —these jobs aren’t really hitting the edge of CS research; it’s just a CRUD app. The autists need to get off their high ponies and look at every other professional industry out there. Those industries have smart people too. Somehow humanity survives and the industry evolves…go figure.
- Esophagus4 1y ago
  > you think the proxy is accurate because it provides some feel-good binary. Having run this “proxy” process for years now, I can tell you it is, in fact, the most accurate indicator I have seen of software engineering capabilities. If you prefer, there are absolutely companies that don’t use the process, and they’ll hire you after a quick resume conversation. Frankly, I wouldn’t want to work there, having seen the abysmally bad talent hired through lax processes, but Godspeed if that’s where you want to work. > the fact that a person actually had the same or similar jobs successfully over many years. No matter how good you think you are, if you can’t pass a basic live coding exercise, you have no place on my team. …You’re not being asked to invert a binary tree in 20 minutes with your eyes closed, you’re being asked to traverse a string and use a set. Stop whining.
  - johnsmith1840 1y ago
ponector 1y ago
>>>Yes - that means regardless of seniority, I expect you to know CAP theorem You can have the same result asking for a chess.com score. Anyone with score lower than 1400 is a bad engineer. I'm sure you'll have even better results than asking some CS theorems.
- Esophagus4 1y ago
  Why is expecting senior engineers to have an understanding of, frankly, basic fundamentals of how computers work is so upsetting to you? If you want to hire and work with people who don’t know those, by all means, hire them… I certainly won’t stop you.

wakawaka28 1y ago

>Yes - that means regardless of seniority, I expect you to know CAP theorem. Sure, knowing CAP theorem does not imply you are a good engineer, but being a good engineer DOES imply you know CAP theorem. There are lots of good engineers who don't encounter this, but who will understand the CAP theorem to the same level you and most other people you consider "good engineers" do, after simply reading the top of the Wikipedia article about it. Ultimately you need to be the kind of person who can understand such a thing to be a good engineer, not someone who knows any particular random thing. On the other hand I would like to know that the candidate knows the CAP theorem if we are working on a distributed database or massive web service. In that case it is actually relevant. >Every few weeks, someone posts an article about how broken tech interviews are, and the articles always follow the same formula: but I’m really good at REAL engineering… it’s the INTERVIEWS that are wrong! Interviewing is mostly a different skillset from day to day work. That is why everyone complains about it. Knowing that you are good at the job you're applying for, perhaps better than the smug interviewer, yet blocked because you can't produce an optimal solution to their puzzle (that they probably stole from someone else and/or could not solve themselves in an interview), is hella frustrating. If you urgently need a job, it is even worse.

Esophagus4 1y ago
> Interviewing is mostly a different skillset from day to day work. It’s not, really: this could be true if your day to day work is writing very basic websites without real performance or scale constraints, but if you are building large, performant systems, a good technical interview will give you a chance to show those skills. There are plenty of places that have lower bars for hiring if you can call a JSON API in Python and run some Linux commands - but for the places everyone wants to work, you should expect a high bar. And that’s a good thing! A players want to work with A players. I would not want to work at a place that has a low technical bar for hiring. > Knowing that you are good at the job you're applying for, perhaps better than the smug interviewer, yet blocked because you can't produce an optimal solution to their puzzle (that they probably stole from someone else and/or could not solve themselves in an interview) It goes without saying that interviewer successfully passed that interview process to get hired there. So they have demonstrated at some point that they can do the problems they’re asking you to do. Blowing a technical interview sucks, I get it - I have blown dozens of them. It’s humiliating, I’m aware, and so people find all sorts of copes (I would’ve been better than my interviewer at the actual job if I had just been given a chance! They couldn’t solve that problem anyway!) but they don’t want people that can just do the job - they want really talented engineers that can grow with the company and build all sorts of things. Being a good engineer does not imply you’ll pass the interview (there are plenty of reasons good engineers fail interviews) but passing an interview does imply you’re a good engineer. (Edit: I’m assuming the interviewer is competent.) And that’s the point: hiring a bad engineer is one of the worst mistakes a company can make. They’re expensive, take a long time to manage out, drain team productivity and morale, and can destabilize systems. You want a process that would rather say no to a good engineer than say yes to a bad one.
- barchar 1y ago
  > It goes without saying that interviewer successfully passed that interview process to get hired there It does not. Also, even at the places with the most consistent interviews difficulty is pretty all over the place (or questions are well-known). Anyway, for me the answer to my interviewing woes was a propranolol prescription
- 1y ago

siva7 1y ago

> Sure, knowing CAP theorem does not imply you are a good engineer, but being a good engineer DOES imply you know CAP theorem. Eh, no it doesn't? I guess it's one of those questions - what makes a good software engineer - that people will never universally agree on like many other topics in the field but still think their own truth is universal.

Esophagus4 1y ago
Those that don’t know CS fundamentals end up making bad technology decisions. I can’t tell you the number of times I’ve failed a “senior” level engineer because when I asked, “Tell me why you chose X database on Y project,” the only thing they could come up with was, “Well, we were storing JSON data, so we used Mongo.” I don’t want to be left cleaning up the mess that guy makes.

Herring 1y ago

The interviews are wrong. Check with your favorite frontier LLM. There has been a lot of research on what's predictive for job performance and what's not, but it's largely ignored. An easy example: Google's "Project Aristotle" - https://psychsafety.com/googles-project-aristotle/ https://psychsafety.com/googles-project-aristotle/ tl;dr: psychological safety was the determining factor of highly effective teams. Then Google goes and does large-scale layoffs. Think about your workplace, do you feel safe? Do you think these interviews help people feel safe?

Esophagus4 1y ago
Great idea. So we’ll do both: have a high bar for technical interviews and a culture of psychological safety. That should be the best of all worlds and create a high performing team. I’m not sure your point here. Yes, high performing teams have psychological safety.
- Herring 1y ago
  Ironically, that's my point right there. Zero real thought, zero follow-through. There's plenty of research but nope, it's all vibes no data.

sharts 1y ago

The problem is you want a proxy for that which you really can’t evaluate and you think the proxy is accurate because it provides some feel-good binary. Fundamentally, you can’t really figure out the things you are interested that way. This is the underlying problem with tech and CS bros which results in the broken system being even more broken. If anything these types of interviews are really only to validate the interviewers bias which is that they think they are smarter than everyone else and anyone else that came before them. Otherwise why would they have been entrusted to being the gatekeeper of shiny job and privilege to work along the interviewer. One may as well just defer to SAT scores, GPA, or the fact that a person actually graduated from a reputable CS program, or dare we say, the fact that a person actually had the same or similar jobs successfully over many years. The reason people bomb these are precisely because they don’t need to exercise that “deep knowledge” that often in the first place. It doesn’t mean they aren’t capable it just means they’ll need to walk thru it longer than possible in a contrived situation. And the fact that they haven’t needed it is telling —these jobs aren’t really hitting the edge of CS research; it’s just a CRUD app. The autists need to get off their high ponies and look at every other professional industry out there. Those industries have smart people too. Somehow humanity survives and the industry evolves…go figure.

Esophagus4 1y ago
> you think the proxy is accurate because it provides some feel-good binary. Having run this “proxy” process for years now, I can tell you it is, in fact, the most accurate indicator I have seen of software engineering capabilities. If you prefer, there are absolutely companies that don’t use the process, and they’ll hire you after a quick resume conversation. Frankly, I wouldn’t want to work there, having seen the abysmally bad talent hired through lax processes, but Godspeed if that’s where you want to work. > the fact that a person actually had the same or similar jobs successfully over many years. No matter how good you think you are, if you can’t pass a basic live coding exercise, you have no place on my team. …You’re not being asked to invert a binary tree in 20 minutes with your eyes closed, you’re being asked to traverse a string and use a set. Stop whining.
- johnsmith1840 1y ago

ponector 1y ago

>>>Yes - that means regardless of seniority, I expect you to know CAP theorem You can have the same result asking for a chess.com score. Anyone with score lower than 1400 is a bad engineer. I'm sure you'll have even better results than asking some CS theorems.

Esophagus4 1y ago
Why is expecting senior engineers to have an understanding of, frankly, basic fundamentals of how computers work is so upsetting to you? If you want to hire and work with people who don’t know those, by all means, hire them… I certainly won’t stop you.