6 ms·

I moved from Physics and Engineering to CS and honestly, I found the interview process very odd. It is far more involved and time consuming of a process than th

I moved from Physics and Engineering to CS and honestly, I found the interview process very odd. It is far more involved and time consuming of a process than the interviews in other fields. In other fields, it is expected that if you can "talk the talk" you can "walk the walk." Mostly because it is really hard to talk in the right way if you don't have actual experience. Tbh, I think this is true about expertise in any domain. I don't think it is too hard to talk to a programmer about how they'd solve a problem and see the differences between a novice and a veteran. A traditional engineering interview will have a phone screen and an in person interview. Both of which they'll ask you about a problem similar to one they are working on or recently solved. They'll also typically ask you to explain a recent project of yours. The point is to see how you think and how you overcome challenges, not what you memorize. Memorization comes with repetition, so it's less important. I remember in one phone interview I was asked about something and gave a high level answer and asked if it was okay for me to grab one of the books I had sitting next to me because I earmarked that equation suspecting it would be asked. I was commended for doing so, grabbed my book, and once I reminded myself of the equation (all <<1m?) gave a much more detailed response. In a PhD level interview, you're probably going to do this and give a talk on your work. Where people ask questions about your work. IMO the tech interviews are wasteful. They aren't great at achieving their goals and are quite time consuming. General proficiency can be determined in other ways, especially with how prolific GitHub is these days. It's been explained to me that the reason for all this is due to the cost of bad hires. But all this is expensive too, since you are paying for the time of your high cost engineers all throughout this process. If the concern is that firing is so difficult, then I don't think it'd be hard to set policy where new employees are hired in under a "probationary" or "trial" status. It shouldn't take months to hire someone...

kenjackson 2y ago
> I found the interview process very odd. It is far more involved and time consuming of a process than the interviews in other fields. What part is too time consuming? What you describe in the engineering interview sounds like a software engineer interview process as well.
- godelski 2y ago
  No engineering interview would have you do anything like leetcode problems. No one is going to ask you to solve equations in front of them[0]. They will not give you take home tests or any of that. Doesn't matter if you're at a small startup or a big player like Boeing or Lockheed Martin. The stereotypical software engineering interview is heavily leetcode dependent. It's why leetcode exists and they can charget $150/yr for people to just study it (time that could be spent on learning other things). I mean somewhere like Google you can have 3-6 rounds in the interviewing process. [0] Maybe you'll use a board or paper to draw illustrations and help in your explanations, but you're not going to work out problems. No one is going to give you a physics textbook problem and say "Go".
  - throwaway2037 2y ago
    First, when you write "engineering", I suppose that you mean all engineering disciplines except software engineering. If true, how do you compare candidates for material science or civil engineering or aero engineering or mechanical engineering roles? I suppose that you will reply "talk to them" or "look at their experience". But, we have learned through squillions of posts here on HN, it just isn't enough. There are many charlatans that will slip through that type of interview process -- "great talker / good looking". This is the reason for the three-decade-long "arms race" in the technical interview process where programming problems become harder and harder over time. (Side comment: Does anyone think that people who can solve harder leetcode problems have a higher IQ? Controversially, on balance, I believe it to be true, and, thus, I think programming tests are a great way to filter for higher IQ candidates.)
    - godelski 2y ago
      > But, we have learned through squillions of posts here on HN, it just isn't enough. Idk, I can usually tell when someone is an actual engineer vs armchair expert. Actually building stuff requires you to think differently. It's like how someone that just does CAD often fights with machinists because they don't understand the physical limitations. > There are many charlatans that will slip through that type of interview process Of course. But that also happens with leetcode style interviews. You can memorize problems and that doesn't reflect your actual job performance. There's a saying "studying to the test" The real question is the "optimization" question. Considering the time and cost of the interview process, along with the difficulty to remove bad employees, how effective is the interview process. You are optimizing for the best candidate but it's a constrained optimization problem. Otherwise you need infinite resources. So don't ignore the constraints. There's more that I haven't mentioned. > Does anyone think that people who can solve harder leetcode problems have a higher IQ? I know people who believe this. But I'm generally uninterested in anyone who has an obsession with IQ. So far it's been a fairly successful filter
