6 ms·

> Get used to 'em. No. I’ve spent the last year or so reinventing the hiring process at my tech company to expressly avoid algorithmic puzzles and leetcode no

> Get used to 'em. No. I’ve spent the last year or so reinventing the hiring process at my tech company to expressly avoid algorithmic puzzles and leetcode nonsense, and I was able to do this because I patently refused to accept the status quo. You can do this too. Anyone can. I’m basically a moron and I managed to convince our talent team to radically change how we do things; if I can do it I feel like the bar is pretty damn low. The only real requirement is that enough of us simply refuse to accept how things are today. Right now is a fantastic time for the tech industry to adopt change because your talent recruiters are probably struggling to find and retain new developers and are almost certainly willing to listen to suggestions on how to stand out.

rodenmonte 4y ago
Would you be able to share the kinds of questions you ask and have had success with? :)
- tsuujin 4y ago
  We basically adopted the MINASWAN interview, which Jesse Spevack can explain much better than myself in his talk [here](https://youtube.com/watch?v=c4K-ORZmrGk&feature=share https://youtube.com/watch?v=c4K-ORZmrGk&feature=share). The overview is that for each candidate we spend 20 minutes reading through code we provide to them to demonstrate comprehension, and then we give them 45 minutes to pair with us on reimplementing that same code from scratch. What that code is doesn’t really matter, it’s more about getting a chance to work with them and start a conversation, and starting with trying to explain a provided example really smooths the way into the pair programming.
  - kyawzazaw 4y ago
    How much time and resources does it cost to successfully hire one candidate?
    - tsuujin 4y ago
      Substantially less than our previous process. We went from a process that took weeks to get through (multiple interviews, about an hour each, with a full code day at the end) to a two step process. Talent reaches out to the candidate and has a thirty or so minute chat to make sure the candidate meets basic hiring requirements, and then we have our MINASWAN process which is a single three hour interview, including two breaks for the candidate to get off camera and catch their breath. The participants are: - the candidate - a hiring manager - between two and four developers for pairing - an open invitation to the hiring team’s devs for a closing panel interview. The feedback we’ve received from candidates has been overwhelmingly positive, even for those who didn’t receive an offer.
  - erik_seaberg 4y ago
    > 45 minutes to pair with us Do you require pairing on real work? How do you handle candidates who need quiet to think? Going by the continual complaints about open plan offices, there seem to be a lot of us.
    - tsuujin 4y ago
      We require that ICs are able to work with others effectively; we have a very large engineering team working on issues related to health care and collaboration is effectively mandatory. We keep the pairing as short as we can and we provide breaks between the short sessions to be as friendly as we can without being unrealistic as to what the candidate should expect in the actual job.
      - trekz 4y ago
        Your hiring process sounds great. Is there a link where one could apply?
        tsuujin 4y ago
        Sure, you can view all of our open positions here: https://experience.covermymeds.com/open-positions https://experience.covermymeds.com/open-positions (and then narrow down the list with the “all teams” drop down and selecting “technology”) If you’re looking for a general SWE role: https://mckesson.wd3.myworkdayjobs.com/CoverMyMeds_External_Careers/job/USA-OH-Columbus/Software-Developer_JR0062397 https://mckesson.wd3.myworkdayjobs.com/CoverMyMeds_External_...
deleted 4y ago
[deleted]
bluedevilzn 4y ago
> I’m basically a moron Google and other companies are actively trying to avoid hiring morons.
- tsuujin 4y ago
  I’m not sure if you’re just being snarky or you’re trying to make an actual point here, but I can tell you that this kind of commentary reinforces the egocentric interview process we currently suffer through. Solving puzzles doesn’t prove that you’re smart, and not memorizing them ahead doesn’t prove you can’t do the job. Unless you’re really on the edge of the industry—designing rockets for NASA or surgery tech or something—most dev jobs aren’t really all that hard, and we should stop pretending they are.
  - missedthecue 4y ago
    Solving complex riddles may not prove you're Einstein, but it's a pretty good filter for morons.
    - tsuujin 4y ago
      Disagree. I’m very good at puzzles.
      - fsckboy 4y ago
        then you shouldn't have said you're a moron. You seem somewhat contrary, which leads to its own problems, at least for me.
        tsuujin 4y ago
        Disagree. I’m highly agreeable.
  - bartread 4y ago
    > most dev jobs aren’t really all that hard, and we should stop pretending they are. I agree with you about GP's commentary, but I don't know that I agree with this statement. Getting something working is often relatively easy. Shipping v1.0 is often relatively easy. But it starts to get gnarly as you build out capabilities, add services, split concerns up, have to maintain compatibility with previous versions, dependencies multiply, the amount of data you're dealing with massively expands, and so on. Most problems have one or more inflection points, whether that's around performance, or scale, or volume of data, or whatever, that when you pass them make that problem substantially harder to solve. Still, these are all issues that come with a certain amount of success. Not necessarily crazy success: I'm just talking about the kind of traction that companies that grow to earn millions to tens of millions of dollars or pounds per annum experience. The really hard part of being a dev, of course, is knowing what the right thing is to build. Often, because users tend to struggle to articulate their needs, the only way to find out what to build is to start by building something that you know is probably going to be at least a bit wrong, if not massively wide of the mark, just to get some feedback. And then you have to iterate, sometimes quite painfully, towards an actually good solution from there. Of course, this isn't something you can assess with a leetcode interview. I don't hate interviews where the candidate is asked to write some code. I think writing code is a valid form of assessment because I've encountered enough jokers over the years who couldn't program if their life depended upon it - yet still manage to carry a job title like "software developer" - that I need some way of weeding them out of our hiring process. One reason for this is that I simply don't have gobs of spare cash to pay large salaries to people who are fundamentally incapable of doing the job they're asked to do. Note though that asking them to write code does not equate to leetcode. We'll generally give people access to an IDE containing a template project and common tooling they would use on a day to day basis in the job. We also select problems that have some relation to our systems rather than asking hardcore questions about algorithms and data structures: we give them internet access so they can look that stuff up if they need it to help them (just like the rest of us do in our day jobs). Cynically, a lot of interviewing I've seen over the years seems to be about the interviewer trying to appear to be the cleverest person in the room, and I think leetcode often falls into this category. I find this perverse and unhelpful but I guess these interviewers are just insecure, angry people.
valar_m 4y ago
So what'd you come up with?
- tsuujin 4y ago
  I answered this in another comment before I saw this, feel free to respond to it if you want to chat about it: https://news.ycombinator.com/item?id=31453571 https://news.ycombinator.com/item?id=31453571
deleted 4y ago
[deleted]
UncleOxidant 4y ago
> now is a fantastic time for the tech industry to adopt change because your talent recruiters are probably struggling to find and retain new developers Unfortunately, this will likely change much sooner and more rapidly then most of us expect. The music is stopping and chairs are about to be removed. It was great while it lasted, but all good things come to an end.
- tsuujin 4y ago
  I’m not sure I agree, but I’m positive this isn’t a barrier to adoption right now. Recruiters are really looking for an edge to provide differentiation, and “friendlier, faster process” is a big one.
  - danachow 4y ago
    What has changed in the past 20 years? Because this sounds like the same shit I’ve heard since entering the industry. And it isn’t like this topic is new at all.
- rejor121 4y ago
  Sure. Someday. Same thing has been said since the 90s
  - sorry_outta_gas 4y ago
    After working though the dotcom bust and the subprime fiasco it seems a bit dramatic although I'm also not beyond my means and have some savings this time (didn't last time and it got hairy) in general i worry more about other people in much worse situations that I'm unable to help
  - UncleOxidant 4y ago
    And it's happened a couple of times since the 90s.
