7 ms·

Glad to hear that the software engineer selection method is determined by this very rigorous process of character assessment. No wonder why big corporations pro

Glad to hear that the software engineer selection method is determined by this very rigorous process of character assessment. No wonder why big corporations produce such amazing teams.

avl999 5y ago
I am not gonna die on a hill defending these types of interviews but they are infinitely better than the alternatives. Alternatives are often subjective criteria like "culture fit" which can lead to nepotism/other types of biases or hiring being done by sorting resumes based on the prestige level of the college of the applicant and just running down the list from the top (which happens in other professions like law). Ofcourse the interview process is (or atleast is supposed to be multifaced) and passing these problems is just one of the facets of the process. A great candidate can bomb one of these questions but I wouldn't necessarily reject them just because of that (although that happens in practice in the industry) and wouldn't necessarily okay someone just because they aced one of these questions. I'd take complaining about these type of problems any day over complaining about only being able to get a job in certain companies by having connections or having gone to an Ivy League school.
- vanusa 5y ago
  Alternatives are often subjective criteria like "culture fit" There's a vast territory of approaches that are neither leetcode hazing or culture fit tests. And which, while nuanced, are basically objective. Work sample evaluations do quite well, for example. As do in-depth technical discussions about ... just about any subject the candidate claims to know about. Neither of which have anything to do with "culture fit".
  - esyir 5y ago
    >As do in-depth technical discussions about ... just about any subject the candidate claims to know about. Having attempted to do this after reading all the HN screeds, I found that this failed horribly. You'll find a large number of people who seemingly know the theory, but can't execute worth a damn. They can happily talk on and on about normalization, regularization, imbalanced datasets and so on. Then they fail fizzbuzz. I then put the programming screen first.
    - vanusa 5y ago
      Try talking about execution, not theory.
      - Jensson 5y ago
        You can't communicate experience like you can communicate theory, if you could then it would be called theory instead of practice. Theory is great since it is something we can communicate, whatever instincts you developed working on a big codebase can't be communicated. Some people thing you can, there are lots of talks about these things etc, but in practice you can't teach practice, you need to experience it yourself. And if you distil practice into pure enough droplets of wisdom that others can recognize as the truth without being your in-group, guess what, that is what we call theory!
        pjmlp 5y ago
        Talk about how the candidate used technology X in practice, what was their role in the project, what worked in practice and what not, how they would approach the bad decisions in retrospective of the lessons learned while using X.
  - visarga 5y ago
    > Work sample evaluations do quite well, for example. As do in depth technical discussions about ... just about any subject the candidate claims to know about. How do you compare candidate A with preferred subject 1 with candidate B with subject 2? And how do you get the candidate to talk sincerely and not bullshit around the topic, especially when testing ML - a modern alchemy more or less, no definitive answers, just a bag of tricks? I have had problems with controlling the waste of time and directing the talk towards useful topics because the candidate wouldn't stop the bullshit talk. Maybe other fields have less bullshit maneuvering space. I think it's better to go with a list of basic questions that remains the same between candidates. Only if they ace the basics I test for depth. Depth can be tricky to evaluate, especially for people who are not very bad - maybe just in ML.
- austincheney 5y ago
  In small companies or startups I have come to believe the quality and objectivity of the interview is a fair reflection of the maturity of the thought leaders at the company. I then use that assessment as a primary indicator to drop out. As someone who has a current stable employment I have the freedom and flexibility to fail at numerous interviews with only minor frustration of time wasted. If I were out of a job and a bit more desperate I would just lie through my teeth on all elements that of a job interview except education and employment history like a super brown-nose narcissist. Since most all programming interviews are maximally subjective intentionally injected bias goes both ways and is easily applied.
- quasiprime 5y ago
  Unfortunately subjective criteria are not alternatives to objective criteria but are generally applied in conjunction with them. From my experience, in the past one year and a half I've been interviewing at several companies, and I've done over 20 different code challenges. Even though I passed 90% of those code challenges, only 1 company gave me an offer and that's the company I'm working for right now. Other companies just rejected my application because I wasn't a "cultural fit" or something.

