11 ms·

I wish I could a 2-3 hour interview where I (or the candidate) showcase one of my projects and explain the architectural details and decisions in addition to sh

by swman 5y ago

I wish I could a 2-3 hour interview where I (or the candidate) showcase one of my projects and explain the architectural details and decisions in addition to showing any cool/hairy/insane code that got the job done. We can discuss those things and see how to improve them, or laugh at the crazy solutions. Honestly how many times do I need to rehearse these dumbass algos (blah blah blah, so I'll optimize for space with blah blah blah) okay already. I would much rather show you real world code that I've built, or passion projects I spend my free time on. I want to bring me to your company/projects, so get to know what I'm about holistically as an engineer. I think you can best understand that by looking at actual work done and judging whether or not the person is capable of contributing to your needs. Whenever we face challenges, we learn from them. At scale, we learn everyday. So just hire people who are passionate about facing challenges and learning from them. Not someone who can spend 8 hours a day like a college student playing leet code instead of building something useful. It really isn't that hard to memorize a dozen essential data structures and algorithms. But then what? So cringe.

Consultant32452 5y ago
This is almost exactly how I hold interviews, except they are usually < 1hr. I ask a person to tell me about a recent project and then keep asking more detailed questions about things until one of us hits our limit of understanding. No gotcha questions or random trivia. I only ask questions about something they claim to have done. Occasionally I'll ask a category question like, "Have you done any work with multi-threading?" And if they say yes, I ask about that project. I've found this technique to be extremely successful. It's possible I may have had some false negatives, but I've never had a false positive. Everyone I've recommended for hiring has been successful.
- onion2k 5y ago
  Everyone I've recommended for hiring has been successful. It's possible you're good at spotting good people, and rejecting bad people, but it's also possible that hiring is just easier than you think it is, and most people are capable of doing the jobs you hire for. You have no way to tell if you'd have the same result just hiring people by picking random resumes. Maybe negatives are just rare.
  - Consultant32452 5y ago
    It's unlikely that hiring is easier than I think it is, because I think it's pretty easy. The people who think it's hard are the HN consensus and the large corporations we keep reading about coming up with these convoluted interview standards/metrics.
- vineyardmike 5y ago
  > I've found this technique to be extremely successful. It's possible I may have had some false negatives, but I've never had a false positive. This is the impossible problem with hiring. Every interviewer wants to minimize false positives (they're expensive!), but every interviewee thinks they're a false negative.
  - Jensson 5y ago
    Which is funny since I bet most who thinks they are a "false negative" also would claim to have "impostor syndrome". Anyone with impostor syndrome would view themselves as a true negative.
    - vineyardmike 5y ago
      > I bet most who thinks they are a "false negative" also would claim to have "impostor syndrome" I don't think this could be true? If you think you don't belong/deserve the job (imposter)... why would you think you deserved the job (false negative).
- lordnacho 5y ago
  Same here. I've never had a dud in terms of ability when doing a technical chat interview. People who don't know how things work will hit a wall in this format, it's not actually that easy to BS what your thoughts on the CPP memory model are. The fear of BSers seems to be what holds people back from this approach though, and I can see that it wouldn't work for certain non technical fields.
- wiseowise 5y ago
  > I've found this technique to be extremely successful. That's just survivorship bias waiting to explode. Also, they're successful by some arbitrary metric that is applicable only to your company.
  - Consultant32452 5y ago
    It's entirely likely I will one day hit a false positive. I've been on the hiring team for every employer I've had for the last 15 years and have hired dozens of people.
jandrewrogers 5y ago
The challenge with this approach as that many very competent people are not allowed to discuss their prior work in that level of detail. More practical variants of this approach use a straw man software design problem to talk to that will exercise diverse areas of experience.
- swiftcoder 5y ago
  Yep, 100% this. Particularly if you've worked for big firms in the past, those NDAs do not mess around.
- twic 5y ago
  I do experience-based interviewing, and i have never encountered this problem. The great majority of the time, people are able to talk about anything. Sometimes, there are sensitive parts of prior work, but a candidate can just talk around those bits and focus on the rest. Even if someone had been working somewhere super-secret, if they aren't a junior, they have other experience to talk about. If all your career experience so far has been at the NSA, yeah, you might want to do a side project before looking for work.
  - nostrebored 5y ago
    I’ve worked at some large companies and would say this is wrong. I can’t talk about most of my best examples because they’re still roadmap items.
    - ctvo 5y ago
      You can’t remove the identifying details and talk about the technical challenge and usage in a generic sense? Your system or software is that specific? Can you give a now public example?
      - nostrebored 5y ago
        I can, and that’s usually what I do, but there are identifying details about the very specific domain which AWS only has a single product in. So I can talk about architecting a system, about customer feedback and redesigns, but I can’t talk about work I did that will span another three years. I think at FAANG it’s usually fine — most people have good enough examples even without their full repertoire. But at mid enterprise or F500 companies I could see this being a bit impactful.