ssalka 4y ago
Yeah, I've worked in tech 6 years now and never had to do Leetcode to get by in interviews. That being said, I never interviewed at FAANG. But many teams set a bar easier to pass than leetcode that still ensures good engineering skills
beej71 4y ago
> I’ve spent the last year or so reinventing the hiring process at my tech company to expressly avoid algorithmic puzzles and leetcode nonsense, and I was able to do this because I patently refused to accept the status quo. I think companies that break out of the leetcode habit are going to do well. There's a lot of great talent out there that's being passed over by these tests. If the job is to solve leetcode problems, by all means, test the candidates for that. If the job is to solve real life problems, there's almost certainly a better measure. I will never judge someone based on that kind of problem. I believe the data that results is just bad. Edit: I should add that leetcode is useful for developing programming and problem-solving skill. I've done tons of problems, myself, and have fun solving them... and learn from them. So I do recommend it for a challenge. But not for interviews.
- tsuujin 4y ago
  Strong agree with all of this. Ideally, interview questions should be directly related to the domain of the position. Show the candidate what they will actually be doing if they accept an offer. The whole process should be a two way conversation.
- stutsmansoft 4y ago
  > I think companies that break out of the leetcode habit are going to do well. > There's a lot of great talent out there that's being passed over by these tests. Agreed. And there's a lot of great talent that doesn't even want to try with some of these companies solely due to the hostile interview process.
  - kabdib 4y ago
    I recently took a year off, and started interviewing in March. I spent a fair amount of time in fear of interviewing, doing LeetCode pushups and feeling miserable about my performance, and wondering if I could swing retirement rather than go through another fucking hazing ritual. Excuse my language. I resolved up front not to submit to any kind of take-home test, proctoring software, or algorithmic nonsense unrelated to the actual job of shipping software. A polite "No thank you" was what I planned. But the plan was thwarted! I was pleasantly surprised by the technical interviews I actually got. They were mostly nicely constrained problems that were real-world and not algorithmically nasty. One was a little unintended "collaboration" in the form of helping a senior dev debug their own "what is wrong with this code?" exercise (it probably went smoother for the next candidate they interviewed). In short, it was actually kind of fun. I started a new dream job this week. At 61 this is no longer easy, but the company is enlightened enough to support me while I get up to speed, and it's fun to help mentor the folks just getting into the industry. There are decent companies out there. Hopefully the terrible ones will start getting a clue.
