8 ms·

What kills me is the fact that the interviews (especially the technical ones) go in depth into topics that aren’t ever pertinent to the job. It’s simply so the

What kills me is the fact that the interviews (especially the technical ones) go in depth into topics that aren’t ever pertinent to the job. It’s simply so the interviewer can rank you vs themselves. You need to be good but not too good you’re a threat. The best interviews I’ve ever taken and in turn, host, are the ones where we break down a problem with low code, no gotchas, little examples of specifics just to make sure they know how to write it in language of their choice. That they understand the problem, can satisfactorily break it down into actionable tasks, and come up with a solution to the problem. Everything else: tech stack, jira, agile, culture - is company specific and should be taught to your employees and not be made the bar. If you need someone who can hit the ground running you can focus on a tech stack but ultimately it’s up to you, the company, to ensure they fit. Not the new hire.

rewmie 3y ago
> What kills me is the fact that the interviews (especially the technical ones) go in depth into topics that aren’t ever pertinent to the job. It’s simply so the interviewer can rank you vs themselves. You need to be good but not too good you’re a threat. Story time. A few years back I was in hiring loops as an interviewer. Half a dozen engineers in my company interviewed a candidate during a morning. Everyone had their notes and we were discussing if we should hire the guy or not. Everyone gave thumbs up except one engineer. It turned out he tested the candidate on data structures and algorithms, and the candidate hadn't memorized the computational complexity of some bullshit algorithm that only shows up in lame trivia games no one cares about. Based in that, that particular interviewer gave thumbs down. We discussed everything, went through all notes, and ultimately based on all feedback the hiring leader gave a thumbs up. The data structures engineer threw a tantrum. In his opinion, we would be lowering the hiring bar if we hired a candidate that failed to meet his bar on what he felt were basic competences. The hiring leader asked how many times he used that algorithm in his everyday work. The data structures engineer answered that alas he never used it at all, but still he felt that everyone working in his org should know that. I feel some companies don't have good hiring managers and give free reign to bad engineers who have no idea what it takes to deliver production code.
- roland35 3y ago
  That is a major problem in interviewing. Everyone has their own set of internal guidelines! I have worked on teams trying to improve our interviewing process, and one key goal was aligning everyone in exactly what technical and personal attributes we were trying to hire for.
  - rewmie 3y ago
    In my anecdote, we already had very explicit and rigorous guidelines. We had goals, evaluation requirements, question banks, and more importantly post-interview meetings where all interviewers matched notes and we're tasked with gathering data on topics that overlapped the responsibilities of other interviewers. Even so, the data structure engineer cracked open Trivial Pursuit on the candidates and wanted to reject him based on one answer alone.
    - roland35 3y ago
      Yup, some people just seem to have a hard time with evaluating candidates fairly rather than by some arbitrary guidelines inside their head. Of course if you're looking for a software jeopardy contestant maybe memory recall is important, but for the rest of us it is much better to have a good understanding of fundamentals and know where to look when it comes to specifics!
- mhss 3y ago
  That’s why you need experienced hiring managers. The questions should be discussed and approved before the interview. You just don’t let an engineer ask whatever they want. An interview plan needs to be shared to avoid overlapping questions or topics between interviews. In this particular example the hiring leader did the right thing, only after doing the wrong thing: not review or having an interview plan discussed beforehand and training the interviewers. The interviewing principles need to be clear to all your interviewers.
  - rewmie 3y ago
    > You just don’t let an engineer ask whatever they want. In my anecdote, the data structure engineer was indeed tasked with evaluating the candidate on his data structures knowledge. Except that the candidate had guidelines that went in the line of assessing basic understanding and proficiency in following an algorithm, but instead opted to make it a game of Trivial Pursuit.
