7 ms·

I have interviewed 100s of candidates for software engineering positions

58 points by riidom 3y ago

mlhpdx 3y ago
I don’t disagree with the sentiment but the tools aren’t the problem, it’s the delivery. A puzzle can might be toxic if it’s a test, but constructive as a gimmick used to explore communication. Likewise for coding exercises. It’s all pretty easy if respect for the human is genuine, and destructive for all when faked.
- H8crilA 3y ago
  But it is a test. "Anti-whiteboarding" people do not seem to recognize that there are many, many candidates who cannot write a loop. Those people cannot be employed as software engineers in most firms, and the wall must be made of brick.
  - swells34 3y ago
    I think you're missing the point of that comment. Yes, you don't want to hire someone to a programming role if they have absolutely no skill or knowledge in the subject and "cannot we write a loop". But that will become quite clear during the interview regardless if you have them doing some leetcode challenge or not. The important part to me is whether they can function in the present team, whether they can employ problem solving skills in a positive way. Sure, let's whiteboard out a problem, show me how you think about it, how you approach it, what steps you take to disassemble it. But also, if you're stuck do you ask for help? Can you discuss the problem without having a solution ready, do you have ideas about how to research it, can you present paths to progress? These are the really important attributes, not "have you memorized this wacky algorithmic solution in the last two weeks". Pure whiteboard tests are just stupid, don't shed light on someone's potential, and carry a context that makes a lot of intelligent high potential individuals freeze up. They select for the wrong traits.
    - dilyevsky 3y ago
      > But that will become quite clear during the interview regardless if you have them doing some leetcode challenge or not. No, no it won’t. I’ve done 300 interviews when i stopped counting and I’ve had all sorts of people who talk a good game but absolutely can’t code
      - Tknl 3y ago
        I second this. I've been interviewing candidates for around 6 years and I feel like the number of applicants with very strong communication skills but that cannot perform the most simple programming problems (basic loop, swapping two variables) went up. For my team and most teams at my employer we employ a simple test with a basic programming problem, code review problem and rudimentary system design problem similar to our actual work. We expect the juniors and medior to not succeed at all of these but do want to see how candidates think and communicate if they get stuck, but a junior that can't sort strings in any language of choice is a hard pass. Half of our candidates past initial phone screen fail this test. I do wonder though if this has something to do with the local (NL) market.
        mlhpdx 3y ago
        Each company I’ve worked with has attracted a slightly different group of applicants, so I find it easy to believe NL would be different yet. Whenever I start thinking the problem is the candidates I start asking myself “why?”. Why we came to the conclusion we did, why they applied, why we need more people on the team, etc.
        dilyevsky 3y ago
        It’s not your local market and this is not new. I interviewed folks at google head office in 2012 so we had people from all over the world and different experience levels and it was the same thing
      - Warwolt 3y ago
        What kinds of questions could you possibly ask that doesn't immediately surface this? A person who "cannot write a loop" will not be able to earnestly hold a conversation about programming.
  - dilyevsky 3y ago
    I realize now I just won’t be able to understand the crowd that wants an easy ride through interview loops and refuse to be put in a hot seat. Do they not care at all who they end up working with? Because you will 100% end up having half of your team incapable of writing software in such places
    - mlhpdx 3y ago
      I don’t accept the premise that being kind and respectful in an interview leads to underperforming teams. My current team is way, way into the “exceptional” range by common measures (DORA, etc). I don’t characterize what I do as “tests” because there is no wrong answer. I’ve never worked on software that didn’t have competition, and so literally different “right” answers. Maybe it is a test as there is an evaluation, an assessment of fit and ability of compliment the team’s current skills and way of working. That evaluation is uncompromising, not an “easy pass” by any means.
      - dilyevsky 3y ago
        “Kind” as in passing people who probably wont cut it? You’re only being kind in a feel good about yourself sense and just setting them up for getting pip’ed later on. What’s so kind about that?
        mlhpdx 3y ago
        That is not what I wrote, and not at all what I meant. A high-pressure "test" is cruel to folks who simply don't test well. Simple as that. Interviews can get at the skills of someone without putting them through that. I can't, so far, think of anyone who faked it past my interview teams over the years. It's not that hard to figure out if someone can actually code, has a sincere interest in it, respects others, craves improvement and measures their work by the value created. I really don't care if they test well. And, like I said, the bar is actually very high to join my teams. But my teams aren't prototype or manifestations of any theory of teams -- it's just folks getting the work done and enjoying it along the way. A team of different folks will need different things by definition and still be valuable individuals, each different, each worthy of respect.
water9 3y ago
Whiteboard tests are not a good way to evaluate people. It doesn’t tell you if they’re going to be a leader. It doesn’t tell you if they’re going to take an initiative. It doesn’t tell you if they’re going to be a person that complains all the time. It doesn’t tell you if they’re going to be able to solve problems they haven’t seen before which by nature will be all problems they encounter. Whiteboarding interviews are a good way to make the applicant feel bad about themselves so you can lowball them in salary, however
- danielvaughn 3y ago
  I agree, but the same can be said of any other interview technique. There's no rock solid, reliable way to determine in 30-60 minutes whether a candidate is going to be a good hire. I'm not in favor of whiteboards, but I'm also not necessarily in favor of anything else.
  - kekebo 3y ago
    I'm told that in the early days of the German branch of takeaway.com they would conduct interviews late and invite the interviewee to their after work beer and only hire the person if they thought they would enjoy future beers with them. Obviously only useful to somewhat determine personality but in my experience that is often a better predictor for a good hire than tech skills.
    - recursive 3y ago
      > often a better predictor for a good hire than tech skills On the other hand, the inability to write a nested for loop is a reliable predictor for a bad hire.
    - nradov 3y ago
      That is an unprofessional, abusive way to treat job applicants. It's going to filter out those who don't drink or who have evening family obligations. Any hiring manager who engages in these shenanigans should be ashamed of themselves. And in the USA at least, they could potentially be exposing the company to legal jeopardy.