weq 5y ago
100% give me a convo with a dev like this anyday of the week over this crammer whiteboarding l33tcode problems.
Hermitian909 5y ago
As an interviewee I'd like this too, but as an interviewer I wonder if it actually has enough signal. One of the problems I've found with these kinds of conversations is that people can plausibly BS quite a bit about projects, or their role in them. Maybe I started a new compiler or something at my company but didn't have the chops for it and the project flamed out. If I lie and said that all my goals were achieved and all the hard technical challenges were overcome, how can you tell? Or maybe the project did succeed but someone else came up with the idea and led the efforts. I was there for the technical discussions and grilled the lead on why he made the choices he did, so now I can answer your questions and sound like I know what I'm talking about. Software engineers can make a lot of money, the incentives to game the interview process are high and people attempt it often...
- Jensson 5y ago
  Yeah, any member of a team that isn't completely clueless will be able to convincingly claim that all of the achievements done by the team was achieved by the person alone.
- TrackerFF 5y ago
  There is a hysteria that's plaguing the world of tech: The fear that incompetent people might "BS" their way to a position. Everyone you talk with, has probably one or two anecdotal stories of such. "Yeah I worked with this CS grad that couldn't even write FizzBuzz" - yet we ignore the hundreds of other that do their work just fine. And this is fought with setting up ridiculous 8-part technical interviews where you'll have to whiteboard some leetcode questions ("Given a problem, show us a working O(Log N), or preferably O(1) solution. You have 45 minutes") or design questions ("Show us how you would design slack / discord / zoom / etc.") that drags over 6 months. For someone to be truly incompetent, or even not good enough to meet the company standards, the current system is overkill.
  - philwelch 5y ago
    The vast majority of people you actually work with are competent, sure. But the problem with interviewing is that it adversely selects for incompetent people, because competent people are more likely to have jobs and not be currently interviewing.
philbert101 5y ago
This is pretty pretty much what I tried to achieve here https://github.com/philbert/take-home-tech-test https://github.com/philbert/take-home-tech-test The point is to have a conversation about a project that the candidate understands well and is passionate about rather than asking them a bunch of questions that we already know the answers to. Before the interview we review the code base and try to understand what it’s doing by the documentation provided in the readme. During the interview we get the candidate to demo the project and any questions that came up in our code review we ask at the stage of execution in the project demo. The interview lasts for 2 hours and we’ve had several rounds of candidates put through this process. Both we as interviewers and the feedback from candidates has been very positive. The interview ends up being a day-to-day normal experience within the team and this really helps us to gauge the team fit. I think this helps to hire people that compliment and expand our skill set rather than hire people who are basically ourselves.
- yvrev 5y ago
  I feel like this is a pretty big ask to do for an interview, unless you happen to have it lying around already.
  - cutthegrass2 5y ago
    Yep, agree. 95% of the code I write is owned by my employer and is under NDA various other privacy / IP laws. The 5% that isn't, has no place in an interview. It's a bunch of brittle glue code automating and backing up data between my devices. "Passion projects" in my "spare time"... maybe once the kids have grown up and flown the nest... Leetcode is easy... I memorise a bunch of stuff, do the dance and pass the interview. If i'm lucky I get a problem i've not seen before and actually have to use my brain during the interview.
    - soneca 5y ago
      Isn’t the time spent memorizing leetcode similar to the time spent building a side-project? I took a look at leetcode when I was interviewing and decided it was a waste of time for me to learn that dance. I was happy with my chances with the companies that didn’t use it in their interviews. And it worked out fine.