deltree7 4y ago
Only on the internet, that someone working for a cost-center division, building an piece of internal software used by 20 users, gets to lecture how a $2 Trillion Dollar, building multiple Billion real-world user products, generating > $500,000 per engineer profit should run their hiring process
- tsuujin 4y ago
  That’s making a lot of assumptions about who I am and what I do based on nothing.
serenitylater 4y ago
curiousllama 4y ago
FWIW, happy you're doing this! A better process would make so many peoples' lives better. The ONLY people who should "get used to 'em" are new/recent grads looking for a junior-ish IC job. For them, it's just a fact of life: they had to learn history & biology to get their CS degree; they have to learn leetcode to get a job. Interviewers should make a better process, as you're doing.
- tsuujin 4y ago
  Honestly, I think I would encourage junior devs to shop around before just accepting the leet code life. Unless they’re in dire need of income—in which case, do what you need to do—the kind of company willing to treat you like a game show contestant may not provide the best culture for learning and growth. If you can avoid the BS you should definitely do so.

rodenmonte 4y ago

Would you be able to share the kinds of questions you ask and have had success with? :)

tsuujin 4y ago
We basically adopted the MINASWAN interview, which Jesse Spevack can explain much better than myself in his talk [here](https://youtube.com/watch?v=c4K-ORZmrGk&feature=share https://youtube.com/watch?v=c4K-ORZmrGk&feature=share). The overview is that for each candidate we spend 20 minutes reading through code we provide to them to demonstrate comprehension, and then we give them 45 minutes to pair with us on reimplementing that same code from scratch. What that code is doesn’t really matter, it’s more about getting a chance to work with them and start a conversation, and starting with trying to explain a provided example really smooths the way into the pair programming.
- kyawzazaw 4y ago
  How much time and resources does it cost to successfully hire one candidate?
  - tsuujin 4y ago
    Substantially less than our previous process. We went from a process that took weeks to get through (multiple interviews, about an hour each, with a full code day at the end) to a two step process. Talent reaches out to the candidate and has a thirty or so minute chat to make sure the candidate meets basic hiring requirements, and then we have our MINASWAN process which is a single three hour interview, including two breaks for the candidate to get off camera and catch their breath. The participants are: - the candidate - a hiring manager - between two and four developers for pairing - an open invitation to the hiring team’s devs for a closing panel interview. The feedback we’ve received from candidates has been overwhelmingly positive, even for those who didn’t receive an offer.
- erik_seaberg 4y ago
  > 45 minutes to pair with us Do you require pairing on real work? How do you handle candidates who need quiet to think? Going by the continual complaints about open plan offices, there seem to be a lot of us.
  - tsuujin 4y ago
    We require that ICs are able to work with others effectively; we have a very large engineering team working on issues related to health care and collaboration is effectively mandatory. We keep the pairing as short as we can and we provide breaks between the short sessions to be as friendly as we can without being unrealistic as to what the candidate should expect in the actual job.
    - trekz 4y ago
      Your hiring process sounds great. Is there a link where one could apply?
      - tsuujin 4y ago
        Sure, you can view all of our open positions here: https://experience.covermymeds.com/open-positions https://experience.covermymeds.com/open-positions (and then narrow down the list with the “all teams” drop down and selecting “technology”) If you’re looking for a general SWE role: https://mckesson.wd3.myworkdayjobs.com/CoverMyMeds_External_Careers/job/USA-OH-Columbus/Software-Developer_JR0062397 https://mckesson.wd3.myworkdayjobs.com/CoverMyMeds_External_...

deleted 4y ago

[deleted]

bluedevilzn 4y ago

> I’m basically a moron Google and other companies are actively trying to avoid hiring morons.

tsuujin 4y ago
I’m not sure if you’re just being snarky or you’re trying to make an actual point here, but I can tell you that this kind of commentary reinforces the egocentric interview process we currently suffer through. Solving puzzles doesn’t prove that you’re smart, and not memorizing them ahead doesn’t prove you can’t do the job. Unless you’re really on the edge of the industry—designing rockets for NASA or surgery tech or something—most dev jobs aren’t really all that hard, and we should stop pretending they are.
- missedthecue 4y ago
  Solving complex riddles may not prove you're Einstein, but it's a pretty good filter for morons.
  - tsuujin 4y ago
    Disagree. I’m very good at puzzles.
    - fsckboy 4y ago
      then you shouldn't have said you're a moron. You seem somewhat contrary, which leads to its own problems, at least for me.
      - tsuujin 4y ago
        Disagree. I’m highly agreeable.
- bartread 4y ago
  > most dev jobs aren’t really all that hard, and we should stop pretending they are. I agree with you about GP's commentary, but I don't know that I agree with this statement. Getting something working is often relatively easy. Shipping v1.0 is often relatively easy. But it starts to get gnarly as you build out capabilities, add services, split concerns up, have to maintain compatibility with previous versions, dependencies multiply, the amount of data you're dealing with massively expands, and so on. Most problems have one or more inflection points, whether that's around performance, or scale, or volume of data, or whatever, that when you pass them make that problem substantially harder to solve. Still, these are all issues that come with a certain amount of success. Not necessarily crazy success: I'm just talking about the kind of traction that companies that grow to earn millions to tens of millions of dollars or pounds per annum experience. The really hard part of being a dev, of course, is knowing what the right thing is to build. Often, because users tend to struggle to articulate their needs, the only way to find out what to build is to start by building something that you know is probably going to be at least a bit wrong, if not massively wide of the mark, just to get some feedback. And then you have to iterate, sometimes quite painfully, towards an actually good solution from there. Of course, this isn't something you can assess with a leetcode interview. I don't hate interviews where the candidate is asked to write some code. I think writing code is a valid form of assessment because I've encountered enough jokers over the years who couldn't program if their life depended upon it - yet still manage to carry a job title like "software developer" - that I need some way of weeding them out of our hiring process. One reason for this is that I simply don't have gobs of spare cash to pay large salaries to people who are fundamentally incapable of doing the job they're asked to do. Note though that asking them to write code does not equate to leetcode. We'll generally give people access to an IDE containing a template project and common tooling they would use on a day to day basis in the job. We also select problems that have some relation to our systems rather than asking hardcore questions about algorithms and data structures: we give them internet access so they can look that stuff up if they need it to help them (just like the rest of us do in our day jobs). Cynically, a lot of interviewing I've seen over the years seems to be about the interviewer trying to appear to be the cleverest person in the room, and I think leetcode often falls into this category. I find this perverse and unhelpful but I guess these interviewers are just insecure, angry people.

valar_m 4y ago

So what'd you come up with?

tsuujin 4y ago
I answered this in another comment before I saw this, feel free to respond to it if you want to chat about it: https://news.ycombinator.com/item?id=31453571 https://news.ycombinator.com/item?id=31453571

deleted 4y ago

[deleted]

UncleOxidant 4y ago

> now is a fantastic time for the tech industry to adopt change because your talent recruiters are probably struggling to find and retain new developers Unfortunately, this will likely change much sooner and more rapidly then most of us expect. The music is stopping and chairs are about to be removed. It was great while it lasted, but all good things come to an end.

tsuujin 4y ago
I’m not sure I agree, but I’m positive this isn’t a barrier to adoption right now. Recruiters are really looking for an edge to provide differentiation, and “friendlier, faster process” is a big one.
- danachow 4y ago
  What has changed in the past 20 years? Because this sounds like the same shit I’ve heard since entering the industry. And it isn’t like this topic is new at all.
rejor121 4y ago
Sure. Someday. Same thing has been said since the 90s
- sorry_outta_gas 4y ago
  After working though the dotcom bust and the subprime fiasco it seems a bit dramatic although I'm also not beyond my means and have some savings this time (didn't last time and it got hairy) in general i worry more about other people in much worse situations that I'm unable to help