ryandrake 3y ago
One of the problems I've seen constantly, for 10+ years (been working for 20+, interviewing others for approx. 10+) is that there has never been a "baseline" skill level that you could always count on when you got a candidate in front of you. Any given person's programming and problem solving skill level could be absolutely anywhere on the spectrum between 1. "super proficient, fluent in multiple languages, highly structured thinking, clearly articulates a solution, can mentally visualize over a range of 20 orders of magnitude" and 2. "literally has no idea how to solve a problem, program a computer to do it, or even describe coherently what they are thinking". And these two extremes can have the same resume. Some first level of the hiring funnel (HR, recruiter, or something) screens the candidate by looking at the resume and maybe doing an initial phone screen, and then this person gets dumped on the interviewer, and they 100% could be anywhere on that skill scale. So you always seem to have to start at "how do you turn a computer on?" and "write code that finds a substring in a string." It's really frustrating for the interviewers and I'm sure also insulting to actually good candidates. I've never been in one of these businesses, but I bet if a hospital interviews a doctor, they can at least count on basic knowledge of anatomy, and if a law firm interviews a lawyer, they can assume the person has read a law book. We have no such guarantees in software.
- majormajor 3y ago
  > I've never been in one of these businesses, but I bet if a hospital interviews a doctor, they can at least count on basic knowledge of anatomy, and if a law firm interviews a lawyer, they can assume the person has read a law book. We have no such guarantees in software. If the cost of those guarantees is formal specialized training costing hundreds of thousands of dollars, I'll stick with the world of phone screens - speaking as someone who's been both rejected-after-phone-screen and rejected others after a phone screen.
  - ryandrake 3y ago
    I used to feel the same way, and yes, reliance on credentials and formal training often serves the credentialing and training industries. But, I don't think our industry's current 'free for all' ultimately serves anyone. We should consider an inexpensive, very basic "programmer's bar exam" to establish a (admittedly very low) proficiency baseline. I'm not asking for a test that gatekeeps software engineering only to people who can write a compiler. I'm asking for a reliable document that says this person can write a loop and a conditional statement and can reason about how it works. Is this a lot to ask for?
ghaff 3y ago
And it goes all the way up to the top. I can name CEOs who were great hires who not at all an obvious fit for a tech company and I can name CEOs who certainly looked good on paper who were disasters.
pkdpic 3y ago
Everyone else getting a 500 level error? Is this a Mastodon issue?
- cratermoon 3y ago
  Probably the HN Hug of Death.
- solardev 3y ago
  It took like 2-3 minutes for mine to load. Here's the text: ------------------------- > Anders Borsch (@anders@mastodon.cyborch.com) I have interviewed 100s of candidates for software engineering positions. I’ve done take-home tests, in person challenges, pair programming with the candidates. All of them were awful experiences for me and especially for the candidate. I can only think of a single instance where a code challenge exposed a poor software engineer and I could definitely have made the same assessment just by talking to them. Lately I’ve stopped doing any software or mental puzzles. I don’t do any of that when I interview designers or QA people or HR people, so why would I be particularly toxic towards software engineers during the hiring process? Instead, I actually read their resumes (which is significantly quicker than doing interviews, asking them to repeat the same information), and then I ask them questions like: - Where do you get your tech news? - How do you learn about new technologies? - What do you most appreciate in your coworkers today? - What is a perfect workday like for you? I specifically avoid trap-style questions like “what is your greatest weakness?” or “why are you leaving your current job?” I recommend that you make a plan for what you want to learn about the candidate, e.g. “are they good at acquiring new skills?” or “do they share the same values as the team?” and then structure the interview around that. Be a non-toxic manager. Make your company look good during the interview process. Get better candidates.
  - suzzer99 3y ago
    My first 3 or 4 tech jobs started with interviews like this, which seemed to work fine. Then everyone fell in love with coding questions. It's funny to think some hiring managers might be going back to interviewing like every other job.