jmchuster 5y ago
I don't think that style of interview provides as much signal as you think it does. I would probably say that watching someone work through a problem provides more signal than having someone explain a problem they have already solved. That's why I feel that all of the companies I've been at, eventually ended up shifting the interview process to do less "explain a project" and converging more on "talk us though these different types of problems". And then the past experience is what is being demonstrated when they show off how deeply and quickly they can think through the different types and bring their experience to bear. I also just generally do not think that most people can even put together a 2-3 hour presentation of their past work that goes over well. Most of the time people can't really talk more than 30 minutes about past projects. That requires a whole different set of skills, which there are certain contexts where I'd value that more highly. But my initial impression is that if we set up our interviews this way, we'd also end up filtering out a lot of people who'd be great, since not picking the perfect project to demo basically dooms the entire interview to be a flop. With multiple interview types, you increase the chance that there's an interview they really shine in.
bvm 5y ago
This is how I interview. Show me something you've done that you're proud of. Take me through it in depth. Answer some questions on it. Doesn't have to be a free-time project. If you don't have a free-time project and you're too NDA'd to discuss previous work, then present some language feature or something.
twic 5y ago
I often administer a 45 minute version of this (talking about any/all past work, not necessarily side projects), as part of a half-day of interviews. We'd never be able to get into the depth you could in two hours, but we can get somewhere. My experience has been that a lot of candidates can't even fill 45 minutes. I ask "what was the most interesting part?", "what was most technically complex?", "what would you do differently if you did it again?", and they just don't have nontrivial answers.
- vsareto 5y ago
  >and they just don't have nontrivial answers. Yeah, because you can have a career where you're just gluing stuff together to make business apps for, usually, simple business problems. You're looking for craftsmen but you're interviewing plumbers.
  - logfromblammo 5y ago
    To extend the plumber analogy, prospective employers will frequently look for plumbers with specific experience in copper pipe, rigid PVC pipe, or flexible PEX pipe, as though fragmenting the plumbing space in this fashion has any bearing on whether or not the result will conform to building codes, ensure that all the drains and faucets work as expected, and generally solve any fluids transport problems that may come up without having to push the calendar to the right. Most people look up the local business listings, pick anyone advertised as "plumber", and call to make a service appointment. Or they use a general contractor that already has a list of approved subs. Master plumbers don't have to answer little trick questions about brazing copper or about finding lead pipes in an old building. People somehow trust them to know what their job is, and do it. Rarely, one might encounter an unreliable plumber. They might not get paid, and any other plumber is usually able to fix their botched jobs without hurting the budget much. Review sites exist to track building-trades business reputations. But the analogy breaks, because no one trusts software and IT folks to do their jobs competently. The default assumption is that we are all know-nothing hacks who could destroy the company with one keystroke. All our knowledge is assumed to be tightly siloed, and does not transfer between similar technologies. C++ people can't do Rust or Go. Java people can't do C#. Desktop people can't do the cloud. Back-end people can't do UI. CMMI people can't be Agile. It's madness.
auggierose 5y ago
I don't like it, but I get it. You can train for the algos, so just do what needs to be done and train for it. Maybe you don't like to do what needs to be done? Well, that filter worked. Also, putting the emphasis on the interviewer understanding the candidates code instead of the other way around is never going to be popular ;-)
- zsmi 5y ago
  > Also, putting the emphasis on the interviewer understanding the candidates code instead of the other way around is never going to be popular It's also hard to scale it, make it objective, and keep the efficiency high (most developers prefer not spending their time on either side of the interview table) There is another advantage to the "algos". If you can learn algorithms then perhaps you can learn other things as well. Every new job I've had involved quite a lot of learning in a very short period of time. Learning whatever language, and whatever standard library is almost always trivial. They're usually not all that different, well documented, some with textbooks even. Learning to navigate and reason about the huge number of undocumented, often arbitrary, system architecture decisions, design decisions, code layout, etc. etc. that make up real code bases. That's hard. Really hard.
neverminder 5y ago
You can make it even more generic than that. A rather simple at first glance, but discussion provoking question: "What do you like and what do you dislike about the Technology X?". A good candidate who has experience with the said Technology X would not shut up on this subject. A bad one however will struggle. This is of course provided that you are hiring for some specific stack.
- commandlinefan 5y ago
  > experience with the said Technology X would not shut up on this subject I've learned the hard way to be very reserved when giving opinions about technology X because interviewers sometimes get really defensive about the thing they like about technology X.
- webdood90 5y ago
  The bias in this approach is obvious. In your mind, you think a candidate "not shutting up" is a green flag, but the reality is you are trying to hire someone who thinks like you. There are a million reasons why this approach doesn't work. Maybe they just don't like talking that much. Maybe they don't like the technology you're discussing. Maybe they just don't care enough to have an opinion on it. None of the above are good reasons to pass on a candidate.
  - neverminder 5y ago
    > but the reality is you are trying to hire someone who thinks like you. Not really. If someone can present solid reasoning and argue their point well, they don't have to think like me. Three's more than one way to skin a cat. > Maybe they don't like the technology you're discussing. Maybe they just don't care enough to have an opinion on it. You mean the technology they are being hired for? Yeah, hating, not caring about it is probably not a good motivator to go for the job then, wouldn't you agree? > None of the above are good reasons to pass on a candidate. Beats the whiteboarding. I was hired like that in my last 3 jobs and I have used the same approach myself with rather consistently good results.
    - 5y ago