roenxi 3y ago
> You need to be good but not too good you’re a threat. For what it is worth; based on what I've seen in interviews. Programmers can only rank people who are close to their own level. If someone like Terry Davis of TempleOS fame shows up for an interview, should the interview declare them as a madman? a genius? both? If we need to build an OS, are his design choice eccentricities sly moves of genius or evidence of a diseased mind? It isn't as much that strong programmers are a threat (that might be a factor) but more that big gaps in though lead to both productivity and inscrutability. And people avoid things they don't understand.
- mhss 3y ago
  That’s why assembling an interview panel requires some finesse. How senior the candidate is expected to be needs to be calibrated and interviewers selected accordingly to seniority and domain expertise. Not always possible, so it’s always imperfect. Assessing performance is really hard, even more so with limited interview time that requires determining not only hire or no hire, but also level and compensation.
- golergka 3y ago
  I would hire him in a heartbeat if, and only if, the team I would be hiring him for would be a team of one.
Roark66 3y ago
Personally I really dislike very specific questions you can Google an answer to in 3s and consequently no one remembers it while doing an actual job. IMO when it comes to verification of actual technical ability the candidate should be told an example of an actual task she/he would be expected to complete routinely and they should either do it during the interview or explain how would they go about doing it.
- mhss 3y ago
  I get what you mean I think. However if you’ve been doing C dev for several years and you “don’t remember” what a static variable is and when to use it (or not) is not a great sign. Cumulative signals is what determines hire or no hire, not a single “wrong answer”. Even when a candidate doesn’t know an answer you can get useful signals. If you give them the answer or hints and see how they react or a follow up question after giving them the answer. You can google many things easily. Understanding the answer and knowing how to apply it to different problems matters a lot more. I still expect some concepts and definitions to be remembered if you’re claiming expertise in a topic.
  - badtension 3y ago
    Static variable sure but there are many other examples, like returning a C fixed-size array from a function. I had this question asked and they specifically insisted on being compliant with the standards and not using an out-argument. This is a ridiculous question.
    - _a_a_a_ 3y ago
      > they specifically insisted on being compliant with the standards that's wrong?
      - badtension 3y ago
        No, but this is a very niche thing to know and if I remember correctly gcc has a widely used specific extension for that which would not be accepted in that case.
mhss 3y ago
I’m not going to justify going in depth in topics not relevant for the job. However going deep in tech topics is necessary to evaluate experience and seniority. The “best interviews” process you described is adequate for the first eng levels but if you want to interview for senior, staff, principal; etc it gets harder and going into depth and breadth is necessary. Heck. Sometimes going into topics “not relevant” for the job is revealing. If their cv says they spent 5yrs writing Linux dev drivers but the position is to write golang web services I may still ask about device drivers if I can get a domain expert. Good people tend to understand very well the things they’ve worked on.
- jagged-chisel 3y ago
  ‘going into topics “not relevant” for the job is revealing‘ I would suggest anything on the applicant’s cv is fair game. What makes no sense is asking about removing duplicates from a linked list when that’s nowhere near what the job will entail.
  - jonathankoren 3y ago
    It’s literally an intro test question that you can figure out if you know what a linked list is. It’s not that big of a deal. Now trying to remember a specific algorithm like red-black tree rotation or Djikstra’s is something completely different
softfalcon 3y ago
Yeah, I try and background check my interviewer thoroughly because of the “threat” issue. I always ask who will be interviewing me and look them up. I specifically try and answer their questions and “hold back” a bit when answering if I can. I also sometimes will drop a nugget of knowing more and study their reaction. Some interviewers react quite poorly if you hint you know considerably more about a subject than they might want you to know. I have friends with a lot more education than myself (PhD, masters, very senior) and they say they have to do this A LOT. The goal is to see how the interviewer handles not being the smartest in the room about everything. This is a big deal because it can suss out whether the other person is “on good behaviour for the interview” but otherwise has an enormous ego during regular work hours. No one wants to work for an ego maniac vetting out all the A+ candidates out of fear of competition.
- angarg12 3y ago
  I never heard about having to do this during an interview, but it sounds concerning. My advice would be to not play mind games and just interview as yourself. Interviews go both ways, so if your interviewer is a psychopath you'd want to know sooner. Then just give the job a pass.
  - dallasg3 3y ago
    Psychopaths can be the best chameleons though.
  - lowdest 3y ago
    True in aggregate, but special conditions exist. E.g. when interviewing for a rarely available position with extraordinary compensation.