- 3y ago
mjr00 3y ago
> I recommend that you make a plan for what you want to learn about the candidate, e.g. “are they good at acquiring new skills?” or “do they share the same values as the team?” and then structure the interview around that. Generally what I want to learn about a candidate is "are they good at understanding plain-English requirements, can talk through their thought process as they problem solve, convert that solution into something that resembles working software, and we can have a decent conversation about what was built." As it turns out, whiteboard-type algorithms and system design questions are very good at this. Asking if someone keeps up with tech news (and call it a red flag if they don't) is just a way to keep your candidates within a certain social bubble. Which, honestly, is preferable if you're a < 50 person startup. But this doesn't scale. Plenty of software devs at IBM, Amazon, etc are just clocking in and out of their shifts and do a fine job of it. Not everyone needs to make career advancement in the tech industry their life.
- lentil_soup 3y ago
  > can talk through their thought process as they problem solve Why? Why can't I have a moment to think and focus without talking?
  - mjr00 3y ago
    Taking a moment to think is totally fine. But it's important to be able to explain what you're going to build before you actually build. Writing up clear design docs and architecture is critical in most senior technical positions. Obviously the expectation here changes on leveling--with juniors if they just code in silence before explaining their solution at the end, I'm less concerned. But if a senior just starts coding on the whiteboard I'll interrupt them and ask them to explain what their approach is, in English, before coding it up.
    - ipaddr 3y ago
      Do you think that's how coding happens? That's something you might see in a movie or rehearsed talk.
cube2222 3y ago
I’ve also done 100s of interviews, mostly for mid-senior positions and generally cv-reading and a non-quiz intro interview talking about various technologies and experiences work great. That said, I disagree about lack of any exercises. I think practical but not too time-consuming take-home assignments are nice and not too annoying (as long as they’re not the first step! That would be wasting candidates’ time.), and I’ve rejected tons of candidates based on the results of those, which is different to the author’s experience. Overall, I recommend people to really think about who they’re looking for, and heavily adjust their process to that. There’s no silver bullet, and the right process will vary greatly depending both on the seniority and the skillset you’re looking for.
mrazomor 3y ago
I'd probably fail the author's interview. As soon as you hit strong cultural disagreement (e.g. "new technologies" is a minefield), the interviewer has to be a mental Hulk to proceed without bias. Goodbye diversity. I've also done 100s of interviews (small and large companies). What I learnt: - CVs are useless except for leveling the candidate (which is done for me), - CVs are dangerous because they create a bias ("looks like an amazing candidate!" -- an then you get someone who is good, but not amazing as you expected and then you rate them lower than you should -- I intentionally skip the CVs as much as possible), - majority of the people will solve a simple problem at the algorithmic level, and then fail to code it up, - the best value is to give the candidate a SIMPLE coding question which produces a decent amount of code (25-50 lines), and observe them while solving it (their approach, bugs, etc.), - the signals I'm looking for: (1) can the candidate code fluently, (2) do they approach the problem in a systematic way, (3) can I communicate with them without friction.
- oglop 3y ago
  > As soon as you hit strong cultural disagreement (e.g. "new technologies" is a minefield) I am not sure what you mean by this. This is a question I ask and I’m concerned there’s something I’m missing here. Could you elaborate? > I intentionally skip the CVs as much as possible), That seems very odd. How do you comb through and make an initial choice of who to interview then? Also, seems unfair to not look at the work they’ve done over all the years. Personally, I’m a GitHub person. Show me what you’ve written and how active you are.
  - mrazomor 3y ago
    >> As soon as you hit strong cultural disagreement (e.g. "new technologies" is a minefield) > I am not sure what you mean by this. This is a question I ask and I’m concerned there’s something I’m missing here. Could you elaborate? Easy :). Take me: I hate Go and think Java is the best programming language there is. (My daily drivers today are C++ and Python.) NodeJs should've never been invented. I'm pretty opinionated when it comes to this. I'd still accept the position where I have to code in Go (been there and it was OK for both sides), but I wouldn't keep my mouth shut during the interview -- I wonder how that would go with 80% interviewers. > How do you comb through and make an initial choice of who to interview then? Sorry, I didn't put it explicit enough. I don't do the initial selection or leveling. This is done for me. The CVs are useful for this. But if you can avoid reading the CV (e.g. assessing only the raw skills), then you should.
ranting-moth 3y ago
But how do you test for psychological fit with the team? You can get a candidate that nails the tests and interviews. Meets the team and first impressions are good. Then 2 months in everyone realises the guy has a tantrum issue and is just an awful person when you get to know him ...
- drewcoo 3y ago
  How do you show candidates that your team is a good psychological fit for them? Do it that way.
deleted 3y ago
[deleted]
whoknowsidont 3y ago
The one thing that's always missing from this conversation is that the "reviewers", "raters", or "interviewers" _themselves_ might not have the skillsets to be able to adequately formulate a roughly accurate opinion of someone's strengths and weaknesses. Even worse, they might not be able to communicate the actual job requirements correctly, if they even understand the requirements and necessities themselves. Even worse than that, they often aren't as strong socially as they believe themselves to be. Being able to establish a comfortable atmosphere to connect with someone quickly is rare skillset within the human population, let alone in specific domains. There is a PRESUMPTION that people in the interviewer seat or management position can and should do this but honestly, after a few decades? I don't see it. We should be working to solve the "interviewer" problem first, not the other way around.
charles_f 3y ago
Interviewing is the single most divisive problem in software. I agree with the author on having a plan built for what you're looking for. I don't like the general "culture" questions because they're quite biased ("oh you're reading on HN! Me too!") I like behavior questions ("tell me about a time when") with a reference scale that explains your. It's not perfect, but it seems slightly more data driven than the rest I've experienced with. I take lots of notes and try to base my verdict on these. I hate leet-code, except at screening level, to validate that the person knows how to type on a computer. I like somewhat job-related exercises for more senior people, code-reviews, and with junior trying to teach them about something new you taught to multiple people and see if they catch it. I betcha half of the people here hate all these methods. In addition to what you're looking for, I advise trying to see what you miss with people you currently have in your team. (eg if they annoy you, find why and look for what they don't have).
absrec 3y ago
And have less rounds. I don't really understand why companies have multiple interview rounds. One of my friends recently gave three 1 hour rounds all technical. If you're afraid of making the wrong decision then if one person makes 1/5 bad hiring decisions then 3 people make 3/5 bad hiring decisions not 1/125.
- mjr00 3y ago
  These systems are made to optimize not making bad hires, not necessarily missing out on good hires. Given that, multiple rounds does help. Per your example, if each interviewer has a 1/5 chance of mistakenly approving a bad hire, then three interviewers does in fact reduce that to a 1/125 chance of the company making a bad hire.
