14 ms·

I can tell you how I do it and would certainly recommend it as the way it should be done. For some context, I've been interviewing software engineers for about

by jjav 7y ago

I can tell you how I do it and would certainly recommend it as the way it should be done. For some context, I've been interviewing software engineers for about 25 years in companies ranging from established multi-nationals to tiny startups in very fast headcount-growth mode. I'm in silicon valley. I can say that I've never regretted a hire I said yes to, so the method works to my satisfaction. It'd be nice to think I have some special skill here but I really don't. This is just how interviewing was done in the 90s. To some of the younger generations, I've been told it sounds crazy. If you send me your resume I'll actually read it, carefully. If the person described in this resume fits the background experience the role needs, you get an interview. During the interview we'll talk about all those projects you worked on that are relevant to this role. Which parts you enjoyed the best and why? Which parts were boring and why? Which parts were the most challenging and why? What you find too easy and why? What would you have done differently? Could you have? If you were to do the same project all over how would you approach it? Other open ended conversations along these lines. I don't ask anyone to whiteboard code, that's not part of the job so it's not part of the interview. No puzzles, no trivia-pursuit style questions. It works great. You can't BS your way through such a conversation with a senior technical peer if you didn't actually do the work described in the resume. You just can't. It is, however, vital that the interviewer must be a expert in the field.