- redditor98654 3y ago
  I have done 300+ interviews in a 13 year career in FAANG companies and anytime I get a sense a candidate knows more than me, I get all excited and will work extra hard in the debriefs to get the person hired. If the spot is for my own team, even better ans will nudge my manager to hire the candidate. The prospects of learning from the person on the job is too enticing.
sokoloff 3y ago
> You need to be good but not too good you’re a threat. I will happily hire someone who’s a threat to take my job. If I don’t, I can’t ever move up either.
- softfalcon 3y ago
  This is the right way to take it, but unfortunately many don’t see it this way.
scarface_74 3y ago
With most employees not staying at a job for more than two years, why wouldn’t you hire someone who can hit the ground running? If they spend six months doing negative work ramping up and leave in two years, your investment in them didn’t go far. Yes, I know the answer is to keep them at market wages and don’t fall into the salary compression trap. But often that isn’t under your control as a hiring manager. HR won’t give you a budget for raises. But will give you the budget to hire at market rates.
- solarmist 3y ago
  Because, as mentioned, it’s a fantasy that someone can step in and understand the peculiarities of a new company(’s technology) without ramp up time. Edit: specified its specifically about the tech. The business side is a whole other thing.
  - scarface_74 3y ago
    There are two things to ramp up on - the technology and the business. If they know the technology that’s one less thing to worry about.
    - solarmist 3y ago
      And you can know 100% of the technologies they use; open the repo and still say, “what the hell were they thinking using X like Y!” “Why didn’t they use Y here” “Oh man, this looks like monkey patched code from 2 full versions ago, the right way to handle this now would be 1/3 the code, but oh they can’t update it because they’re mutating the data structure in order to Z… Fuck…” Edit: Eventually, you'll come to an understanding of why it's that way, but it takes time and often experimentation.
      - scarface_74 3y ago
        Everyone thinks what came before then was done stupidly. With maturity, you realize whatever they did worked well enough to get the company to a position where they were able to hire you. As Corey Quinn (a well known “cloud economist”) says, “legacy software is software that generates revenue”.
jagged-chisel 3y ago
Allow me to add. “If you need someone who can hit the ground running…” then you need to have documented the crazy decisions that led to the awkward implementation that is your product. I have yet to meet a company who is using standard, recommended, tried-n-tested, well-known solutions to typical problems. Unless you write docs or stick to standards, no outsider has the context to “hit the ground running.”
- SonOfLilit 3y ago
  Some people can still hit the ground running when there is a complex codebase with zero docs. They are just very expensive.
  - QuercusMax 3y ago
    Last three times I've joined a new team (2004, 2015, 2017) I spent my first week trying to fix tiny bugs and generally just reading my way through the codebase till I understood what was going on. I highly recommend it. I learned to do this when I was working on my master's, and my advisor suggested a project to me, and when I asked him for help figuring out where to start, and he told me to read through the code until I understood it, and come to him if I spent more than an hour or two stuck on things. Thanks, Mikhail - your advice was fantastic.
    - not_alexb 3y ago
      That only works if the code was written in a semi-digestible format; I've met my fair share of monstrosities that were propped up by race conditions -- you're not going to briskly digest them in a week (especially if you're in the unlucky circumstance of only having a single breakpoint per run and the engineers who had any understanding of it haven't worked there in 20 years).
      - SnorkelTan 3y ago
        Test cases can be a good place to start because they are usually clustered around business critical functionality. Or problematic legacy code that needs to work :)