bluedino 3y ago
I interviewed recently at a large GPU-related company, and the interviewer setup a bunch of softball questions. What's your favorite editor, what language do you like using for scripting, what's your favorite Linux distribution, do you have a homelab... We were having a decent back and forth and getting along, and then he hit me with the final question, "we really aren't supposed to ask, but what do you like to do in your spare time?" I mentioned that I had a 2 and 3 year old and joked that I didn't have much free time anymore, and said I liked working in the garage with my hands to get a break from computers. I didn't realize I gave the wrong answer until an hour or two later (based upon the rest of our conversion and his questions). It would have been the right time to show a few personal projects on GitHub.
- ptsneves 3y ago
  Perhaps but I think you shouldn’t feel you were disqualified because you missed the GitHub projects. Stating that you are a father is an honest answer and also sets the expectations on whether you are going to pull all nighters or your dedication matches a fresh grad. As a fellow father I would rather there is an honest match than be surprised half way into onboarding with the stress that ensues. I try to focus on being the candidate that knows their thing and that will improve the software quality so there are no all nighters. Employers value that and it is something I know I can show up as an advantage. Recommendations mentioning that, help.
fishtoaster 3y ago
I feel like 99% of eng interview advice sounds just like this: "I've interviewed a bazillion people, everyone else is doing it wrong, here's the one good way." Honestly, I think a lot of it is akin to medieval quackery. "I've treated hundreds of patients with leeches and the large majority of them eventually recovered - you should listen to me!" I wish that we, as an industry, would spend less time reinventing interviewing from first principles. There are decades of research on how to interview people effectively. I highly recommend Schmidt + Hunter's meta-analysis (https://www.researchgate.net/publication/232564809_The_Validity_and_Utility_of_Selection_Methods_in_Personnel_Psychology https://www.researchgate.net/publication/232564809_The_Valid...) as a starting point. From my read of the research: 1. Use work-sample tests. Yes, they're annoying, but they're high-signal. Take-home tests, online tests, in-person tests, trial periods - there are plenty of options here, but it seems clear this is the most effective way. 2. Use structured interviews. Engineers love to just have loose conversations and judge people based on that, but structured > unstructured. Plus (just my guess here), I suspect unstructured interviews leave a lot more room for bias. 3. Plenty of techniques are effective on their own (eg references), but add minimal effectiveness when you're already doing a more effective test (eg work sample) and are therefore pretty much wastes.
- ghaff 3y ago
  >1. Use work-sample tests. Yes, they're annoying, but they're high-signal. Take-home tests, online tests, in-person tests, trial periods - there are plenty of options here, but it seems clear this is the most effective way. I'd argue that you're basically pushing the workload onto the applicant. Now, sometimes it makes a lot of sense to the degree that the applicant can just share a work sample with you--GitHub, published report/paper/other writing, a video of a presentation. In fact, I've hired for non-developer roles where some sort of work sample is pretty much non-negotiable. But recognize this creates biases (and acts as a filter) where something needs to be created from scratch.
- threatofrain 3y ago
  One of the most stable and effective findings in I/O psychology is the predictive value of IQ on job performance, which unfortunately is also often legally gray. Maybe companies know what they're doing with coding challenges as an under-the-legal-radar proxy for IQ? Especially if companies are hiring young adults straight out of college with little to differentiate themselves.
HarHarVeryFunny 3y ago
IMO the best way to interview a software candidate is just to get them talking about the stuff on their resume. Ask for overviews, diagrams, justifications, etc, etc. If you really know something you will have a very clear mental model of it and be able to discuss it fluently. Leetcode challenges are a waste of everyone's time. If you are a competent developer then you can google for algorithmic solutions if you really need to, but honestly how often does the need come up, and is googling for suggestions really the hardest part of the project ?! The only thing that doing well on these type of problems proves is that you've been willing to put the practice time in to get good at them.
throwadf2342 3y ago
I can't shake the feeling that time invested in gaming interviews is a big suckers bet. Seems wiser to invest that time in health & entrepreneurship.
deleted 3y ago
[deleted]
beej71 3y ago
Amen. My interview questions eventually settled to having the candidate bring in a sample of their code and then teaching me how it worked. We'd talk about what it did, what they thought they'd change to make it better, and so on. Learned a ton really quickly and didn't waste anyone's time. The last tech job I interviewed for they had me spend a lot of time working a sample application. When I thought about how many person hours were going into that across all the candidates, I immediately felt the company didn't have a sense of efficiency. Sure, it didn't cost them, but the fact they were fine just wasting time like that was telling. Didn't get that job. But got a better one. :)