david38 5y ago
You can sometimes. This is literally one of the interview questions I ask - tell me about a complex project.

by swman 5y ago

Consultant32452 5y ago

This is almost exactly how I hold interviews, except they are usually < 1hr. I ask a person to tell me about a recent project and then keep asking more detailed questions about things until one of us hits our limit of understanding. No gotcha questions or random trivia. I only ask questions about something they claim to have done. Occasionally I'll ask a category question like, "Have you done any work with multi-threading?" And if they say yes, I ask about that project. I've found this technique to be extremely successful. It's possible I may have had some false negatives, but I've never had a false positive. Everyone I've recommended for hiring has been successful.

onion2k 5y ago
Everyone I've recommended for hiring has been successful. It's possible you're good at spotting good people, and rejecting bad people, but it's also possible that hiring is just easier than you think it is, and most people are capable of doing the jobs you hire for. You have no way to tell if you'd have the same result just hiring people by picking random resumes. Maybe negatives are just rare.
- Consultant32452 5y ago
  It's unlikely that hiring is easier than I think it is, because I think it's pretty easy. The people who think it's hard are the HN consensus and the large corporations we keep reading about coming up with these convoluted interview standards/metrics.
vineyardmike 5y ago
> I've found this technique to be extremely successful. It's possible I may have had some false negatives, but I've never had a false positive. This is the impossible problem with hiring. Every interviewer wants to minimize false positives (they're expensive!), but every interviewee thinks they're a false negative.
- Jensson 5y ago
  Which is funny since I bet most who thinks they are a "false negative" also would claim to have "impostor syndrome". Anyone with impostor syndrome would view themselves as a true negative.
  - vineyardmike 5y ago
    > I bet most who thinks they are a "false negative" also would claim to have "impostor syndrome" I don't think this could be true? If you think you don't belong/deserve the job (imposter)... why would you think you deserved the job (false negative).
lordnacho 5y ago
Same here. I've never had a dud in terms of ability when doing a technical chat interview. People who don't know how things work will hit a wall in this format, it's not actually that easy to BS what your thoughts on the CPP memory model are. The fear of BSers seems to be what holds people back from this approach though, and I can see that it wouldn't work for certain non technical fields.
wiseowise 5y ago
> I've found this technique to be extremely successful. That's just survivorship bias waiting to explode. Also, they're successful by some arbitrary metric that is applicable only to your company.
- Consultant32452 5y ago
  It's entirely likely I will one day hit a false positive. I've been on the hiring team for every employer I've had for the last 15 years and have hired dozens of people.

jandrewrogers 5y ago

The challenge with this approach as that many very competent people are not allowed to discuss their prior work in that level of detail. More practical variants of this approach use a straw man software design problem to talk to that will exercise diverse areas of experience.

swiftcoder 5y ago
Yep, 100% this. Particularly if you've worked for big firms in the past, those NDAs do not mess around.
twic 5y ago
I do experience-based interviewing, and i have never encountered this problem. The great majority of the time, people are able to talk about anything. Sometimes, there are sensitive parts of prior work, but a candidate can just talk around those bits and focus on the rest. Even if someone had been working somewhere super-secret, if they aren't a junior, they have other experience to talk about. If all your career experience so far has been at the NSA, yeah, you might want to do a side project before looking for work.
- nostrebored 5y ago
  I’ve worked at some large companies and would say this is wrong. I can’t talk about most of my best examples because they’re still roadmap items.
  - ctvo 5y ago
    You can’t remove the identifying details and talk about the technical challenge and usage in a generic sense? Your system or software is that specific? Can you give a now public example?
    - nostrebored 5y ago
      I can, and that’s usually what I do, but there are identifying details about the very specific domain which AWS only has a single product in. So I can talk about architecting a system, about customer feedback and redesigns, but I can’t talk about work I did that will span another three years. I think at FAANG it’s usually fine — most people have good enough examples even without their full repertoire. But at mid enterprise or F500 companies I could see this being a bit impactful.

weq 5y ago