ch4s3 3y ago
This definitely rings true to me. We give an interview that’s basically a simple parser, and ask candidates to do it recursively(in Elixir) using function head instead of Enumerable. We link to the relevant docs and it’s a paired exercise with tests built in. It’s generally been a good predictor of candidates ability to work in our code base and collaborate. The whole thing can be done in 50loc and is not meant to be terribly hard.
angarg12 3y ago
I've conducted hundreds of interviews and I agree about the tech stack, but disagree about culture. Tech is usually easy to pick up, and highly company specific. Any good engineer should be able to learn new tech, and things will change over time. Culture is much harder to "teach". For me testing for culture fit has become much more important than tech acumen, particularly at more senior levels. You need to have a sense of at least whether the candidate aligns with the company culture, and is willing to fit. Not doing this risks several scenarios: a) The candidate takes a while, but finally fits with the culture. This is suboptimal but ultimately a good outcome. b) Candidate refuses to fit with the culture. This will likely cause performance issues, and the employee will ultimately leave or get fired. Not a good outcome. c) Candidate actively subverts the company culture. This is the most destructive outcome and can be quite damaging, particularly at higher levels. Checking that someone will be a good fit for the company is better for both the company and the candidate.
- _a_a_a_ 3y ago
  It depends what company culture actually is. I have worked at companies where documentation has been frowned upon – I'm not exaggerating either. That is something I most definitely will try and subvert.
- spacemadness 3y ago
  I recently interviewed a candidate that seemed solid technically but kept calling me bro. I’m pretty laid back but that was a fail. Note to everyone here: don’t do that.
  - the_gipsy 3y ago
    Chillax, bro.
  - goostavos 3y ago
    Bruh. Counter note: I've done 100s of interviews. A bro, bruh, or brah wouldn't even register as something notable to me. This is just how my younger coworkers talk. Their use of "bet" has taken some getting used to.
hardlianotion 3y ago
Yeah - my last interview was a bit like that. Uninteresting, lazy factorial question, some syntax bits on Python, can you list some canonical definition of object orientation, no probing at all on any topic of interest, and then a brief trivial squabble on what a list comprehension is.
twelve40 3y ago
> so the interviewer can rank you vs themselves. You need to be good but not too good you’re a threat Maybe only about 10% of people who are sadists or calculating assholes actually follow that motivation? Unless you had a very special sample pool. Most interviewers i've met - both good and bad - were just trying to do what they think is right, with varying degrees of competence.

rewmie 3y ago

> What kills me is the fact that the interviews (especially the technical ones) go in depth into topics that aren’t ever pertinent to the job. It’s simply so the interviewer can rank you vs themselves. You need to be good but not too good you’re a threat. Story time. A few years back I was in hiring loops as an interviewer. Half a dozen engineers in my company interviewed a candidate during a morning. Everyone had their notes and we were discussing if we should hire the guy or not. Everyone gave thumbs up except one engineer. It turned out he tested the candidate on data structures and algorithms, and the candidate hadn't memorized the computational complexity of some bullshit algorithm that only shows up in lame trivia games no one cares about. Based in that, that particular interviewer gave thumbs down. We discussed everything, went through all notes, and ultimately based on all feedback the hiring leader gave a thumbs up. The data structures engineer threw a tantrum. In his opinion, we would be lowering the hiring bar if we hired a candidate that failed to meet his bar on what he felt were basic competences. The hiring leader asked how many times he used that algorithm in his everyday work. The data structures engineer answered that alas he never used it at all, but still he felt that everyone working in his org should know that. I feel some companies don't have good hiring managers and give free reign to bad engineers who have no idea what it takes to deliver production code.