58 points by riidom 3y ago

I don’t disagree with the sentiment but the tools aren’t the problem, it’s the delivery. A puzzle can might be toxic if it’s a test, but constructive as a gimmick used to explore communication. Likewise for coding exercises. It’s all pretty easy if respect for the human is genuine, and destructive for all when faked.

H8crilA 3y ago
But it is a test. "Anti-whiteboarding" people do not seem to recognize that there are many, many candidates who cannot write a loop. Those people cannot be employed as software engineers in most firms, and the wall must be made of brick.
- swells34 3y ago
  I think you're missing the point of that comment. Yes, you don't want to hire someone to a programming role if they have absolutely no skill or knowledge in the subject and "cannot we write a loop". But that will become quite clear during the interview regardless if you have them doing some leetcode challenge or not. The important part to me is whether they can function in the present team, whether they can employ problem solving skills in a positive way. Sure, let's whiteboard out a problem, show me how you think about it, how you approach it, what steps you take to disassemble it. But also, if you're stuck do you ask for help? Can you discuss the problem without having a solution ready, do you have ideas about how to research it, can you present paths to progress? These are the really important attributes, not "have you memorized this wacky algorithmic solution in the last two weeks". Pure whiteboard tests are just stupid, don't shed light on someone's potential, and carry a context that makes a lot of intelligent high potential individuals freeze up. They select for the wrong traits.
  - dilyevsky 3y ago
    > But that will become quite clear during the interview regardless if you have them doing some leetcode challenge or not. No, no it won’t. I’ve done 300 interviews when i stopped counting and I’ve had all sorts of people who talk a good game but absolutely can’t code
    - Tknl 3y ago
      I second this. I've been interviewing candidates for around 6 years and I feel like the number of applicants with very strong communication skills but that cannot perform the most simple programming problems (basic loop, swapping two variables) went up. For my team and most teams at my employer we employ a simple test with a basic programming problem, code review problem and rudimentary system design problem similar to our actual work. We expect the juniors and medior to not succeed at all of these but do want to see how candidates think and communicate if they get stuck, but a junior that can't sort strings in any language of choice is a hard pass. Half of our candidates past initial phone screen fail this test. I do wonder though if this has something to do with the local (NL) market.
      - mlhpdx 3y ago
        Each company I’ve worked with has attracted a slightly different group of applicants, so I find it easy to believe NL would be different yet. Whenever I start thinking the problem is the candidates I start asking myself “why?”. Why we came to the conclusion we did, why they applied, why we need more people on the team, etc.
      - dilyevsky 3y ago
        It’s not your local market and this is not new. I interviewed folks at google head office in 2012 so we had people from all over the world and different experience levels and it was the same thing
    - Warwolt 3y ago
      What kinds of questions could you possibly ask that doesn't immediately surface this? A person who "cannot write a loop" will not be able to earnestly hold a conversation about programming.
- dilyevsky 3y ago
  I realize now I just won’t be able to understand the crowd that wants an easy ride through interview loops and refuse to be put in a hot seat. Do they not care at all who they end up working with? Because you will 100% end up having half of your team incapable of writing software in such places
  - mlhpdx 3y ago
    I don’t accept the premise that being kind and respectful in an interview leads to underperforming teams. My current team is way, way into the “exceptional” range by common measures (DORA, etc). I don’t characterize what I do as “tests” because there is no wrong answer. I’ve never worked on software that didn’t have competition, and so literally different “right” answers. Maybe it is a test as there is an evaluation, an assessment of fit and ability of compliment the team’s current skills and way of working. That evaluation is uncompromising, not an “easy pass” by any means.
    - dilyevsky 3y ago
      “Kind” as in passing people who probably wont cut it? You’re only being kind in a feel good about yourself sense and just setting them up for getting pip’ed later on. What’s so kind about that?
      - mlhpdx 3y ago
        That is not what I wrote, and not at all what I meant. A high-pressure "test" is cruel to folks who simply don't test well. Simple as that. Interviews can get at the skills of someone without putting them through that. I can't, so far, think of anyone who faked it past my interview teams over the years. It's not that hard to figure out if someone can actually code, has a sincere interest in it, respects others, craves improvement and measures their work by the value created. I really don't care if they test well. And, like I said, the bar is actually very high to join my teams. But my teams aren't prototype or manifestations of any theory of teams -- it's just folks getting the work done and enjoying it along the way. A team of different folks will need different things by definition and still be valuable individuals, each different, each worthy of respect.

water9 3y ago

Whiteboard tests are not a good way to evaluate people. It doesn’t tell you if they’re going to be a leader. It doesn’t tell you if they’re going to take an initiative. It doesn’t tell you if they’re going to be a person that complains all the time. It doesn’t tell you if they’re going to be able to solve problems they haven’t seen before which by nature will be all problems they encounter. Whiteboarding interviews are a good way to make the applicant feel bad about themselves so you can lowball them in salary, however