zerr 7y ago
I wonder if there is a list of companies doing interviews this way.
- norcalli 7y ago
  I use the same technique (and I'm 26 now, so relatively young) and it's how I've always interviewed others. Granted, I've only worked at smallish startups, but, either way, the company didn't care about my technique for evaluation, and just my final "yes", "no," or "maybe." So, I think it depends on the engineer. If someone can keep up in a technical conversation about their background with me and answer every question I have about a technical project they did, then basically they pass. It works especially well even if I'm not familiar with their project, because I have an opportunity to learn, so I can ask any question that comes to mind until they teach me what they learned. I did hire someone that I regretted, though, but to be fair, this was among my first interviews. The mistake I made was getting too easily caught talking about programming and technical things without specifically diving deep into his past project. He and I vibed quickly and I liked him, and that felt like enough, but after only a week it seemed obvious that he wasn't going to be producing much code, and we let him go. Otherwise, I've been happy and my ability to discern has only gotten better as I became more experienced. I got a little offtopic, but my main answer to your question was "if the company leaves the decision up to a majority of engineers saying 'yes', then a lot of companies do this." Google does this, the startups I've worked at do this, and some of my friends companies do this.
- Jach 7y ago
  Not exactly that, but you might like to peruse https://github.com/poteto/hiring-without-whiteboards https://github.com/poteto/hiring-without-whiteboards Reader beware, of course, I know at least one company on there shouldn't be.
  - zerr 7y ago
    Oh, I see, they use the term "whiteboard" as a synonym for leetcode-like riddles.
lolptdr 7y ago
Thank you for your refreshing point of view. I'm a mid-level software developer and I was on the other side of the table as a junior web developer and encountered this same style of questioning and embraced it. This is my go-to style when interviewing because if you are confident in the lingo and zeitgeist of development, there is no way they can bullshit there way and lie through their teeth on their own experiences. It is very easy to tell. Whiteboarding doesn't give that detection since it is too broad of a spectrum to start as a indicator of experience.
- rimliu 7y ago
  Exactly. If you were really working with the stuff you do you will know all the common pain points, workarounds, etc. Unless the interviewer is alien to those things themselves there can be instant "one of us" recognition.
novok 7y ago
It’s also very subjective and hard to train for or to audit externally. When a company gets too big, you can’t properly vet hiring personally anymore, so you have to scale it. You don’t want ‘bozo cliques’ to form, so you make a semi-objective process like ‘solve this algorithmic question’ as part of the interview loop. I think execs and the founders doing a final review before hiring all engineers comes from that fear. Then other companies cargo cult interview processes from larger companies and the trend propagates. If you want to ‘hack hiring’ as a smaller company, you should use hard to scale processes like the one described in the parent post.
- rimliu 7y ago
  Well, if you get too big to get things done well, maybe not get too big?
  - newjersey 7y ago
    > Well, if you get too big to get things done well, maybe not get too big? I love this idea but my old history professor (who I pretty much disagree with on everything except this) used to always say "follow the money". What are the incentives that all the parties have for and against growing companies bigger?
jakebasile 7y ago
These are the kinds of interviews I love, and I appreciate that they're still given at some places. I agree, it's nearly impossible to bullshit your way through this kind of a conversational interview but people still think they need to ask trivia questions.
goatinaboat 7y ago
This is just how interviewing was done in the 90s I agree with your approach and use it myself but one thing is different now and that’s the proliferation of tiny skills. Back then you would have a few big skills, you would claim to know one or two main languages, one or two databases and so on. Now people list hundreds - literally hundreds - of skills sometimes. And there’s no way to tell on reading if they really know it, or just saw it once and maybe did a tutorial or “hello world”. People now will add a skill to their CV if they’ve done it for a hour total in their entire lives! Or read a blog post about it. It is a massive time sink to pick through that.
- jjav 7y ago
  If we're talking about the same kind of thing, I don't consider those to be skills. For example I've seen resumes which list every javascript library they've ever used. Or every UNIX command they know how to run or similar minutia. This tells me the person doesn't know the difference between skills and implementation details, so I don't need to proceed to an interview.
  - jishnum 7y ago
    I'd argue that this is a resume overindexed on getting past recruiting filters looking for specific JavaScript libraries or UNIX commands. Even the recruiters action may not be necessarily bad - startups with a decided tech stack might decide they are not able to provide the time for a new hire to ramp up. Effectively you penalise not catering the candidate resume to what you are looking for or deem important.
    - rhizome 7y ago
      Does anybody even know anything about these resume filters? They seem legendary, or I'd think there would be a best practice by now.
      - detaro 7y ago
        Various vendors of software in that space claim they are best practice, e.g. IBM: https://www.ibm.com/talent-management/hr-topic-hub/applicant-tracking-system https://www.ibm.com/talent-management/hr-topic-hub/applicant..., https://appsource.microsoft.com/en-us/product/web-apps/cem_business_solutions.applicant_tracking_system https://appsource.microsoft.com/en-us/product/web-apps/cem_b... promotes keyword matching as a feature, ...
virgilp 7y ago
> I can say that I've never regretted a hire I said yes to, so the method works to my satisfaction. This may just mean that you say a lot Of wrong “No”s. To get very high precision or very high recall is really easy... what you must measure is your F-score
- norcalli 7y ago
  The regret metric is different for a false "no" compared to a false "yes." I'd rather say "no" to someone who could've been great than "yes" to someone who wasn't, so I would say that it isn't that important.
  - virgilp 7y ago
    Depends a lot on the company and situation (how easy is it to fire a bad hire? Does the company do it?) - but you can use something like F2 or F0.5 where relevant. Remember Facebook rejected Brian Acton, and paid billions for that. An oversimplification, I agree, but the larger point is that people tend to dismiss too easily the impact of bad “no hire” decisions, compared to the bad “hire” decisions. Just because you can’t or don’t measure it, doesn’t mean that the impact may not be arbitrarily large.
  - ryandrake 7y ago
    This comment boils down precisely what I’ve always thought is the key problem in tech hiring. Companies overestimate the cost of a bad hire and underestimate the benefit of taking a risk and having it pay off. To borrow from poker: it’s commonly understood that if you’re not “caught bluffing” at least a little, it means you’re not bluffing enough. If your hiring process results in zero bad hires, you are playing it way too safe and I guarantee you are missing out on phenomenal candidates.
    - DavidWoof 7y ago
      I think you're wrong. I think companies are completely correct in assessing the cost of a bad hire to be much greater than the loss of a good hire, assuming you're getting enough good hires to fill the positions available. Now, this assumes that you're not missing out on great hires; in other words, it assumes that the good hires you miss are at the bottom of your hiring range. Your point might be that this can't be guaranteed, and while that may be true, it's unlikely that any tweaks to a given hiring process are going to bring them in either.
baddox 7y ago
My immediate reaction is that the problem with that approach is that it’s simply too expensive for the hiring company, in the same way that take-home programming challenges are too expensive for the applicants. A company trying to hire engineers can easily give a take-home programming challenge to a dozen engineer applicants and take very little time analyzing the submissions. That’s pretty unfair. But it also feels a bit untenable for a senior engineer at a hiring company to have very deep investigations of each applicant’s work history. Another problem is objectivity. If your company’s engineering hiring process relies heavily on a senior engineer’s subjective impression of an applicant, you’re going to have big problems with your own engineers’ biases, whether subconscious or not. Expect to hear a lot of evaluations like “well, the applicant did seem to have good knowledge and experience, but I just wasn’t impressed for some reason.”
- EliRivers 7y ago
  My immediate reaction is that the problem with that approach is that it’s simply too expensive for the hiring company Is it? The cost of hiring the wrong person can be huge. Not just agency fees if they came through a recruiter (those aren't cheap!), but also all the time people then spend on the bad employee and all the damage that person does before the mistake is rectified. If this system of reading the resumes and then spending a few hours of senior employee time on an interview can reliably find good employees, that's an absolute bargain.
  - ozim 7y ago
    If it really would be, then current state of things would not go into "making it cheap". I think for entry level employee, or just a regular employee, cost of bad hire is not that high. If turnover on those positions is high, then it also makes things cheaper just to fill in the seat. I have seen not that brilliant employees that still were earning company money. Just you know "we hire only best of the best" is a scam. Hiring bad manager or a senior dev, can be bad I agree. So it is not so good to use the same hiring way for seniors and juniors, but unfortunately companies treat senior devs also like juniors.
  - goatinaboat 7y ago
thedufer 7y ago
> I can say that I've never regretted a hire I said yes to, so the method works to my satisfaction. You think this is a claim about how good your hiring practice is, but the only way I can think to read this is as a point about how little hiring you do or how little evaluation of hires you do. In the real world, perfection isn't possible, so claims of it are a sign of inexperience or naivete.
- marliechiller 7y ago
  you're misconstruing perfection with satisfaction. entirely different things
wincent 7y ago
These questions should definitely be part of the interview process, but not all of it. I've done a lot of these kinds of interviews and I've definitely seen candidates that speak impressively but fail basic technical tests. If you don't actually verify the technical problem-solving ability of the candidate in some way you're forgoing signal that can massively increase the confidence you can have in your decision.
- sieabahlpark 7y ago
  Anecdotal but we've hired an engineer who was pretty decent in the interview but couldn't figure out how an if statement worked in a legacy codebase. Yes, I wrote that right. He struggled to understand conditionals in general when building his own logic. The guy even had a masters degree.
  - bakuninsbart 7y ago
    So I had the same problem for a while, it was quite absurd, because I got through my uni courses, could decently code in Haskell and some other things, but never figured out the appropriate position to put an if clause. I then did a course on assembly programming and having to be extremely structured and using jump statements actually helped me a lot in easier to use programming languages. Point of this comment is that people might be good at a lot of things, while just having some weird brainfuse related to a very specific thing. That said, not using if statements makes programming rather difficult.
    - sieabahlpark 7y ago
      No see I wish they had any redeeming skill, he always asked an engineer to assist him with anything. They couldn't figure out anything on their own. It was shocking someone could complete the interview (small problem with a solution that is essentially explained, make x do y) and completely fail at building their own solutions without guidance
  - dorfsmay 7y ago
    Can you elaborate? What did he do or say that made you think he could do the job even though it looks like he wasn't able to work with other people code?
supercanuck 7y ago
>It is, however, vital that the interviewer must be a expert in the field. This is key. There are a lot of hiring managers masquerading as experts and are frustrated when cargo culting hiring processes falter and lack the people skills to diagnose a situation. You'd also be amazed at the quality of resumes a high, advertised salary will bring.
- nvarsj 7y ago
  > You'd also be amazed at the quality of resumes a high, advertised salary will bring. This is so true. The best devs are making above market rate and are busy and content with their current role. By not including salary most of these people will simply ignore you, because of the time risk involved in finding the number. Non disclosure only works if your salary ranges are generally known (eg faang).
darkerside 7y ago
> I can say that I've never regretted a hire I said yes to Have you let new hires go in the first 90 days? That's just one of the ways personal regret is probably not the best metric here.
libria 7y ago
> nested for-loop problem > > No puzzles, no trivia-pursuit style questions. I swear HN technical interview threads are the poster child of talking past one another. First, for-loop is nowhere near a trivia-pursuit question. Second, different companies of different sizes/industries/goals have different requirements. Let's all move forward with this discussion and acknowledge that we can't all use the same process because we're not all hiring for the same type of job. If the engineers you hire consider for-loops a "puzzle" that's totally fine and OP using it doesn't invalidate your process for your multi-national or startup companies. > I can say that I've never regretted a hire I said yes to The real question is, has anyone else regretted that hire, which unfortunately can't be answered as they may not tell you. > To some of the younger generations, I've been told it sounds crazy. Doesn't sounds crazy at all. A single process guaranteed to work for everyone? Now that sounds crazy.
- ryandrake 7y ago
  Another question that has not be answered sufficiently: Would the guy you ended up not hiring actually have been a great hire? Everyone panics about / focuses on eliminating false positives and nobody studies or investigates the false negatives.
  - JabrZer0 7y ago
    I have no data to back this up, but my expectation is that this is mostly a result of two things: 1. It's often surprisingly difficult to fire an underperformer (anecdata: a friend of mine has lost multiple talented members of his team in the past few months - all the result of having to work with one completely unqualified person. For some reason, the other person has not been fired). As a result, a bad hire can have an outsized and lasting effect on a company. 2. Unless you're looking at very senior positions, there are almost always more people available to fill a role. You may miss 9 out of 10 people who would be effective in the role, but you only need to hire one person. The math changes a bit when you look at the mythical 10x developer, so maybe it would be worth looking into false negatives specifically in that case. Still, getting that 10x dev would be much more important in a more senior position.
warlog 7y ago
If you haven't hired any people that you regretted (ultimately), I wonder if you're being too conservative in your hiring? Sure you don't fail, but are you ever surprised that a marginal borderline outside the box case turned out to be 100x ?
mizzao 7y ago
This works for non-technical positions too. Generally it requires an experienced interviewer to listen to the candidate, think on their feet, be fully engaged, and basically do the opposite of the one-size-fits-all coding or behavioral interview. It takes a lot more effort on the part of the interviewer and is "harder to scale", in that you can't just train people to ask canned questions. But since it's open ended, it's a lot better at finding out what the candidate is really good at, and it's very useful to have one of these in every hiring loop, usually by a senior team member or exec.
KKKKkkkk1 7y ago
I'm an engineer and my contract is very explicit which parts of my work I'm allowed to speak about. The answer to all your questions will be "I can't speak about it." That's precisely why Google interviewers always ask abstract puzzle questions and avoid like fire any possibility of being exposed to protected IP.
- sbarre 7y ago
  There are definitely ways to talk about your work experience in enough detail without breaking NDAs.. I would be honest and say "I'm under NDA for a lot of that but I'll do my best". If neither of you are jerks, you should be able to manage it.
sh87 7y ago
This form of interviewing requires a certain degree of skill and lots of experience to keep the conversation objective and on track. I don't have that. I rely on a base technical question based on the candidate's past projects and then go on from there.
non-entity 7y ago
This is how much of my interviews have been and how I wish (however unlikely) my future ones will be. Unfortunately I rarely get to the interview stage of things as my resume is filtered out
closeparen 7y ago
>If the person described in this resume fits the background experience the role needs, you get an interview. This is one way the current status quo might be better than the past: you don't get pigeonholed so much by your past experience into being a "fit" only for similar roles. Sometimes the hiring manager is really looking for a specialist, but in general, we don't care what industry you were in or what tools you were using, as long as you can prove you're smart. Some of the most impressive people we have working on Go microservices were enterprise C# developers before.
Aperocky 7y ago
I think fizz-buzz is still an appropriate screen. While it maybe easy to hire dev who have been on the market for 10 years. You still have to keep in mind that new developers are still a very large proportion of the dev population.
sharadov 7y ago
I absolutely agree, as an interviewee that's what I focus on, and you're right you can catch it if someone is bullshitting.
kls 7y ago
Been doing it the same for over 20 as well, only had one bad hire and it had to do with drugs and attitude more than skill set. He was a good developer and was sober when I hired him but fell off the wagon and started missing work, no showing etc. I fully concur that if you can't spot a competent developer from a conversation, you probably should not be in the position of evaluating potential developers. I don't disagree that there are a lot of fake it till you make it developers who did a vo-tech class and are applying for jobs out of their league, but I just don't know how people don't spot them. It takes me about 5 phone calls to find a competent individual, and then I bring them in for a in person. As a hiring manager, I don't find it cumbersome to weed thru 5-10 people to find a good hire.

by jjav 7y ago

zerr 7y ago

I wonder if there is a list of companies doing interviews this way.

norcalli 7y ago
I use the same technique (and I'm 26 now, so relatively young) and it's how I've always interviewed others. Granted, I've only worked at smallish startups, but, either way, the company didn't care about my technique for evaluation, and just my final "yes", "no," or "maybe." So, I think it depends on the engineer. If someone can keep up in a technical conversation about their background with me and answer every question I have about a technical project they did, then basically they pass. It works especially well even if I'm not familiar with their project, because I have an opportunity to learn, so I can ask any question that comes to mind until they teach me what they learned. I did hire someone that I regretted, though, but to be fair, this was among my first interviews. The mistake I made was getting too easily caught talking about programming and technical things without specifically diving deep into his past project. He and I vibed quickly and I liked him, and that felt like enough, but after only a week it seemed obvious that he wasn't going to be producing much code, and we let him go. Otherwise, I've been happy and my ability to discern has only gotten better as I became more experienced. I got a little offtopic, but my main answer to your question was "if the company leaves the decision up to a majority of engineers saying 'yes', then a lot of companies do this." Google does this, the startups I've worked at do this, and some of my friends companies do this.
Jach 7y ago
Not exactly that, but you might like to peruse https://github.com/poteto/hiring-without-whiteboards https://github.com/poteto/hiring-without-whiteboards Reader beware, of course, I know at least one company on there shouldn't be.
- zerr 7y ago
  Oh, I see, they use the term "whiteboard" as a synonym for leetcode-like riddles.

lolptdr 7y ago

Thank you for your refreshing point of view. I'm a mid-level software developer and I was on the other side of the table as a junior web developer and encountered this same style of questioning and embraced it. This is my go-to style when interviewing because if you are confident in the lingo and zeitgeist of development, there is no way they can bullshit there way and lie through their teeth on their own experiences. It is very easy to tell. Whiteboarding doesn't give that detection since it is too broad of a spectrum to start as a indicator of experience.

rimliu 7y ago
Exactly. If you were really working with the stuff you do you will know all the common pain points, workarounds, etc. Unless the interviewer is alien to those things themselves there can be instant "one of us" recognition.

novok 7y ago

It’s also very subjective and hard to train for or to audit externally. When a company gets too big, you can’t properly vet hiring personally anymore, so you have to scale it. You don’t want ‘bozo cliques’ to form, so you make a semi-objective process like ‘solve this algorithmic question’ as part of the interview loop. I think execs and the founders doing a final review before hiring all engineers comes from that fear. Then other companies cargo cult interview processes from larger companies and the trend propagates. If you want to ‘hack hiring’ as a smaller company, you should use hard to scale processes like the one described in the parent post.

rimliu 7y ago
Well, if you get too big to get things done well, maybe not get too big?
- newjersey 7y ago
  > Well, if you get too big to get things done well, maybe not get too big? I love this idea but my old history professor (who I pretty much disagree with on everything except this) used to always say "follow the money". What are the incentives that all the parties have for and against growing companies bigger?

jakebasile 7y ago

These are the kinds of interviews I love, and I appreciate that they're still given at some places. I agree, it's nearly impossible to bullshit your way through this kind of a conversational interview but people still think they need to ask trivia questions.

goatinaboat 7y ago

This is just how interviewing was done in the 90s I agree with your approach and use it myself but one thing is different now and that’s the proliferation of tiny skills. Back then you would have a few big skills, you would claim to know one or two main languages, one or two databases and so on. Now people list hundreds - literally hundreds - of skills sometimes. And there’s no way to tell on reading if they really know it, or just saw it once and maybe did a tutorial or “hello world”. People now will add a skill to their CV if they’ve done it for a hour total in their entire lives! Or read a blog post about it. It is a massive time sink to pick through that.

jjav 7y ago
If we're talking about the same kind of thing, I don't consider those to be skills. For example I've seen resumes which list every javascript library they've ever used. Or every UNIX command they know how to run or similar minutia. This tells me the person doesn't know the difference between skills and implementation details, so I don't need to proceed to an interview.
- jishnum 7y ago
  I'd argue that this is a resume overindexed on getting past recruiting filters looking for specific JavaScript libraries or UNIX commands. Even the recruiters action may not be necessarily bad - startups with a decided tech stack might decide they are not able to provide the time for a new hire to ramp up. Effectively you penalise not catering the candidate resume to what you are looking for or deem important.
  - rhizome 7y ago
    Does anybody even know anything about these resume filters? They seem legendary, or I'd think there would be a best practice by now.
    - detaro 7y ago
      Various vendors of software in that space claim they are best practice, e.g. IBM: https://www.ibm.com/talent-management/hr-topic-hub/applicant-tracking-system https://www.ibm.com/talent-management/hr-topic-hub/applicant..., https://appsource.microsoft.com/en-us/product/web-apps/cem_business_solutions.applicant_tracking_system https://appsource.microsoft.com/en-us/product/web-apps/cem_b... promotes keyword matching as a feature, ...

virgilp 7y ago

> I can say that I've never regretted a hire I said yes to, so the method works to my satisfaction. This may just mean that you say a lot Of wrong “No”s. To get very high precision or very high recall is really easy... what you must measure is your F-score

norcalli 7y ago
The regret metric is different for a false "no" compared to a false "yes." I'd rather say "no" to someone who could've been great than "yes" to someone who wasn't, so I would say that it isn't that important.
- virgilp 7y ago
  Depends a lot on the company and situation (how easy is it to fire a bad hire? Does the company do it?) - but you can use something like F2 or F0.5 where relevant. Remember Facebook rejected Brian Acton, and paid billions for that. An oversimplification, I agree, but the larger point is that people tend to dismiss too easily the impact of bad “no hire” decisions, compared to the bad “hire” decisions. Just because you can’t or don’t measure it, doesn’t mean that the impact may not be arbitrarily large.
- ryandrake 7y ago
  This comment boils down precisely what I’ve always thought is the key problem in tech hiring. Companies overestimate the cost of a bad hire and underestimate the benefit of taking a risk and having it pay off. To borrow from poker: it’s commonly understood that if you’re not “caught bluffing” at least a little, it means you’re not bluffing enough. If your hiring process results in zero bad hires, you are playing it way too safe and I guarantee you are missing out on phenomenal candidates.
  - DavidWoof 7y ago
    I think you're wrong. I think companies are completely correct in assessing the cost of a bad hire to be much greater than the loss of a good hire, assuming you're getting enough good hires to fill the positions available. Now, this assumes that you're not missing out on great hires; in other words, it assumes that the good hires you miss are at the bottom of your hiring range. Your point might be that this can't be guaranteed, and while that may be true, it's unlikely that any tweaks to a given hiring process are going to bring them in either.

baddox 7y ago

My immediate reaction is that the problem with that approach is that it’s simply too expensive for the hiring company, in the same way that take-home programming challenges are too expensive for the applicants. A company trying to hire engineers can easily give a take-home programming challenge to a dozen engineer applicants and take very little time analyzing the submissions. That’s pretty unfair. But it also feels a bit untenable for a senior engineer at a hiring company to have very deep investigations of each applicant’s work history. Another problem is objectivity. If your company’s engineering hiring process relies heavily on a senior engineer’s subjective impression of an applicant, you’re going to have big problems with your own engineers’ biases, whether subconscious or not. Expect to hear a lot of evaluations like “well, the applicant did seem to have good knowledge and experience, but I just wasn’t impressed for some reason.”

EliRivers 7y ago
My immediate reaction is that the problem with that approach is that it’s simply too expensive for the hiring company Is it? The cost of hiring the wrong person can be huge. Not just agency fees if they came through a recruiter (those aren't cheap!), but also all the time people then spend on the bad employee and all the damage that person does before the mistake is rectified. If this system of reading the resumes and then spending a few hours of senior employee time on an interview can reliably find good employees, that's an absolute bargain.
- ozim 7y ago
  If it really would be, then current state of things would not go into "making it cheap". I think for entry level employee, or just a regular employee, cost of bad hire is not that high. If turnover on those positions is high, then it also makes things cheaper just to fill in the seat. I have seen not that brilliant employees that still were earning company money. Just you know "we hire only best of the best" is a scam. Hiring bad manager or a senior dev, can be bad I agree. So it is not so good to use the same hiring way for seniors and juniors, but unfortunately companies treat senior devs also like juniors.
- goatinaboat 7y ago

thedufer 7y ago

> I can say that I've never regretted a hire I said yes to, so the method works to my satisfaction. You think this is a claim about how good your hiring practice is, but the only way I can think to read this is as a point about how little hiring you do or how little evaluation of hires you do. In the real world, perfection isn't possible, so claims of it are a sign of inexperience or naivete.

marliechiller 7y ago
you're misconstruing perfection with satisfaction. entirely different things

wincent 7y ago

These questions should definitely be part of the interview process, but not all of it. I've done a lot of these kinds of interviews and I've definitely seen candidates that speak impressively but fail basic technical tests. If you don't actually verify the technical problem-solving ability of the candidate in some way you're forgoing signal that can massively increase the confidence you can have in your decision.

sieabahlpark 7y ago
Anecdotal but we've hired an engineer who was pretty decent in the interview but couldn't figure out how an if statement worked in a legacy codebase. Yes, I wrote that right. He struggled to understand conditionals in general when building his own logic. The guy even had a masters degree.
- bakuninsbart 7y ago
  So I had the same problem for a while, it was quite absurd, because I got through my uni courses, could decently code in Haskell and some other things, but never figured out the appropriate position to put an if clause. I then did a course on assembly programming and having to be extremely structured and using jump statements actually helped me a lot in easier to use programming languages. Point of this comment is that people might be good at a lot of things, while just having some weird brainfuse related to a very specific thing. That said, not using if statements makes programming rather difficult.
  - sieabahlpark 7y ago
    No see I wish they had any redeeming skill, he always asked an engineer to assist him with anything. They couldn't figure out anything on their own. It was shocking someone could complete the interview (small problem with a solution that is essentially explained, make x do y) and completely fail at building their own solutions without guidance
- dorfsmay 7y ago
  Can you elaborate? What did he do or say that made you think he could do the job even though it looks like he wasn't able to work with other people code?

supercanuck 7y ago

>It is, however, vital that the interviewer must be a expert in the field. This is key. There are a lot of hiring managers masquerading as experts and are frustrated when cargo culting hiring processes falter and lack the people skills to diagnose a situation. You'd also be amazed at the quality of resumes a high, advertised salary will bring.

nvarsj 7y ago
> You'd also be amazed at the quality of resumes a high, advertised salary will bring. This is so true. The best devs are making above market rate and are busy and content with their current role. By not including salary most of these people will simply ignore you, because of the time risk involved in finding the number. Non disclosure only works if your salary ranges are generally known (eg faang).

darkerside 7y ago

> I can say that I've never regretted a hire I said yes to Have you let new hires go in the first 90 days? That's just one of the ways personal regret is probably not the best metric here.

libria 7y ago

> nested for-loop problem > > No puzzles, no trivia-pursuit style questions. I swear HN technical interview threads are the poster child of talking past one another. First, for-loop is nowhere near a trivia-pursuit question. Second, different companies of different sizes/industries/goals have different requirements. Let's all move forward with this discussion and acknowledge that we can't all use the same process because we're not all hiring for the same type of job. If the engineers you hire consider for-loops a "puzzle" that's totally fine and OP using it doesn't invalidate your process for your multi-national or startup companies. > I can say that I've never regretted a hire I said yes to The real question is, has anyone else regretted that hire, which unfortunately can't be answered as they may not tell you. > To some of the younger generations, I've been told it sounds crazy. Doesn't sounds crazy at all. A single process guaranteed to work for everyone? Now that sounds crazy.

ryandrake 7y ago
Another question that has not be answered sufficiently: Would the guy you ended up not hiring actually have been a great hire? Everyone panics about / focuses on eliminating false positives and nobody studies or investigates the false negatives.
- JabrZer0 7y ago
  I have no data to back this up, but my expectation is that this is mostly a result of two things: 1. It's often surprisingly difficult to fire an underperformer (anecdata: a friend of mine has lost multiple talented members of his team in the past few months - all the result of having to work with one completely unqualified person. For some reason, the other person has not been fired). As a result, a bad hire can have an outsized and lasting effect on a company. 2. Unless you're looking at very senior positions, there are almost always more people available to fill a role. You may miss 9 out of 10 people who would be effective in the role, but you only need to hire one person. The math changes a bit when you look at the mythical 10x developer, so maybe it would be worth looking into false negatives specifically in that case. Still, getting that 10x dev would be much more important in a more senior position.

warlog 7y ago

If you haven't hired any people that you regretted (ultimately), I wonder if you're being too conservative in your hiring? Sure you don't fail, but are you ever surprised that a marginal borderline outside the box case turned out to be 100x ?

mizzao 7y ago

This works for non-technical positions too. Generally it requires an experienced interviewer to listen to the candidate, think on their feet, be fully engaged, and basically do the opposite of the one-size-fits-all coding or behavioral interview. It takes a lot more effort on the part of the interviewer and is "harder to scale", in that you can't just train people to ask canned questions. But since it's open ended, it's a lot better at finding out what the candidate is really good at, and it's very useful to have one of these in every hiring loop, usually by a senior team member or exec.

KKKKkkkk1 7y ago

I'm an engineer and my contract is very explicit which parts of my work I'm allowed to speak about. The answer to all your questions will be "I can't speak about it." That's precisely why Google interviewers always ask abstract puzzle questions and avoid like fire any possibility of being exposed to protected IP.

sbarre 7y ago
There are definitely ways to talk about your work experience in enough detail without breaking NDAs.. I would be honest and say "I'm under NDA for a lot of that but I'll do my best". If neither of you are jerks, you should be able to manage it.

sh87 7y ago

This form of interviewing requires a certain degree of skill and lots of experience to keep the conversation objective and on track. I don't have that. I rely on a base technical question based on the candidate's past projects and then go on from there.

non-entity 7y ago

This is how much of my interviews have been and how I wish (however unlikely) my future ones will be. Unfortunately I rarely get to the interview stage of things as my resume is filtered out

closeparen 7y ago

>If the person described in this resume fits the background experience the role needs, you get an interview. This is one way the current status quo might be better than the past: you don't get pigeonholed so much by your past experience into being a "fit" only for similar roles. Sometimes the hiring manager is really looking for a specialist, but in general, we don't care what industry you were in or what tools you were using, as long as you can prove you're smart. Some of the most impressive people we have working on Go microservices were enterprise C# developers before.

Aperocky 7y ago

I think fizz-buzz is still an appropriate screen. While it maybe easy to hire dev who have been on the market for 10 years. You still have to keep in mind that new developers are still a very large proportion of the dev population.

sharadov 7y ago

I absolutely agree, as an interviewee that's what I focus on, and you're right you can catch it if someone is bullshitting.

kls 7y ago

Been doing it the same for over 20 as well, only had one bad hire and it had to do with drugs and attitude more than skill set. He was a good developer and was sober when I hired him but fell off the wagon and started missing work, no showing etc. I fully concur that if you can't spot a competent developer from a conversation, you probably should not be in the position of evaluating potential developers. I don't disagree that there are a lot of fake it till you make it developers who did a vo-tech class and are applying for jobs out of their league, but I just don't know how people don't spot them. It takes me about 5 phone calls to find a competent individual, and then I bring them in for a in person. As a hiring manager, I don't find it cumbersome to weed thru 5-10 people to find a good hire.