roland35 3y ago
That is a major problem in interviewing. Everyone has their own set of internal guidelines! I have worked on teams trying to improve our interviewing process, and one key goal was aligning everyone in exactly what technical and personal attributes we were trying to hire for.
- rewmie 3y ago
  In my anecdote, we already had very explicit and rigorous guidelines. We had goals, evaluation requirements, question banks, and more importantly post-interview meetings where all interviewers matched notes and we're tasked with gathering data on topics that overlapped the responsibilities of other interviewers. Even so, the data structure engineer cracked open Trivial Pursuit on the candidates and wanted to reject him based on one answer alone.
  - roland35 3y ago
    Yup, some people just seem to have a hard time with evaluating candidates fairly rather than by some arbitrary guidelines inside their head. Of course if you're looking for a software jeopardy contestant maybe memory recall is important, but for the rest of us it is much better to have a good understanding of fundamentals and know where to look when it comes to specifics!
mhss 3y ago
That’s why you need experienced hiring managers. The questions should be discussed and approved before the interview. You just don’t let an engineer ask whatever they want. An interview plan needs to be shared to avoid overlapping questions or topics between interviews. In this particular example the hiring leader did the right thing, only after doing the wrong thing: not review or having an interview plan discussed beforehand and training the interviewers. The interviewing principles need to be clear to all your interviewers.
- rewmie 3y ago
  > You just don’t let an engineer ask whatever they want. In my anecdote, the data structure engineer was indeed tasked with evaluating the candidate on his data structures knowledge. Except that the candidate had guidelines that went in the line of assessing basic understanding and proficiency in following an algorithm, but instead opted to make it a game of Trivial Pursuit.

roenxi 3y ago

> You need to be good but not too good you’re a threat. For what it is worth; based on what I've seen in interviews. Programmers can only rank people who are close to their own level. If someone like Terry Davis of TempleOS fame shows up for an interview, should the interview declare them as a madman? a genius? both? If we need to build an OS, are his design choice eccentricities sly moves of genius or evidence of a diseased mind? It isn't as much that strong programmers are a threat (that might be a factor) but more that big gaps in though lead to both productivity and inscrutability. And people avoid things they don't understand.

mhss 3y ago
That’s why assembling an interview panel requires some finesse. How senior the candidate is expected to be needs to be calibrated and interviewers selected accordingly to seniority and domain expertise. Not always possible, so it’s always imperfect. Assessing performance is really hard, even more so with limited interview time that requires determining not only hire or no hire, but also level and compensation.
golergka 3y ago
I would hire him in a heartbeat if, and only if, the team I would be hiring him for would be a team of one.

Roark66 3y ago

Personally I really dislike very specific questions you can Google an answer to in 3s and consequently no one remembers it while doing an actual job. IMO when it comes to verification of actual technical ability the candidate should be told an example of an actual task she/he would be expected to complete routinely and they should either do it during the interview or explain how would they go about doing it.

mhss 3y ago
I get what you mean I think. However if you’ve been doing C dev for several years and you “don’t remember” what a static variable is and when to use it (or not) is not a great sign. Cumulative signals is what determines hire or no hire, not a single “wrong answer”. Even when a candidate doesn’t know an answer you can get useful signals. If you give them the answer or hints and see how they react or a follow up question after giving them the answer. You can google many things easily. Understanding the answer and knowing how to apply it to different problems matters a lot more. I still expect some concepts and definitions to be remembered if you’re claiming expertise in a topic.
- badtension 3y ago
  Static variable sure but there are many other examples, like returning a C fixed-size array from a function. I had this question asked and they specifically insisted on being compliant with the standards and not using an out-argument. This is a ridiculous question.
  - _a_a_a_ 3y ago
    > they specifically insisted on being compliant with the standards that's wrong?
    - badtension 3y ago
      No, but this is a very niche thing to know and if I remember correctly gcc has a widely used specific extension for that which would not be accepted in that case.

mhss 3y ago