danielvaughn 3y ago
I agree, but the same can be said of any other interview technique. There's no rock solid, reliable way to determine in 30-60 minutes whether a candidate is going to be a good hire. I'm not in favor of whiteboards, but I'm also not necessarily in favor of anything else.
- kekebo 3y ago
  I'm told that in the early days of the German branch of takeaway.com they would conduct interviews late and invite the interviewee to their after work beer and only hire the person if they thought they would enjoy future beers with them. Obviously only useful to somewhat determine personality but in my experience that is often a better predictor for a good hire than tech skills.
  - recursive 3y ago
    > often a better predictor for a good hire than tech skills On the other hand, the inability to write a nested for loop is a reliable predictor for a bad hire.
  - nradov 3y ago
    That is an unprofessional, abusive way to treat job applicants. It's going to filter out those who don't drink or who have evening family obligations. Any hiring manager who engages in these shenanigans should be ashamed of themselves. And in the USA at least, they could potentially be exposing the company to legal jeopardy.

ryandrake 3y ago

One of the problems I've seen constantly, for 10+ years (been working for 20+, interviewing others for approx. 10+) is that there has never been a "baseline" skill level that you could always count on when you got a candidate in front of you. Any given person's programming and problem solving skill level could be absolutely anywhere on the spectrum between 1. "super proficient, fluent in multiple languages, highly structured thinking, clearly articulates a solution, can mentally visualize over a range of 20 orders of magnitude" and 2. "literally has no idea how to solve a problem, program a computer to do it, or even describe coherently what they are thinking". And these two extremes can have the same resume. Some first level of the hiring funnel (HR, recruiter, or something) screens the candidate by looking at the resume and maybe doing an initial phone screen, and then this person gets dumped on the interviewer, and they 100% could be anywhere on that skill scale. So you always seem to have to start at "how do you turn a computer on?" and "write code that finds a substring in a string." It's really frustrating for the interviewers and I'm sure also insulting to actually good candidates. I've never been in one of these businesses, but I bet if a hospital interviews a doctor, they can at least count on basic knowledge of anatomy, and if a law firm interviews a lawyer, they can assume the person has read a law book. We have no such guarantees in software.

majormajor 3y ago
> I've never been in one of these businesses, but I bet if a hospital interviews a doctor, they can at least count on basic knowledge of anatomy, and if a law firm interviews a lawyer, they can assume the person has read a law book. We have no such guarantees in software. If the cost of those guarantees is formal specialized training costing hundreds of thousands of dollars, I'll stick with the world of phone screens - speaking as someone who's been both rejected-after-phone-screen and rejected others after a phone screen.
- ryandrake 3y ago
  I used to feel the same way, and yes, reliance on credentials and formal training often serves the credentialing and training industries. But, I don't think our industry's current 'free for all' ultimately serves anyone. We should consider an inexpensive, very basic "programmer's bar exam" to establish a (admittedly very low) proficiency baseline. I'm not asking for a test that gatekeeps software engineering only to people who can write a compiler. I'm asking for a reliable document that says this person can write a loop and a conditional statement and can reason about how it works. Is this a lot to ask for?

ghaff 3y ago

And it goes all the way up to the top. I can name CEOs who were great hires who not at all an obvious fit for a tech company and I can name CEOs who certainly looked good on paper who were disasters.

pkdpic 3y ago

Everyone else getting a 500 level error? Is this a Mastodon issue?

cratermoon 3y ago
Probably the HN Hug of Death.
solardev 3y ago
It took like 2-3 minutes for mine to load. Here's the text: ------------------------- > Anders Borsch (@anders@mastodon.cyborch.com) I have interviewed 100s of candidates for software engineering positions. I’ve done take-home tests, in person challenges, pair programming with the candidates. All of them were awful experiences for me and especially for the candidate. I can only think of a single instance where a code challenge exposed a poor software engineer and I could definitely have made the same assessment just by talking to them. Lately I’ve stopped doing any software or mental puzzles. I don’t do any of that when I interview designers or QA people or HR people, so why would I be particularly toxic towards software engineers during the hiring process? Instead, I actually read their resumes (which is significantly quicker than doing interviews, asking them to repeat the same information), and then I ask them questions like: - Where do you get your tech news? - How do you learn about new technologies? - What do you most appreciate in your coworkers today? - What is a perfect workday like for you? I specifically avoid trap-style questions like “what is your greatest weakness?” or “why are you leaving your current job?” I recommend that you make a plan for what you want to learn about the candidate, e.g. “are they good at acquiring new skills?” or “do they share the same values as the team?” and then structure the interview around that. Be a non-toxic manager. Make your company look good during the interview process. Get better candidates.
- suzzer99 3y ago
  My first 3 or 4 tech jobs started with interviews like this, which seemed to work fine. Then everyone fell in love with coding questions. It's funny to think some hiring managers might be going back to interviewing like every other job.
3y ago

mjr00 3y ago