100% give me a convo with a dev like this anyday of the week over this crammer whiteboarding l33tcode problems.

Hermitian909 5y ago

As an interviewee I'd like this too, but as an interviewer I wonder if it actually has enough signal. One of the problems I've found with these kinds of conversations is that people can plausibly BS quite a bit about projects, or their role in them. Maybe I started a new compiler or something at my company but didn't have the chops for it and the project flamed out. If I lie and said that all my goals were achieved and all the hard technical challenges were overcome, how can you tell? Or maybe the project did succeed but someone else came up with the idea and led the efforts. I was there for the technical discussions and grilled the lead on why he made the choices he did, so now I can answer your questions and sound like I know what I'm talking about. Software engineers can make a lot of money, the incentives to game the interview process are high and people attempt it often...

Jensson 5y ago
Yeah, any member of a team that isn't completely clueless will be able to convincingly claim that all of the achievements done by the team was achieved by the person alone.
TrackerFF 5y ago
There is a hysteria that's plaguing the world of tech: The fear that incompetent people might "BS" their way to a position. Everyone you talk with, has probably one or two anecdotal stories of such. "Yeah I worked with this CS grad that couldn't even write FizzBuzz" - yet we ignore the hundreds of other that do their work just fine. And this is fought with setting up ridiculous 8-part technical interviews where you'll have to whiteboard some leetcode questions ("Given a problem, show us a working O(Log N), or preferably O(1) solution. You have 45 minutes") or design questions ("Show us how you would design slack / discord / zoom / etc.") that drags over 6 months. For someone to be truly incompetent, or even not good enough to meet the company standards, the current system is overkill.
- philwelch 5y ago
  The vast majority of people you actually work with are competent, sure. But the problem with interviewing is that it adversely selects for incompetent people, because competent people are more likely to have jobs and not be currently interviewing.

philbert101 5y ago

This is pretty pretty much what I tried to achieve here https://github.com/philbert/take-home-tech-test https://github.com/philbert/take-home-tech-test The point is to have a conversation about a project that the candidate understands well and is passionate about rather than asking them a bunch of questions that we already know the answers to. Before the interview we review the code base and try to understand what it’s doing by the documentation provided in the readme. During the interview we get the candidate to demo the project and any questions that came up in our code review we ask at the stage of execution in the project demo. The interview lasts for 2 hours and we’ve had several rounds of candidates put through this process. Both we as interviewers and the feedback from candidates has been very positive. The interview ends up being a day-to-day normal experience within the team and this really helps us to gauge the team fit. I think this helps to hire people that compliment and expand our skill set rather than hire people who are basically ourselves.

yvrev 5y ago
I feel like this is a pretty big ask to do for an interview, unless you happen to have it lying around already.
- cutthegrass2 5y ago
  Yep, agree. 95% of the code I write is owned by my employer and is under NDA various other privacy / IP laws. The 5% that isn't, has no place in an interview. It's a bunch of brittle glue code automating and backing up data between my devices. "Passion projects" in my "spare time"... maybe once the kids have grown up and flown the nest... Leetcode is easy... I memorise a bunch of stuff, do the dance and pass the interview. If i'm lucky I get a problem i've not seen before and actually have to use my brain during the interview.
  - soneca 5y ago
    Isn’t the time spent memorizing leetcode similar to the time spent building a side-project? I took a look at leetcode when I was interviewing and decided it was a waste of time for me to learn that dance. I was happy with my chances with the companies that didn’t use it in their interviews. And it worked out fine.

jmchuster 5y ago

I don't think that style of interview provides as much signal as you think it does. I would probably say that watching someone work through a problem provides more signal than having someone explain a problem they have already solved. That's why I feel that all of the companies I've been at, eventually ended up shifting the interview process to do less "explain a project" and converging more on "talk us though these different types of problems". And then the past experience is what is being demonstrated when they show off how deeply and quickly they can think through the different types and bring their experience to bear. I also just generally do not think that most people can even put together a 2-3 hour presentation of their past work that goes over well. Most of the time people can't really talk more than 30 minutes about past projects. That requires a whole different set of skills, which there are certain contexts where I'd value that more highly. But my initial impression is that if we set up our interviews this way, we'd also end up filtering out a lot of people who'd be great, since not picking the perfect project to demo basically dooms the entire interview to be a flop. With multiple interview types, you increase the chance that there's an interview they really shine in.

bvm 5y ago

This is how I interview. Show me something you've done that you're proud of. Take me through it in depth. Answer some questions on it. Doesn't have to be a free-time project. If you don't have a free-time project and you're too NDA'd to discuss previous work, then present some language feature or something.