I’m not going to justify going in depth in topics not relevant for the job. However going deep in tech topics is necessary to evaluate experience and seniority. The “best interviews” process you described is adequate for the first eng levels but if you want to interview for senior, staff, principal; etc it gets harder and going into depth and breadth is necessary. Heck. Sometimes going into topics “not relevant” for the job is revealing. If their cv says they spent 5yrs writing Linux dev drivers but the position is to write golang web services I may still ask about device drivers if I can get a domain expert. Good people tend to understand very well the things they’ve worked on.

jagged-chisel 3y ago
‘going into topics “not relevant” for the job is revealing‘ I would suggest anything on the applicant’s cv is fair game. What makes no sense is asking about removing duplicates from a linked list when that’s nowhere near what the job will entail.
- jonathankoren 3y ago
  It’s literally an intro test question that you can figure out if you know what a linked list is. It’s not that big of a deal. Now trying to remember a specific algorithm like red-black tree rotation or Djikstra’s is something completely different

softfalcon 3y ago

Yeah, I try and background check my interviewer thoroughly because of the “threat” issue. I always ask who will be interviewing me and look them up. I specifically try and answer their questions and “hold back” a bit when answering if I can. I also sometimes will drop a nugget of knowing more and study their reaction. Some interviewers react quite poorly if you hint you know considerably more about a subject than they might want you to know. I have friends with a lot more education than myself (PhD, masters, very senior) and they say they have to do this A LOT. The goal is to see how the interviewer handles not being the smartest in the room about everything. This is a big deal because it can suss out whether the other person is “on good behaviour for the interview” but otherwise has an enormous ego during regular work hours. No one wants to work for an ego maniac vetting out all the A+ candidates out of fear of competition.

angarg12 3y ago
I never heard about having to do this during an interview, but it sounds concerning. My advice would be to not play mind games and just interview as yourself. Interviews go both ways, so if your interviewer is a psychopath you'd want to know sooner. Then just give the job a pass.
- dallasg3 3y ago
  Psychopaths can be the best chameleons though.
- lowdest 3y ago
  True in aggregate, but special conditions exist. E.g. when interviewing for a rarely available position with extraordinary compensation.
redditor98654 3y ago
I have done 300+ interviews in a 13 year career in FAANG companies and anytime I get a sense a candidate knows more than me, I get all excited and will work extra hard in the debriefs to get the person hired. If the spot is for my own team, even better ans will nudge my manager to hire the candidate. The prospects of learning from the person on the job is too enticing.

sokoloff 3y ago

> You need to be good but not too good you’re a threat. I will happily hire someone who’s a threat to take my job. If I don’t, I can’t ever move up either.

softfalcon 3y ago
This is the right way to take it, but unfortunately many don’t see it this way.

scarface_74 3y ago

With most employees not staying at a job for more than two years, why wouldn’t you hire someone who can hit the ground running? If they spend six months doing negative work ramping up and leave in two years, your investment in them didn’t go far. Yes, I know the answer is to keep them at market wages and don’t fall into the salary compression trap. But often that isn’t under your control as a hiring manager. HR won’t give you a budget for raises. But will give you the budget to hire at market rates.

solarmist 3y ago
Because, as mentioned, it’s a fantasy that someone can step in and understand the peculiarities of a new company(’s technology) without ramp up time. Edit: specified its specifically about the tech. The business side is a whole other thing.
- scarface_74 3y ago
  There are two things to ramp up on - the technology and the business. If they know the technology that’s one less thing to worry about.
  - solarmist 3y ago
    And you can know 100% of the technologies they use; open the repo and still say, “what the hell were they thinking using X like Y!” “Why didn’t they use Y here” “Oh man, this looks like monkey patched code from 2 full versions ago, the right way to handle this now would be 1/3 the code, but oh they can’t update it because they’re mutating the data structure in order to Z… Fuck…” Edit: Eventually, you'll come to an understanding of why it's that way, but it takes time and often experimentation.
    - scarface_74 3y ago
      Everyone thinks what came before then was done stupidly. With maturity, you realize whatever they did worked well enough to get the company to a position where they were able to hire you. As Corey Quinn (a well known “cloud economist”) says, “legacy software is software that generates revenue”.