> I recommend that you make a plan for what you want to learn about the candidate, e.g. “are they good at acquiring new skills?” or “do they share the same values as the team?” and then structure the interview around that. Generally what I want to learn about a candidate is "are they good at understanding plain-English requirements, can talk through their thought process as they problem solve, convert that solution into something that resembles working software, and we can have a decent conversation about what was built." As it turns out, whiteboard-type algorithms and system design questions are very good at this. Asking if someone keeps up with tech news (and call it a red flag if they don't) is just a way to keep your candidates within a certain social bubble. Which, honestly, is preferable if you're a < 50 person startup. But this doesn't scale. Plenty of software devs at IBM, Amazon, etc are just clocking in and out of their shifts and do a fine job of it. Not everyone needs to make career advancement in the tech industry their life.

lentil_soup 3y ago
> can talk through their thought process as they problem solve Why? Why can't I have a moment to think and focus without talking?
- mjr00 3y ago
  Taking a moment to think is totally fine. But it's important to be able to explain what you're going to build before you actually build. Writing up clear design docs and architecture is critical in most senior technical positions. Obviously the expectation here changes on leveling--with juniors if they just code in silence before explaining their solution at the end, I'm less concerned. But if a senior just starts coding on the whiteboard I'll interrupt them and ask them to explain what their approach is, in English, before coding it up.
  - ipaddr 3y ago
    Do you think that's how coding happens? That's something you might see in a movie or rehearsed talk.

cube2222 3y ago

I’ve also done 100s of interviews, mostly for mid-senior positions and generally cv-reading and a non-quiz intro interview talking about various technologies and experiences work great. That said, I disagree about lack of any exercises. I think practical but not too time-consuming take-home assignments are nice and not too annoying (as long as they’re not the first step! That would be wasting candidates’ time.), and I’ve rejected tons of candidates based on the results of those, which is different to the author’s experience. Overall, I recommend people to really think about who they’re looking for, and heavily adjust their process to that. There’s no silver bullet, and the right process will vary greatly depending both on the seniority and the skillset you’re looking for.

mrazomor 3y ago

I'd probably fail the author's interview. As soon as you hit strong cultural disagreement (e.g. "new technologies" is a minefield), the interviewer has to be a mental Hulk to proceed without bias. Goodbye diversity. I've also done 100s of interviews (small and large companies). What I learnt: - CVs are useless except for leveling the candidate (which is done for me), - CVs are dangerous because they create a bias ("looks like an amazing candidate!" -- an then you get someone who is good, but not amazing as you expected and then you rate them lower than you should -- I intentionally skip the CVs as much as possible), - majority of the people will solve a simple problem at the algorithmic level, and then fail to code it up, - the best value is to give the candidate a SIMPLE coding question which produces a decent amount of code (25-50 lines), and observe them while solving it (their approach, bugs, etc.), - the signals I'm looking for: (1) can the candidate code fluently, (2) do they approach the problem in a systematic way, (3) can I communicate with them without friction.

oglop 3y ago
> As soon as you hit strong cultural disagreement (e.g. "new technologies" is a minefield) I am not sure what you mean by this. This is a question I ask and I’m concerned there’s something I’m missing here. Could you elaborate? > I intentionally skip the CVs as much as possible), That seems very odd. How do you comb through and make an initial choice of who to interview then? Also, seems unfair to not look at the work they’ve done over all the years. Personally, I’m a GitHub person. Show me what you’ve written and how active you are.
- mrazomor 3y ago
  >> As soon as you hit strong cultural disagreement (e.g. "new technologies" is a minefield) > I am not sure what you mean by this. This is a question I ask and I’m concerned there’s something I’m missing here. Could you elaborate? Easy :). Take me: I hate Go and think Java is the best programming language there is. (My daily drivers today are C++ and Python.) NodeJs should've never been invented. I'm pretty opinionated when it comes to this. I'd still accept the position where I have to code in Go (been there and it was OK for both sides), but I wouldn't keep my mouth shut during the interview -- I wonder how that would go with 80% interviewers. > How do you comb through and make an initial choice of who to interview then? Sorry, I didn't put it explicit enough. I don't do the initial selection or leveling. This is done for me. The CVs are useful for this. But if you can avoid reading the CV (e.g. assessing only the raw skills), then you should.

ranting-moth 3y ago

But how do you test for psychological fit with the team? You can get a candidate that nails the tests and interviews. Meets the team and first impressions are good. Then 2 months in everyone realises the guy has a tantrum issue and is just an awful person when you get to know him ...

drewcoo 3y ago
How do you show candidates that your team is a good psychological fit for them? Do it that way.

deleted 3y ago

[deleted]

whoknowsidont 3y ago

The one thing that's always missing from this conversation is that the "reviewers", "raters", or "interviewers" _themselves_ might not have the skillsets to be able to adequately formulate a roughly accurate opinion of someone's strengths and weaknesses. Even worse, they might not be able to communicate the actual job requirements correctly, if they even understand the requirements and necessities themselves. Even worse than that, they often aren't as strong socially as they believe themselves to be. Being able to establish a comfortable atmosphere to connect with someone quickly is rare skillset within the human population, let alone in specific domains. There is a PRESUMPTION that people in the interviewer seat or management position can and should do this but honestly, after a few decades? I don't see it. We should be working to solve the "interviewer" problem first, not the other way around.

charles_f 3y ago

Interviewing is the single most divisive problem in software. I agree with the author on having a plan built for what you're looking for. I don't like the general "culture" questions because they're quite biased ("oh you're reading on HN! Me too!") I like behavior questions ("tell me about a time when") with a reference scale that explains your. It's not perfect, but it seems slightly more data driven than the rest I've experienced with. I take lots of notes and try to base my verdict on these. I hate leet-code, except at screening level, to validate that the person knows how to type on a computer. I like somewhat job-related exercises for more senior people, code-reviews, and with junior trying to teach them about something new you taught to multiple people and see if they catch it. I betcha half of the people here hate all these methods. In addition to what you're looking for, I advise trying to see what you miss with people you currently have in your team. (eg if they annoy you, find why and look for what they don't have).