Glad to hear that the software engineer selection method is determined by this very rigorous process of character assessment. No wonder why big corporations produce such amazing teams.

avl999 5y ago

I am not gonna die on a hill defending these types of interviews but they are infinitely better than the alternatives. Alternatives are often subjective criteria like "culture fit" which can lead to nepotism/other types of biases or hiring being done by sorting resumes based on the prestige level of the college of the applicant and just running down the list from the top (which happens in other professions like law). Ofcourse the interview process is (or atleast is supposed to be multifaced) and passing these problems is just one of the facets of the process. A great candidate can bomb one of these questions but I wouldn't necessarily reject them just because of that (although that happens in practice in the industry) and wouldn't necessarily okay someone just because they aced one of these questions. I'd take complaining about these type of problems any day over complaining about only being able to get a job in certain companies by having connections or having gone to an Ivy League school.

vanusa 5y ago
Alternatives are often subjective criteria like "culture fit" There's a vast territory of approaches that are neither leetcode hazing or culture fit tests. And which, while nuanced, are basically objective. Work sample evaluations do quite well, for example. As do in-depth technical discussions about ... just about any subject the candidate claims to know about. Neither of which have anything to do with "culture fit".
- esyir 5y ago
  >As do in-depth technical discussions about ... just about any subject the candidate claims to know about. Having attempted to do this after reading all the HN screeds, I found that this failed horribly. You'll find a large number of people who seemingly know the theory, but can't execute worth a damn. They can happily talk on and on about normalization, regularization, imbalanced datasets and so on. Then they fail fizzbuzz. I then put the programming screen first.
  - vanusa 5y ago
    Try talking about execution, not theory.
    - Jensson 5y ago
      You can't communicate experience like you can communicate theory, if you could then it would be called theory instead of practice. Theory is great since it is something we can communicate, whatever instincts you developed working on a big codebase can't be communicated. Some people thing you can, there are lots of talks about these things etc, but in practice you can't teach practice, you need to experience it yourself. And if you distil practice into pure enough droplets of wisdom that others can recognize as the truth without being your in-group, guess what, that is what we call theory!
      - pjmlp 5y ago
        Talk about how the candidate used technology X in practice, what was their role in the project, what worked in practice and what not, how they would approach the bad decisions in retrospective of the lessons learned while using X.
- visarga 5y ago
  > Work sample evaluations do quite well, for example. As do in depth technical discussions about ... just about any subject the candidate claims to know about. How do you compare candidate A with preferred subject 1 with candidate B with subject 2? And how do you get the candidate to talk sincerely and not bullshit around the topic, especially when testing ML - a modern alchemy more or less, no definitive answers, just a bag of tricks? I have had problems with controlling the waste of time and directing the talk towards useful topics because the candidate wouldn't stop the bullshit talk. Maybe other fields have less bullshit maneuvering space. I think it's better to go with a list of basic questions that remains the same between candidates. Only if they ace the basics I test for depth. Depth can be tricky to evaluate, especially for people who are not very bad - maybe just in ML.
austincheney 5y ago
In small companies or startups I have come to believe the quality and objectivity of the interview is a fair reflection of the maturity of the thought leaders at the company. I then use that assessment as a primary indicator to drop out. As someone who has a current stable employment I have the freedom and flexibility to fail at numerous interviews with only minor frustration of time wasted. If I were out of a job and a bit more desperate I would just lie through my teeth on all elements that of a job interview except education and employment history like a super brown-nose narcissist. Since most all programming interviews are maximally subjective intentionally injected bias goes both ways and is easily applied.
quasiprime 5y ago
Unfortunately subjective criteria are not alternatives to objective criteria but are generally applied in conjunction with them. From my experience, in the past one year and a half I've been interviewing at several companies, and I've done over 20 different code challenges. Even though I passed 90% of those code challenges, only 1 company gave me an offer and that's the company I'm working for right now. Other companies just rejected my application because I wasn't a "cultural fit" or something.