jagged-chisel 3y ago

Allow me to add. “If you need someone who can hit the ground running…” then you need to have documented the crazy decisions that led to the awkward implementation that is your product. I have yet to meet a company who is using standard, recommended, tried-n-tested, well-known solutions to typical problems. Unless you write docs or stick to standards, no outsider has the context to “hit the ground running.”

SonOfLilit 3y ago
Some people can still hit the ground running when there is a complex codebase with zero docs. They are just very expensive.
- QuercusMax 3y ago
  Last three times I've joined a new team (2004, 2015, 2017) I spent my first week trying to fix tiny bugs and generally just reading my way through the codebase till I understood what was going on. I highly recommend it. I learned to do this when I was working on my master's, and my advisor suggested a project to me, and when I asked him for help figuring out where to start, and he told me to read through the code until I understood it, and come to him if I spent more than an hour or two stuck on things. Thanks, Mikhail - your advice was fantastic.
  - not_alexb 3y ago
    That only works if the code was written in a semi-digestible format; I've met my fair share of monstrosities that were propped up by race conditions -- you're not going to briskly digest them in a week (especially if you're in the unlucky circumstance of only having a single breakpoint per run and the engineers who had any understanding of it haven't worked there in 20 years).
    - SnorkelTan 3y ago
      Test cases can be a good place to start because they are usually clustered around business critical functionality. Or problematic legacy code that needs to work :)

ch4s3 3y ago

This definitely rings true to me. We give an interview that’s basically a simple parser, and ask candidates to do it recursively(in Elixir) using function head instead of Enumerable. We link to the relevant docs and it’s a paired exercise with tests built in. It’s generally been a good predictor of candidates ability to work in our code base and collaborate. The whole thing can be done in 50loc and is not meant to be terribly hard.

angarg12 3y ago

I've conducted hundreds of interviews and I agree about the tech stack, but disagree about culture. Tech is usually easy to pick up, and highly company specific. Any good engineer should be able to learn new tech, and things will change over time. Culture is much harder to "teach". For me testing for culture fit has become much more important than tech acumen, particularly at more senior levels. You need to have a sense of at least whether the candidate aligns with the company culture, and is willing to fit. Not doing this risks several scenarios: a) The candidate takes a while, but finally fits with the culture. This is suboptimal but ultimately a good outcome. b) Candidate refuses to fit with the culture. This will likely cause performance issues, and the employee will ultimately leave or get fired. Not a good outcome. c) Candidate actively subverts the company culture. This is the most destructive outcome and can be quite damaging, particularly at higher levels. Checking that someone will be a good fit for the company is better for both the company and the candidate.

_a_a_a_ 3y ago
It depends what company culture actually is. I have worked at companies where documentation has been frowned upon – I'm not exaggerating either. That is something I most definitely will try and subvert.
spacemadness 3y ago
I recently interviewed a candidate that seemed solid technically but kept calling me bro. I’m pretty laid back but that was a fail. Note to everyone here: don’t do that.
- the_gipsy 3y ago
  Chillax, bro.
- goostavos 3y ago
  Bruh. Counter note: I've done 100s of interviews. A bro, bruh, or brah wouldn't even register as something notable to me. This is just how my younger coworkers talk. Their use of "bet" has taken some getting used to.

hardlianotion 3y ago

Yeah - my last interview was a bit like that. Uninteresting, lazy factorial question, some syntax bits on Python, can you list some canonical definition of object orientation, no probing at all on any topic of interest, and then a brief trivial squabble on what a list comprehension is.

twelve40 3y ago

> so the interviewer can rank you vs themselves. You need to be good but not too good you’re a threat Maybe only about 10% of people who are sadists or calculating assholes actually follow that motivation? Unless you had a very special sample pool. Most interviewers i've met - both good and bad - were just trying to do what they think is right, with varying degrees of competence.