absrec 3y ago

And have less rounds. I don't really understand why companies have multiple interview rounds. One of my friends recently gave three 1 hour rounds all technical. If you're afraid of making the wrong decision then if one person makes 1/5 bad hiring decisions then 3 people make 3/5 bad hiring decisions not 1/125.

mjr00 3y ago
These systems are made to optimize not making bad hires, not necessarily missing out on good hires. Given that, multiple rounds does help. Per your example, if each interviewer has a 1/5 chance of mistakenly approving a bad hire, then three interviewers does in fact reduce that to a 1/125 chance of the company making a bad hire.

bluedino 3y ago

I interviewed recently at a large GPU-related company, and the interviewer setup a bunch of softball questions. What's your favorite editor, what language do you like using for scripting, what's your favorite Linux distribution, do you have a homelab... We were having a decent back and forth and getting along, and then he hit me with the final question, "we really aren't supposed to ask, but what do you like to do in your spare time?" I mentioned that I had a 2 and 3 year old and joked that I didn't have much free time anymore, and said I liked working in the garage with my hands to get a break from computers. I didn't realize I gave the wrong answer until an hour or two later (based upon the rest of our conversion and his questions). It would have been the right time to show a few personal projects on GitHub.

ptsneves 3y ago
Perhaps but I think you shouldn’t feel you were disqualified because you missed the GitHub projects. Stating that you are a father is an honest answer and also sets the expectations on whether you are going to pull all nighters or your dedication matches a fresh grad. As a fellow father I would rather there is an honest match than be surprised half way into onboarding with the stress that ensues. I try to focus on being the candidate that knows their thing and that will improve the software quality so there are no all nighters. Employers value that and it is something I know I can show up as an advantage. Recommendations mentioning that, help.

fishtoaster 3y ago

I feel like 99% of eng interview advice sounds just like this: "I've interviewed a bazillion people, everyone else is doing it wrong, here's the one good way." Honestly, I think a lot of it is akin to medieval quackery. "I've treated hundreds of patients with leeches and the large majority of them eventually recovered - you should listen to me!" I wish that we, as an industry, would spend less time reinventing interviewing from first principles. There are decades of research on how to interview people effectively. I highly recommend Schmidt + Hunter's meta-analysis (https://www.researchgate.net/publication/232564809_The_Validity_and_Utility_of_Selection_Methods_in_Personnel_Psychology https://www.researchgate.net/publication/232564809_The_Valid...) as a starting point. From my read of the research: 1. Use work-sample tests. Yes, they're annoying, but they're high-signal. Take-home tests, online tests, in-person tests, trial periods - there are plenty of options here, but it seems clear this is the most effective way. 2. Use structured interviews. Engineers love to just have loose conversations and judge people based on that, but structured > unstructured. Plus (just my guess here), I suspect unstructured interviews leave a lot more room for bias. 3. Plenty of techniques are effective on their own (eg references), but add minimal effectiveness when you're already doing a more effective test (eg work sample) and are therefore pretty much wastes.

ghaff 3y ago
>1. Use work-sample tests. Yes, they're annoying, but they're high-signal. Take-home tests, online tests, in-person tests, trial periods - there are plenty of options here, but it seems clear this is the most effective way. I'd argue that you're basically pushing the workload onto the applicant. Now, sometimes it makes a lot of sense to the degree that the applicant can just share a work sample with you--GitHub, published report/paper/other writing, a video of a presentation. In fact, I've hired for non-developer roles where some sort of work sample is pretty much non-negotiable. But recognize this creates biases (and acts as a filter) where something needs to be created from scratch.
threatofrain 3y ago
One of the most stable and effective findings in I/O psychology is the predictive value of IQ on job performance, which unfortunately is also often legally gray. Maybe companies know what they're doing with coding challenges as an under-the-legal-radar proxy for IQ? Especially if companies are hiring young adults straight out of college with little to differentiate themselves.

HarHarVeryFunny 3y ago

IMO the best way to interview a software candidate is just to get them talking about the stuff on their resume. Ask for overviews, diagrams, justifications, etc, etc. If you really know something you will have a very clear mental model of it and be able to discuss it fluently. Leetcode challenges are a waste of everyone's time. If you are a competent developer then you can google for algorithmic solutions if you really need to, but honestly how often does the need come up, and is googling for suggestions really the hardest part of the project ?! The only thing that doing well on these type of problems proves is that you've been willing to put the practice time in to get good at them.

throwadf2342 3y ago

I can't shake the feeling that time invested in gaming interviews is a big suckers bet. Seems wiser to invest that time in health & entrepreneurship.

deleted 3y ago

[deleted]

beej71 3y ago

Amen. My interview questions eventually settled to having the candidate bring in a sample of their code and then teaching me how it worked. We'd talk about what it did, what they thought they'd change to make it better, and so on. Learned a ton really quickly and didn't waste anyone's time. The last tech job I interviewed for they had me spend a lot of time working a sample application. When I thought about how many person hours were going into that across all the candidates, I immediately felt the company didn't have a sense of efficiency. Sure, it didn't cost them, but the fact they were fine just wasting time like that was telling. Didn't get that job. But got a better one. :)