3 ms·

It depends on what level you are hiring at. For senior engineers I would say it's all about design/architectural problems and talking generally about concepts

by jpgvm 6y ago

It depends on what level you are hiring at. For senior engineers I would say it's all about design/architectural problems and talking generally about concepts and taste to gauge fit. Mid-level engineers I think the take-home is king. A scoped problem, 1-2 hours at most that can be followed up with an interview talking about an extending their solution is pretty bulletproof. You get to understand what tools that are comfortable with, practices around source-control, testing etc that you would expect from an experienced but not overly senior engineer. Finally for entry level candidates I don't really know. Personally I hire entry level people on gut feel. Algorithms and datastructures just tell me if they a) went to university and b) paid attention. Seeing as I did neither of those things and still write IMO decent software that seems like a hypocritical measure. So I stick with how I feel about them, their level of enthusiasm, how well they researched the position, what stuff they have played with etc.

RandoHolmes 6y ago
I once did an interview where I described some software I had designed and built that was deployed around the world. At the end of it the biggest burning question they had was "where are the unit tests". I was like ... you see this circle here with this label inside it? This was critical to the entire system and therefore had unit tests surrounding it. didn't get the job, they seemed kind of annoyed that I didn't get into great detail about things like unit tests and instead talked mostly about the architectural problems I solved. I wish companies actually valued that level of knowledge.
- hackinthebochs 6y ago
  The fact is, people tend to over-emphasize their area of competence and de-emphasize areas outside of it. It was probably the case that the architectural problems you solved were above their paygrade, so they ignored that and over-emphasized what they knew. The fact that you didn't share their enthusiasm for unit tests just shows you weren't a top notch developer (which always happens to be a mirror image of the interviewer).
  - RandoHolmes 6y ago
    My interpretation was similar, but slightly different. The company itself wasn't actually solving complex problems and therefore the developers involved couldn't actually understand the level of complexity I was able to deal with. I get the feeling a lot of developers believe dealing with state in a react app is a complex problem, but I've been doing this stuff for 25+ years and left that behind as complex long ago. I know that's probably going to come across as arrogant, but it's how I feel about the entire thing. I see people all the time squabbling online over very specific source code related things as if they're important.
    - potamic 6y ago
      Out of curiosity, what was the software which you built?
      - RandoHolmes 6y ago
        Nothing glorious :) It was a VPS automated deployment system that could deploy both windows and linux to various datacenters around the world while also installing some 50+ pieces of software (as configured).
  - username90 6y ago
    That is the problem with soft skill interviews, in hard skill interviews there isn't much debate whether the solution is correct or not so your typical programmer can administer them correctly.

by jpgvm 6y ago

RandoHolmes 6y ago

I once did an interview where I described some software I had designed and built that was deployed around the world. At the end of it the biggest burning question they had was "where are the unit tests". I was like ... you see this circle here with this label inside it? This was critical to the entire system and therefore had unit tests surrounding it. didn't get the job, they seemed kind of annoyed that I didn't get into great detail about things like unit tests and instead talked mostly about the architectural problems I solved. I wish companies actually valued that level of knowledge.

hackinthebochs 6y ago
The fact is, people tend to over-emphasize their area of competence and de-emphasize areas outside of it. It was probably the case that the architectural problems you solved were above their paygrade, so they ignored that and over-emphasized what they knew. The fact that you didn't share their enthusiasm for unit tests just shows you weren't a top notch developer (which always happens to be a mirror image of the interviewer).
- RandoHolmes 6y ago
  My interpretation was similar, but slightly different. The company itself wasn't actually solving complex problems and therefore the developers involved couldn't actually understand the level of complexity I was able to deal with. I get the feeling a lot of developers believe dealing with state in a react app is a complex problem, but I've been doing this stuff for 25+ years and left that behind as complex long ago. I know that's probably going to come across as arrogant, but it's how I feel about the entire thing. I see people all the time squabbling online over very specific source code related things as if they're important.
  - potamic 6y ago
    Out of curiosity, what was the software which you built?
    - RandoHolmes 6y ago
      Nothing glorious :) It was a VPS automated deployment system that could deploy both windows and linux to various datacenters around the world while also installing some 50+ pieces of software (as configured).
- username90 6y ago
  That is the problem with soft skill interviews, in hard skill interviews there isn't much debate whether the solution is correct or not so your typical programmer can administer them correctly.