- UncleOxidant 4y ago
  And it's happened a couple of times since the 90s.

ssalka 4y ago

Yeah, I've worked in tech 6 years now and never had to do Leetcode to get by in interviews. That being said, I never interviewed at FAANG. But many teams set a bar easier to pass than leetcode that still ensures good engineering skills

beej71 4y ago

> I’ve spent the last year or so reinventing the hiring process at my tech company to expressly avoid algorithmic puzzles and leetcode nonsense, and I was able to do this because I patently refused to accept the status quo. I think companies that break out of the leetcode habit are going to do well. There's a lot of great talent out there that's being passed over by these tests. If the job is to solve leetcode problems, by all means, test the candidates for that. If the job is to solve real life problems, there's almost certainly a better measure. I will never judge someone based on that kind of problem. I believe the data that results is just bad. Edit: I should add that leetcode is useful for developing programming and problem-solving skill. I've done tons of problems, myself, and have fun solving them... and learn from them. So I do recommend it for a challenge. But not for interviews.

tsuujin 4y ago
Strong agree with all of this. Ideally, interview questions should be directly related to the domain of the position. Show the candidate what they will actually be doing if they accept an offer. The whole process should be a two way conversation.
stutsmansoft 4y ago
> I think companies that break out of the leetcode habit are going to do well. > There's a lot of great talent out there that's being passed over by these tests. Agreed. And there's a lot of great talent that doesn't even want to try with some of these companies solely due to the hostile interview process.
- kabdib 4y ago
  I recently took a year off, and started interviewing in March. I spent a fair amount of time in fear of interviewing, doing LeetCode pushups and feeling miserable about my performance, and wondering if I could swing retirement rather than go through another fucking hazing ritual. Excuse my language. I resolved up front not to submit to any kind of take-home test, proctoring software, or algorithmic nonsense unrelated to the actual job of shipping software. A polite "No thank you" was what I planned. But the plan was thwarted! I was pleasantly surprised by the technical interviews I actually got. They were mostly nicely constrained problems that were real-world and not algorithmically nasty. One was a little unintended "collaboration" in the form of helping a senior dev debug their own "what is wrong with this code?" exercise (it probably went smoother for the next candidate they interviewed). In short, it was actually kind of fun. I started a new dream job this week. At 61 this is no longer easy, but the company is enlightened enough to support me while I get up to speed, and it's fun to help mentor the folks just getting into the industry. There are decent companies out there. Hopefully the terrible ones will start getting a clue.

deltree7 4y ago

Only on the internet, that someone working for a cost-center division, building an piece of internal software used by 20 users, gets to lecture how a $2 Trillion Dollar, building multiple Billion real-world user products, generating > $500,000 per engineer profit should run their hiring process

tsuujin 4y ago
That’s making a lot of assumptions about who I am and what I do based on nothing.

serenitylater 4y ago

curiousllama 4y ago

FWIW, happy you're doing this! A better process would make so many peoples' lives better. The ONLY people who should "get used to 'em" are new/recent grads looking for a junior-ish IC job. For them, it's just a fact of life: they had to learn history & biology to get their CS degree; they have to learn leetcode to get a job. Interviewers should make a better process, as you're doing.

tsuujin 4y ago
Honestly, I think I would encourage junior devs to shop around before just accepting the leet code life. Unless they’re in dire need of income—in which case, do what you need to do—the kind of company willing to treat you like a game show contestant may not provide the best culture for learning and growth. If you can avoid the BS you should definitely do so.