SoftTalker 2y ago
I haven't interviewed for a tech job in over 10 years but I've never had a leetcode interview. Never been asked about algorithms, or put on the spot to answer how many manhole covers are there in New York City. I've been asked about my former projects, my roles, what I liked or didn't like about them, how do I approach a new project, what did I find most interesting, etc. I gather there are a lot of fakers in the software dev world. So maybe that's why more places try to make you prove you can actually write code. Reaching for a book to answer, makes sense to me. That's what you'd do on the job, and nobody would think less of you for it.
hansvm 2y ago
> months to hire I've seen that at BigCo, but that's the exception. Every other place strongly prefers a start date of ASAP, with O(weeks) from initial contact as a next-best option. If you state that you aren't available for months you probably won't be hired. > concern is that firing is so difficult There are lots of concerns. Keep in mind, 95% of resumes are some sort of bot/scam, and 0.5% of the rest are actually at the skill level I'm looking for. There are lots of potential explanations, and I don't think it's that only 0.5% of developers are who I'm looking for (there are sampling biases, survivorship bias, and all sorts of things at play in that data), but from my position doing the screening and interviewing those are the stats I see. 1. Suppose you actually did hire everyone who passed a 1hr screen. You'd still have 20+ failed candidates before you found the right person. Even with a 2-week trial period, that's 3/4 of the year not having your projects properly staffed, a demoralizing experience for all their coworkers, and 3/4 of a SWE-year in wages and benefits lost. 2. Is it really fair to hire somebody if I know there's a 95% chance I intend to fire them? What if they have to move? What if they hadn't quit their old job till I accepted them? I suppose if somebody said they were confident in themselves and were willing to risk a trial period I might allow it, but the current set of social expectations is that once you're hired your employer will spend months at a bare minimum trying to make you successful, I'd want to be cautious with that sort of arrangement out of respect for the candidates. 3. Onboarding is even more expensive than it might seem since it sucks away your more senior talent for the training. If the cost of a bad engineer were just the normal day-to-day post-onboarding it wouldn't be _that_ terrible (you still have attrition and other knock-on effects to worry about), but having multiple onboarding sessions for a single hire (because of multiple trial periods) is the most expensive part of the process. etc > General proficiency can be determined in other ways, especially with how prolific GitHub is these days I agree. Walking through a project with a candidate is one of my favorite interview sessions. They tend to be more comfortable, I tend to learn more, and I get to learn something about their technical communication on top of any coding knowledge. Not everyone has a GH with anything interesting, so I make other interviews available for everyone, but my life is a little easier if public "proof" (till you talk to the candidate you really have no idea how much they know or who wrote what, but I thankfully haven't seen that problem yet in an interview) exists.
- godelski 2y ago

kenjackson 2y ago

> I found the interview process very odd. It is far more involved and time consuming of a process than the interviews in other fields. What part is too time consuming? What you describe in the engineering interview sounds like a software engineer interview process as well.