twic 5y ago

I often administer a 45 minute version of this (talking about any/all past work, not necessarily side projects), as part of a half-day of interviews. We'd never be able to get into the depth you could in two hours, but we can get somewhere. My experience has been that a lot of candidates can't even fill 45 minutes. I ask "what was the most interesting part?", "what was most technically complex?", "what would you do differently if you did it again?", and they just don't have nontrivial answers.

vsareto 5y ago
>and they just don't have nontrivial answers. Yeah, because you can have a career where you're just gluing stuff together to make business apps for, usually, simple business problems. You're looking for craftsmen but you're interviewing plumbers.
- logfromblammo 5y ago
  To extend the plumber analogy, prospective employers will frequently look for plumbers with specific experience in copper pipe, rigid PVC pipe, or flexible PEX pipe, as though fragmenting the plumbing space in this fashion has any bearing on whether or not the result will conform to building codes, ensure that all the drains and faucets work as expected, and generally solve any fluids transport problems that may come up without having to push the calendar to the right. Most people look up the local business listings, pick anyone advertised as "plumber", and call to make a service appointment. Or they use a general contractor that already has a list of approved subs. Master plumbers don't have to answer little trick questions about brazing copper or about finding lead pipes in an old building. People somehow trust them to know what their job is, and do it. Rarely, one might encounter an unreliable plumber. They might not get paid, and any other plumber is usually able to fix their botched jobs without hurting the budget much. Review sites exist to track building-trades business reputations. But the analogy breaks, because no one trusts software and IT folks to do their jobs competently. The default assumption is that we are all know-nothing hacks who could destroy the company with one keystroke. All our knowledge is assumed to be tightly siloed, and does not transfer between similar technologies. C++ people can't do Rust or Go. Java people can't do C#. Desktop people can't do the cloud. Back-end people can't do UI. CMMI people can't be Agile. It's madness.

auggierose 5y ago

I don't like it, but I get it. You can train for the algos, so just do what needs to be done and train for it. Maybe you don't like to do what needs to be done? Well, that filter worked. Also, putting the emphasis on the interviewer understanding the candidates code instead of the other way around is never going to be popular ;-)

zsmi 5y ago
> Also, putting the emphasis on the interviewer understanding the candidates code instead of the other way around is never going to be popular It's also hard to scale it, make it objective, and keep the efficiency high (most developers prefer not spending their time on either side of the interview table) There is another advantage to the "algos". If you can learn algorithms then perhaps you can learn other things as well. Every new job I've had involved quite a lot of learning in a very short period of time. Learning whatever language, and whatever standard library is almost always trivial. They're usually not all that different, well documented, some with textbooks even. Learning to navigate and reason about the huge number of undocumented, often arbitrary, system architecture decisions, design decisions, code layout, etc. etc. that make up real code bases. That's hard. Really hard.

neverminder 5y ago

You can make it even more generic than that. A rather simple at first glance, but discussion provoking question: "What do you like and what do you dislike about the Technology X?". A good candidate who has experience with the said Technology X would not shut up on this subject. A bad one however will struggle. This is of course provided that you are hiring for some specific stack.

commandlinefan 5y ago
> experience with the said Technology X would not shut up on this subject I've learned the hard way to be very reserved when giving opinions about technology X because interviewers sometimes get really defensive about the thing they like about technology X.
webdood90 5y ago
The bias in this approach is obvious. In your mind, you think a candidate "not shutting up" is a green flag, but the reality is you are trying to hire someone who thinks like you. There are a million reasons why this approach doesn't work. Maybe they just don't like talking that much. Maybe they don't like the technology you're discussing. Maybe they just don't care enough to have an opinion on it. None of the above are good reasons to pass on a candidate.
- neverminder 5y ago
  > but the reality is you are trying to hire someone who thinks like you. Not really. If someone can present solid reasoning and argue their point well, they don't have to think like me. Three's more than one way to skin a cat. > Maybe they don't like the technology you're discussing. Maybe they just don't care enough to have an opinion on it. You mean the technology they are being hired for? Yeah, hating, not caring about it is probably not a good motivator to go for the job then, wouldn't you agree? > None of the above are good reasons to pass on a candidate. Beats the whiteboarding. I was hired like that in my last 3 jobs and I have used the same approach myself with rather consistently good results.
  - 5y ago

david38 5y ago

You can sometimes. This is literally one of the interview questions I ask - tell me about a complex project.