godelski 2y ago
No engineering interview would have you do anything like leetcode problems. No one is going to ask you to solve equations in front of them[0]. They will not give you take home tests or any of that. Doesn't matter if you're at a small startup or a big player like Boeing or Lockheed Martin. The stereotypical software engineering interview is heavily leetcode dependent. It's why leetcode exists and they can charget $150/yr for people to just study it (time that could be spent on learning other things). I mean somewhere like Google you can have 3-6 rounds in the interviewing process. [0] Maybe you'll use a board or paper to draw illustrations and help in your explanations, but you're not going to work out problems. No one is going to give you a physics textbook problem and say "Go".
- throwaway2037 2y ago
  First, when you write "engineering", I suppose that you mean all engineering disciplines except software engineering. If true, how do you compare candidates for material science or civil engineering or aero engineering or mechanical engineering roles? I suppose that you will reply "talk to them" or "look at their experience". But, we have learned through squillions of posts here on HN, it just isn't enough. There are many charlatans that will slip through that type of interview process -- "great talker / good looking". This is the reason for the three-decade-long "arms race" in the technical interview process where programming problems become harder and harder over time. (Side comment: Does anyone think that people who can solve harder leetcode problems have a higher IQ? Controversially, on balance, I believe it to be true, and, thus, I think programming tests are a great way to filter for higher IQ candidates.)
  - godelski 2y ago
    > But, we have learned through squillions of posts here on HN, it just isn't enough. Idk, I can usually tell when someone is an actual engineer vs armchair expert. Actually building stuff requires you to think differently. It's like how someone that just does CAD often fights with machinists because they don't understand the physical limitations. > There are many charlatans that will slip through that type of interview process Of course. But that also happens with leetcode style interviews. You can memorize problems and that doesn't reflect your actual job performance. There's a saying "studying to the test" The real question is the "optimization" question. Considering the time and cost of the interview process, along with the difficulty to remove bad employees, how effective is the interview process. You are optimizing for the best candidate but it's a constrained optimization problem. Otherwise you need infinite resources. So don't ignore the constraints. There's more that I haven't mentioned. > Does anyone think that people who can solve harder leetcode problems have a higher IQ? I know people who believe this. But I'm generally uninterested in anyone who has an obsession with IQ. So far it's been a fairly successful filter

SoftTalker 2y ago

I haven't interviewed for a tech job in over 10 years but I've never had a leetcode interview. Never been asked about algorithms, or put on the spot to answer how many manhole covers are there in New York City. I've been asked about my former projects, my roles, what I liked or didn't like about them, how do I approach a new project, what did I find most interesting, etc. I gather there are a lot of fakers in the software dev world. So maybe that's why more places try to make you prove you can actually write code. Reaching for a book to answer, makes sense to me. That's what you'd do on the job, and nobody would think less of you for it.

hansvm 2y ago

> months to hire I've seen that at BigCo, but that's the exception. Every other place strongly prefers a start date of ASAP, with O(weeks) from initial contact as a next-best option. If you state that you aren't available for months you probably won't be hired. > concern is that firing is so difficult There are lots of concerns. Keep in mind, 95% of resumes are some sort of bot/scam, and 0.5% of the rest are actually at the skill level I'm looking for. There are lots of potential explanations, and I don't think it's that only 0.5% of developers are who I'm looking for (there are sampling biases, survivorship bias, and all sorts of things at play in that data), but from my position doing the screening and interviewing those are the stats I see. 1. Suppose you actually did hire everyone who passed a 1hr screen. You'd still have 20+ failed candidates before you found the right person. Even with a 2-week trial period, that's 3/4 of the year not having your projects properly staffed, a demoralizing experience for all their coworkers, and 3/4 of a SWE-year in wages and benefits lost. 2. Is it really fair to hire somebody if I know there's a 95% chance I intend to fire them? What if they have to move? What if they hadn't quit their old job till I accepted them? I suppose if somebody said they were confident in themselves and were willing to risk a trial period I might allow it, but the current set of social expectations is that once you're hired your employer will spend months at a bare minimum trying to make you successful, I'd want to be cautious with that sort of arrangement out of respect for the candidates. 3. Onboarding is even more expensive than it might seem since it sucks away your more senior talent for the training. If the cost of a bad engineer were just the normal day-to-day post-onboarding it wouldn't be _that_ terrible (you still have attrition and other knock-on effects to worry about), but having multiple onboarding sessions for a single hire (because of multiple trial periods) is the most expensive part of the process. etc > General proficiency can be determined in other ways, especially with how prolific GitHub is these days I agree. Walking through a project with a candidate is one of my favorite interview sessions. They tend to be more comfortable, I tend to learn more, and I get to learn something about their technical communication on top of any coding knowledge. Not everyone has a GH with anything interesting, so I make other interviews available for everyone, but my life is a little easier if public "proof" (till you talk to the candidate you really have no idea how much they know or who wrote what, but I thankfully haven't seen that problem yet in an interview) exists.

godelski 2y ago