Questions to ask in interviews(cternus.net)
cternus.net
Questions to ask in interviews
https://cternus.net/blog/2017/10/10/questions-i-m-asking-in-interviews-2017/
107 comments
That's truly a brilliant variant of "What will it take to succeed in this role?" Fantastic!
I (founder) actually love hearing these types of questions because they convey actual interest.
However, by no means am I saying ask for the sake of asking because I’ll read through that and will probably try to turn it into a conversation you’d be expected to participate in ;)
However, by no means am I saying ask for the sake of asking because I’ll read through that and will probably try to turn it into a conversation you’d be expected to participate in ;)
Same here.
Very often it's the questions the interviewee asks in the interview that make my mind up on a hire/pass decision.
Very often it's the questions the interviewee asks in the interview that make my mind up on a hire/pass decision.
This one is a killer. When I talk to candidates in an interview we do a 30ish minute problem and then you get 30 minutes time to ask anything you can think of with your potential boss. So many people have no questions. You really don't care if we don't use source control, do waterfall development, make people work 14 hour days, or code in pascal? (None of that is true, but if you never ask...)
A mixed bag. Questions like:
Tell me about your hiring process — how many rounds, how many interviewers? Is there anything special about your interview process I should know? Are coding interviews on a whiteboard or laptop? What resources do candidates have access to while coding? Assuming the process goes well, how long does your hiring process typically take? How long do candidates who are given offers have to decide on an offer?
are perfectly fine, because they're simple and objective, and can be immediately answered by the company (if they have their shit together on any meaningful level). But questions like:
What are you trying to figure out about a candidate in an interview? Why do you think your current process does that effectively? What biases have you decided to accept in your hiring process? Which are you trying to change?
would be a red flag, because really now, it's not like employers have huge swaths of time available to holistically explain the raison d'être of their hiring process and how it got that way. If anything it's the exact opposite -- if they company is successful, then their people have almost no time at all to wax philosophic which each and every candidate about such topics.
So to ask questions of the latter sort strikes me as a bit obtuse.
Tell me about your hiring process — how many rounds, how many interviewers? Is there anything special about your interview process I should know? Are coding interviews on a whiteboard or laptop? What resources do candidates have access to while coding? Assuming the process goes well, how long does your hiring process typically take? How long do candidates who are given offers have to decide on an offer?
are perfectly fine, because they're simple and objective, and can be immediately answered by the company (if they have their shit together on any meaningful level). But questions like:
What are you trying to figure out about a candidate in an interview? Why do you think your current process does that effectively? What biases have you decided to accept in your hiring process? Which are you trying to change?
would be a red flag, because really now, it's not like employers have huge swaths of time available to holistically explain the raison d'être of their hiring process and how it got that way. If anything it's the exact opposite -- if they company is successful, then their people have almost no time at all to wax philosophic which each and every candidate about such topics.
So to ask questions of the latter sort strikes me as a bit obtuse.
Companies above garage size literally employ people to answer candidate questions. If the company hasn't invested the time to answer "What are you trying to figure out about a candidate in an interview?" and its recruiters don't have a simple, objective answer, they should stop interviewing and go answer that before they start again.
A simple answer is something like, "We want to figure out whether a candidate can do the work we need them to do. We do that by giving candidates sample work problems which are streamlined versions of problems we've actually solved at the company in the past. People we hire are more likely to still be employed with us than they are at our competitors after a year. We know we don't hire enough women and URMs into technical roles, and we're instituting a rule that at least one woman or URM candidate needs to be interviewed for each open role."
A simple answer is something like, "We want to figure out whether a candidate can do the work we need them to do. We do that by giving candidates sample work problems which are streamlined versions of problems we've actually solved at the company in the past. People we hire are more likely to still be employed with us than they are at our competitors after a year. We know we don't hire enough women and URMs into technical roles, and we're instituting a rule that at least one woman or URM candidate needs to be interviewed for each open role."
"We want to figure out whether a candidate can do the work we need them to do."
Well, yeah, that's the thing - the answer is (or should be) so self-evident that one wonders if one wonders whether the question is really worth the bandwidth.
Well, yeah, that's the thing - the answer is (or should be) so self-evident that one wonders if one wonders whether the question is really worth the bandwidth.
So few companies are clear about it in their hiring processes, and therefore wind up hiring for all sorts of skills which have at best weak bearing on actual job performance in most roles (eg. brain teaser memorization) that the answer is, empirically, yes.
Hmm. I have they sense they know do what they want ("a candidate who can do the work") but have but are basically at a loss as to how to deterministically assess that via the standard interview format. Hence the brain teaser stuff.
Not asking these questions is giving a free pass.
I am in favor of asking 'Are questions asked in the interview a true reflection of what I would be doing if I was hired.' If the answer is no, then you have more questions that revolve around 'how they evaluate best-fit'.
The tech interview process is broken and change requires challenging and questioning the status quo.
I am in favor of asking 'Are questions asked in the interview a true reflection of what I would be doing if I was hired.' If the answer is no, then you have more questions that revolve around 'how they evaluate best-fit'.
The tech interview process is broken and change requires challenging and questioning the status quo.
I agree, the latter batch of questions strike me as terrible things to ask.
> What are you trying to figure out about a candidate in an interview? Why do you think your current process does that effectively?
Unless the interviewer is from HR they probably don't know (or care) much about the answers, and unless you're interviewing for a position in HR, knowing the answers won't tell you much about whether to take the position. So why ask at all?
Questions like these are analogous to bike-shedding - asking about what's most visible to you at that moment, rather than about what's important.
> What are you trying to figure out about a candidate in an interview? Why do you think your current process does that effectively?
Unless the interviewer is from HR they probably don't know (or care) much about the answers, and unless you're interviewing for a position in HR, knowing the answers won't tell you much about whether to take the position. So why ask at all?
Questions like these are analogous to bike-shedding - asking about what's most visible to you at that moment, rather than about what's important.
You don't think that the company's algorithm for hiring your coworkers tells you much about whether to take the position? That's almost literally the most important thing I know how to find out during an interview.
> You don't think that the company's algorithm for hiring your coworkers tells you much about whether to take the position?
I don't think that hearing whoever happens to be interviewing me defend their interviewing process tells me much about whether to take the position.
I don't think that hearing whoever happens to be interviewing me defend their interviewing process tells me much about whether to take the position.
Hunt for red flags, you can thank me later:
-The person I'm replacing, why did they leave?
-How much overtime is done and is it paid? Are weekends required? Are people asked to volunteer for a weekend shift? Do you have "deployment days" where people have to stay until/past midnight not accounted anywhere?
-Who is going to be my manager/technical lead? Can I talk to them?
-Is this a full time position, or full time supplemental (ex: IBM) Oh, it's full time suplemental, is overtime paid? Do I have vacation days and health insurance?
-Can you show me the exact spot where I'll be sitting?
-Can I take two weeks to decide on the offer considering I have currently three more interviews in progress?
-The person I'm replacing, why did they leave?
-How much overtime is done and is it paid? Are weekends required? Are people asked to volunteer for a weekend shift? Do you have "deployment days" where people have to stay until/past midnight not accounted anywhere?
-Who is going to be my manager/technical lead? Can I talk to them?
-Is this a full time position, or full time supplemental (ex: IBM) Oh, it's full time suplemental, is overtime paid? Do I have vacation days and health insurance?
-Can you show me the exact spot where I'll be sitting?
-Can I take two weeks to decide on the offer considering I have currently three more interviews in progress?
A trap I see promoted by recruiters and companies with poor culture (typically big corporate settings) is to not ask any probing questions.
Interviewers should have no problems answering questions about their work culture unless it is unhealthy or broken.
I was once told I was egotistical after the interview (because of my probing questions) but was offered and accepted the job anyway - it was a admirable brand. Quickly found myself regretting. My questions were based around work culture (Is this a new position? Have many people have left recently? etc.)
Discovered the department was toxic, aggressive members with terrible traits. Structurally very secure from legal and HR so unlikely to change anything.
Thankfully was early in my career and left. Lesson? Take the time to thoroughly question the interviewer and reject any company that seems avoiding. Take the advice from this article.
Never had a bad role since.
Interviewers should have no problems answering questions about their work culture unless it is unhealthy or broken.
I was once told I was egotistical after the interview (because of my probing questions) but was offered and accepted the job anyway - it was a admirable brand. Quickly found myself regretting. My questions were based around work culture (Is this a new position? Have many people have left recently? etc.)
Discovered the department was toxic, aggressive members with terrible traits. Structurally very secure from legal and HR so unlikely to change anything.
Thankfully was early in my career and left. Lesson? Take the time to thoroughly question the interviewer and reject any company that seems avoiding. Take the advice from this article.
Never had a bad role since.
Of all my interview questions[0], the favorite is "what is the biggest technical thorn in the company's side." It gets a different response from every person, which gives an interesting perspective of a company.
[0] http://gilgamech.com/docs/resume/interview.txt
[0] http://gilgamech.com/docs/resume/interview.txt
Another question that yields different responses from everyone that I like to ask: "what is your more favorite and what is your least favorite thing about working here?"
One thing I wish I'd asked before starting the job I currently have is how much IT likes to dictate what you can and cannot do on your work machine.
They block iCloud, Messages.app, have some horrible resource-heavy anti-virus, and a ton of other restrictions on my machine that impair my ability to get my job done.
They block iCloud, Messages.app, have some horrible resource-heavy anti-virus, and a ton of other restrictions on my machine that impair my ability to get my job done.
"can I expense equipment I deem adequate if the tools you give me don't suffice?"
Answer: "Dependent on circumstances and cost"
This. If I were told I had to VPN from a brick laptop into a VM, both widows machines, with heavily restricted permissions, I would have cut the interview short.
[deleted]
> iCloud, Messages.app
At least you get to use macOS at work, mad jealous!
At least you get to use macOS at work, mad jealous!
First thing I did when promoted to a position of responsibility - Gave all developers Macs if they wanted them.
Cue disappearance of frequent grumbling about “IT”, since worst they can do now is install McAfee, which is worked around by exclusions for devs (with absolutely everything thrown into exclusion folder!).
Shit actually gets done and “fuckin IT” is no longer a valid excuse for not delivering.
Cue disappearance of frequent grumbling about “IT”, since worst they can do now is install McAfee, which is worked around by exclusions for devs (with absolutely everything thrown into exclusion folder!).
Shit actually gets done and “fuckin IT” is no longer a valid excuse for not delivering.
Is your team diverse? Is diversity a priority, and if so, what do you do to promote it?
Am I the only person to call BS on this one? How this is likely going to be interpreted by an interviewer is "can I excuse my poorer skills/performance by capitalizing on my gender/race?", so you will get a politically correct answer like "diversity is among our core values and we promote it by giving preference to <...> among the candidates with equal skills and backgrounds" and will never hear from them again.
I mean, diversity is a legitimate value, but asking this during an interview when you are trying to advertise yourself as a valuable addition to the team, is a bit strange IMO.
Am I the only person to call BS on this one? How this is likely going to be interpreted by an interviewer is "can I excuse my poorer skills/performance by capitalizing on my gender/race?", so you will get a politically correct answer like "diversity is among our core values and we promote it by giving preference to <...> among the candidates with equal skills and backgrounds" and will never hear from them again.
I mean, diversity is a legitimate value, but asking this during an interview when you are trying to advertise yourself as a valuable addition to the team, is a bit strange IMO.
I care about diversity. I've had experience with enough teams to know that teams that are homogenous (in whatever way -- this isn't exclusive to white guys, though that's the obvious example) tend to have problems.
I think I know what you're talking about. I've seen teams where everyone tries to look exactly the same way and is expected to have exactly the same interests and hobbies. That usually ends up being quite toxic and demotivating.
The trouble is - once the company starts setting quotas and special rules for enforcing diversity, it attracts the type of people that focus on gaming those rules instead of bringing in added value and this quickly creates another form of toxicity.
In my opinion the ideal work environment is somewhere between those 2 extremes.
The trouble is - once the company starts setting quotas and special rules for enforcing diversity, it attracts the type of people that focus on gaming those rules instead of bringing in added value and this quickly creates another form of toxicity.
In my opinion the ideal work environment is somewhere between those 2 extremes.
> it attracts the type of people that focus on gaming those rules
Can you tell me how you know this or what makes you think it is true? It sounds like a readily available stereotype.
Can you tell me how you know this or what makes you think it is true? It sounds like a readily available stereotype.
Human nature really. The moment you transition from applying common sense to a formal set of rules, there are always some people ready to abuse it. One of the well-known historical anecdote would be the cobra effect [1], I guess.
A more recent example is how whiteboard programming questions during interviews turned out to be ineffective because it indicated how well a candidate rehearsed this type of questions, rather than their programming abilities.
[1] https://en.wikipedia.org/wiki/Cobra_effect
A more recent example is how whiteboard programming questions during interviews turned out to be ineffective because it indicated how well a candidate rehearsed this type of questions, rather than their programming abilities.
[1] https://en.wikipedia.org/wiki/Cobra_effect
The whiteboard thing is different. Candidates of all backgrounds can practice that and thus make it less effective as a tool to filter out bad applicants. But diversity quotas, for example, are harder to game because most people can't change much about themselves to meet diversity criteria. So instead you are presumably talking about people who use their background to get an advantage in the hiring process and end up in roles a role for which they are not competent. But this is also fuzzy, because if the company is seeking diversity, why shouldn't people apply and let the company decide if their skills are sufficient? How are they "gaming" something by showing up and being hired? That's a failing of the company, not the candidate.
Which problems arise due to homogeneity?
Successful groups are diverse. If groups become gratuitously homogeneous there arises a lack of variance in approach. This lack of variance:
- Reduces ability to catch errors. Linus: "given enough eyeballs, all bugs are shallow". But this does not work if everyone looks at things in the same way.
- Makes it easier for undesirable decision cascades to form: One or two people have an idea, and the other members in the group copy their decision, because they always agree. Smart well-weighted decisions are the product of disagreement.
- Stifles innovation. Do you really want your tech company to be all Stanford graduates? Where everyone knows the exact same algorithms, because they sat in the exact same classes, by the exact same professors for decades?
- Is inefficient in regards to Pareto optimality: It is impossible to hire someone that knows all. Hiring for diverse skill sets comes close. Hiring people with homogeneous skill sets is an expensive uphill battle, that relies on small random mutations.
- Reduces the motivation of your top performers. The really desirable job candidates don't always like working in a drone factory, where everybody dresses the same, there is no challenging of their ideas, and, for instance, women all have inferior roles.
- Reduces ability to catch errors. Linus: "given enough eyeballs, all bugs are shallow". But this does not work if everyone looks at things in the same way.
- Makes it easier for undesirable decision cascades to form: One or two people have an idea, and the other members in the group copy their decision, because they always agree. Smart well-weighted decisions are the product of disagreement.
- Stifles innovation. Do you really want your tech company to be all Stanford graduates? Where everyone knows the exact same algorithms, because they sat in the exact same classes, by the exact same professors for decades?
- Is inefficient in regards to Pareto optimality: It is impossible to hire someone that knows all. Hiring for diverse skill sets comes close. Hiring people with homogeneous skill sets is an expensive uphill battle, that relies on small random mutations.
- Reduces the motivation of your top performers. The really desirable job candidates don't always like working in a drone factory, where everybody dresses the same, there is no challenging of their ideas, and, for instance, women all have inferior roles.
Agreed, but it seems to me that, in the context of our industry, race and gender diversity is way less important than the other kinds of diversity(ex. age, industry background, type of personality).
This isn't an assumption I would make immediately, but I am not a hiring manager, so I can see your point. Perhaps ask about how they choose to encourage inclusivity?
This only covers one aspect of managing diversity though. Other than practising active diverse hiring though, some companies are very active in diverse communities which naturally leads to diverse hires.
I think it is absolutely an important thing to try to delve into, but yeah, maybe try to be strategic about it.
This only covers one aspect of managing diversity though. Other than practising active diverse hiring though, some companies are very active in diverse communities which naturally leads to diverse hires.
I think it is absolutely an important thing to try to delve into, but yeah, maybe try to be strategic about it.
Interviews are not (just) advertising yourself: it's a date, and a two way street.
Does your concern about an interviewer misinterpreting the intent of the question change if the asker presents as a white man?
People trying to game the rules come from all sorts of different backgrounds, so my concern wouldn't really be affected.
When I evaluate a job, I usually optimize for a few things (position, location, salary, tech) but very TOP of the list (i.e., non-negotiable) is what my sense of happiness as a contributor/developer will be.
A very good metric to this (for me) is lines of code. Take where they say their product is (in terms of features etc) and then weigh that agains their LOC (if they're willing to give it to you)... If you get a sense that the LOC is far too much wrt the capability of the product (experience/intuition will give you a feel for this over time, as you start paying attention to the metric)... this will give you a good sense of how many late nights you'll be spending trying to fix some nasty bugs or contend with spaghettini instead of delivering real value.
A very good metric to this (for me) is lines of code. Take where they say their product is (in terms of features etc) and then weigh that agains their LOC (if they're willing to give it to you)... If you get a sense that the LOC is far too much wrt the capability of the product (experience/intuition will give you a feel for this over time, as you start paying attention to the metric)... this will give you a good sense of how many late nights you'll be spending trying to fix some nasty bugs or contend with spaghettini instead of delivering real value.
Experience and intuition give you approximately no useful, valid "feel" for how much LOC is appropriate for a given thing, with the possible exception of outliers or incredibly trivial programs.
We don't value LOC as a measure of productivity because it is a terrible metric to use. That doesn't change just because a person is on the developer rather than the manager side of things.
We don't value LOC as a measure of productivity because it is a terrible metric to use. That doesn't change just because a person is on the developer rather than the manager side of things.
LOC can be a huge indicator of quality of code imho—would you want to work on a 100k loc app that is more or less crud operations for a specific domain? Etc.
If you care about happiness, why would you want to work on a CRUD app at all?
Anyway I'm not sure what else your 100K LOC is supposed to represent - that the app has a lot of responsibilities?
Anyway I'm not sure what else your 100K LOC is supposed to represent - that the app has a lot of responsibilities?
I couldnt care less as long as the codebase has a decent structure. And decent structure often increase lines of code.
I’ve found the opposite to be true. Good structure yields succinctness.
Side note: I'm to point now if I get pointless algorithm pop quiz questions in an interview I'll politely ask to move on.
One hypothesis I've heard is that companies have found that the kinds of questions that get asked in programming interviews can serve as a decent proxy for IQ tests (which are effectively illegal for hiring purposes), if they choose the right questions.
So even if these questions aren't related to the day-to-day work programmers do at the company, it could give them a legal way to filter for intelligence.
I say that it could because I think they'd have to select the questions fairly carefully to ensure they're achieving the intended result, and then compare the success of the candidates hired via those questions vs. the success of those hired via work samples or different types of interview questions.
So even if these questions aren't related to the day-to-day work programmers do at the company, it could give them a legal way to filter for intelligence.
I say that it could because I think they'd have to select the questions fairly carefully to ensure they're achieving the intended result, and then compare the success of the candidates hired via those questions vs. the success of those hired via work samples or different types of interview questions.
Yep! I think a lot of software developers think they're expert psychologists when asking these type of questions
What response do you receive when you ask to move on?
Probable response: `${GENERIC_APOLOGY}, i'll show you out.`
Probable thought process of interviewer:
* What a prick
* LOL we have 200 resumes on file for this position
* Dammit I'm going to have to interview more people
* When can I go back to being an actual engineer, the job I was hired for
Probable thought process of interviewer:
* What a prick
* LOL we have 200 resumes on file for this position
* Dammit I'm going to have to interview more people
* When can I go back to being an actual engineer, the job I was hired for
+1 for the thought process. You left out "Damn, I suck at interviewing. I can't believe they want ME to help decide who we hire. I'm still trying to figure out how I snuck in the door."
I answered the question on big o and gave some examples. The guy asked to have me implement something ridiculous, I responded, honestly I wouldn't, I'd use the one in the jdk. He was a little shocked and kind of stuttered onward. I didn't get the job, and I'm fine with that.
I am at this point too. But I am yet to find someone who hires without these, unless you are going in with strong referral.
I've had several interviews that were pretty practical. They do exist but there's unfortunately no way to know in advance unless the company advertises it.
if you're gonna take that route, the appropriate response is:
"Will this be relevant to my daily responsibilities and, if so, in what exact context?"
or
"How many times per week is this algorithm re-implemented by your engineers to solve real problems?"
it may in fact be relevant, and then you better know it. but for 99.5% of dev positions, it's just a BS test. knowing the Big-O, cpu/mem trade-offs and applicable datasets for common algorithms is usually important but being able to re-implement them rarely is. the most important thing is knowing what the algos are and where they need to be utilized (binary search, bloom filters, nested sets, etc...). the most i do is give high-level descriptions of the algos' steps, if i know them.
it's valuable to have the interviewers describe early on what a typical day entails at the position you're applying for and what type of assignments are typical. you'll have much more leverage to have these types of conversations.
of course, this attitude ain't gonna fly for low-level coders working on kernels, compilers, graphics, etc.
"Will this be relevant to my daily responsibilities and, if so, in what exact context?"
or
"How many times per week is this algorithm re-implemented by your engineers to solve real problems?"
it may in fact be relevant, and then you better know it. but for 99.5% of dev positions, it's just a BS test. knowing the Big-O, cpu/mem trade-offs and applicable datasets for common algorithms is usually important but being able to re-implement them rarely is. the most important thing is knowing what the algos are and where they need to be utilized (binary search, bloom filters, nested sets, etc...). the most i do is give high-level descriptions of the algos' steps, if i know them.
it's valuable to have the interviewers describe early on what a typical day entails at the position you're applying for and what type of assignments are typical. you'll have much more leverage to have these types of conversations.
of course, this attitude ain't gonna fly for low-level coders working on kernels, compilers, graphics, etc.
[deleted]
At that point you may as well just leave. You’re not going to talk the interviewer out of doing the interview.
What I don’t understand though is this: why not just do the problem? People ask these kinds of questions to see how you solve problems and what it’s like to work with you. They ask the same question to every candidate so they can calibrate. They ask questions to known problems so they can see how you will handle unknown problems (ie the job).
How else do you expect them to interview you?
What I don’t understand though is this: why not just do the problem? People ask these kinds of questions to see how you solve problems and what it’s like to work with you. They ask the same question to every candidate so they can calibrate. They ask questions to known problems so they can see how you will handle unknown problems (ie the job).
How else do you expect them to interview you?
> What I don’t understand though is this: why not just do the problem?
Because none of the work I'm interested in deals with CS trivia at that level, and it generally is a strong indicator that the company is engaged in one or more terrible practices like, e.g., incorrectly thinking Google's hiring process is generalizable or that CS trivia is the same as engineering. Or else it is looking for someone who doesn't know or care to think about the bigger picture and solve bigger problems than what they can pick out of a textbook (i.e. they're looking for a technician, not an engineer).
I'm not a fresh graduate looking for my first job in which I'll spend my day throwing code at an editor to implement someone else's designs because I lack the experience and wisdom to participate in the design process, nor am I ignorant and arrogant enough to believe a little understanding of DS&A is sufficient to cover all or even most of the important problems in engineering a product.
> They ask questions to known problems so they can see how you will handle unknown problems
That doesn't make any seunse. These kinds of problems test memorization and little else.
> How else do you expect them to interview you?
By asking intelligent questions having to do with problem solving and not running through the college level CS equivalent of basic arithmetic.
Because none of the work I'm interested in deals with CS trivia at that level, and it generally is a strong indicator that the company is engaged in one or more terrible practices like, e.g., incorrectly thinking Google's hiring process is generalizable or that CS trivia is the same as engineering. Or else it is looking for someone who doesn't know or care to think about the bigger picture and solve bigger problems than what they can pick out of a textbook (i.e. they're looking for a technician, not an engineer).
I'm not a fresh graduate looking for my first job in which I'll spend my day throwing code at an editor to implement someone else's designs because I lack the experience and wisdom to participate in the design process, nor am I ignorant and arrogant enough to believe a little understanding of DS&A is sufficient to cover all or even most of the important problems in engineering a product.
> They ask questions to known problems so they can see how you will handle unknown problems
That doesn't make any seunse. These kinds of problems test memorization and little else.
> How else do you expect them to interview you?
By asking intelligent questions having to do with problem solving and not running through the college level CS equivalent of basic arithmetic.
We don’t have algorithm problems at our coding interview but they are relatively simple problems. You’d be surprised how a simple problem _does_ filter candidates that can “bluff” their way up to an actual co-sign interview. In my limited experience it can give the interviewer valuable
Info.
Also, at my company this serves as a jumping off point for other questions. Scaling, concurrency, networking etc. All great for seeing breadth of knowledge and problem solving/talking through a solution type skills which I think are relevant in day to day work.
Also, at my company this serves as a jumping off point for other questions. Scaling, concurrency, networking etc. All great for seeing breadth of knowledge and problem solving/talking through a solution type skills which I think are relevant in day to day work.
If you ask too many of these questions you're going to set off red flags that you're an entitled person who's looking to receive more value than you contribute. I'd focus more on asking about the company's future plans and strategies.
Always ask questions that are probing.
The interviewer should never worry about being asked ANY questions about their culture unless it is unhealthy or broken.
The interviewer should never worry about being asked ANY questions about their culture unless it is unhealthy or broken.
Why? I think you're perfectly entitled to ask questions that affect your day-to-day. It isn't a one-way street.
The wording of the questions could be improved.
Also, you can ask them differently. So instead of "How late do people usually arrive/stay?" you can ask "How early do most people get to the office? Am I encouraged to come early?"
Makes you sound better.
Makes you sound better.
A lot of these work culture and life and tech questions can be backed into.
My series of questions when I get the chance to talk to an engineer on the team I'm interviewing for is just this, "What's a normal day at work look like for you? Not a fire drill day or anything crazy. Just walk me through what you think of as your routine."
And once you can get that conversation going, you can pretty easily suss out the answer to very many questions in the article without coming across as even really asking questions, let alone seeming like a special snowflake.
Some questions can be more direct than others. But I think many of them can be figured out through a healthy conversation in the interview process.
If you can't engage someone in that kind of a conversation someone ought to be seeing some red flags.
My series of questions when I get the chance to talk to an engineer on the team I'm interviewing for is just this, "What's a normal day at work look like for you? Not a fire drill day or anything crazy. Just walk me through what you think of as your routine."
And once you can get that conversation going, you can pretty easily suss out the answer to very many questions in the article without coming across as even really asking questions, let alone seeming like a special snowflake.
Some questions can be more direct than others. But I think many of them can be figured out through a healthy conversation in the interview process.
If you can't engage someone in that kind of a conversation someone ought to be seeing some red flags.
Why? Why on earth would wanting to know about the place where you're going to spend the majority of your day cause you to seem "entitled"?
It's not the wanting to know part that makes someone seem entitled. It's the way they go about obtaining the answers to the questions they want to know. Dealing with humans sometimes requires tact, regardless of what you have to bring to the table.
...which is pretty sad to think. You're entitled because you want to ask a set of questions that takes maybe a few hours tops because you want to evaluate this place you are going to spend more time at than almost anywhere else for some number years into the future? It's crazy that we spend more time investigating what vacuum or small kitchen appliance to buy than we do on one of the most important decisions we ever make.
One dev I worked with asked the following question at the companies he interviewed at (he got offers from all of them, btw): "What percentage of your co-workers would you like to see fired?"
Most interviewers responded in the ten percent range. One notable exception was a place where they responded with "fifty percent" -- I can't imagine what it was like there.
Most interviewers responded in the ten percent range. One notable exception was a place where they responded with "fifty percent" -- I can't imagine what it was like there.
I would give joke answer with random number. There is no way I would give you honest answer to that question, if would indeed wanted to see some of my colleges fired. You are testing interviewer personality, not the company there.
Without other information, 50% may mean a lot of bad colleges or arrogant self-aggrandizing interviewer.
Without other information, 50% may mean a lot of bad colleges or arrogant self-aggrandizing interviewer.
Amazed he got offers from all of them. If someone asked this during an interview I would most definitely not give them an offer. It seems indicative of a vengeful and toxic mentality.
>What are you trying to figure out about a candidate in an interview? Why do you think your current process does that effectively?
I asked this to my netflix interviewer, he just mumbled some incoherent answer about "netflix values" and didn't answer my question. He seemed to get angry when I reworded my question and asked him again.
Seems like they have no idea why they are following that process, just blindly copying "industry best practices" .
I asked this to my netflix interviewer, he just mumbled some incoherent answer about "netflix values" and didn't answer my question. He seemed to get angry when I reworded my question and asked him again.
Seems like they have no idea why they are following that process, just blindly copying "industry best practices" .
Netflix is very (in)famous for their culture deck. I could understand they got a little piqued. Assuming you did not read it before the interview, they are looking for: good judgment, communicative, impactful, curious, innovative, courageous, passionate, honest, not selfish, performant, smart, professional team players. Hah.
https://www.slideshare.net/reed2001/culture-1798664 (17 million + views)
I am on the fence about the second part of your question. On the one hand: If they are free to grill you about hypotheticals and process, why can't you do the same? On the other hand, should you really? It is a very cheeky ("courageous") question that would catch me off guard. "Who are you to question the very job interview we are currently having? How is this relevant to your prospective job? Current interview not up to par for you?".
https://www.slideshare.net/reed2001/culture-1798664 (17 million + views)
I am on the fence about the second part of your question. On the one hand: If they are free to grill you about hypotheticals and process, why can't you do the same? On the other hand, should you really? It is a very cheeky ("courageous") question that would catch me off guard. "Who are you to question the very job interview we are currently having? How is this relevant to your prospective job? Current interview not up to par for you?".
Recruiter made me read through the slide deck. He called me the second-time and 'pop quiz'ed me on the contents of deck.
What a strange company.
What a strange company.
It's going to depend a lot on the individual interviewer how well they can answer that question. If recruiting and the hiring manager don't both have good answers to that question, though, that's a big red flag.
A reason for that might be because if they tell you straightforward, then it gives candidates a chance to "fake it" just for the job when they might not be the best candidate.
Note that the questions re: business plan are more appropriate for a startup unless you’re applying for an executive role, in which case you aren’t interviewing in this way anyway. (Interviews for exec level positions are MUCH more thorough/prolonged and take a lot of time given the $$$ and responsibility involved).
Also, the questions re: benefits etc. are more well-suited towards the recruiter you’re working with or HR; it is highly unlikely that the hiring manager knows enough about those things to answer your question effectively.
Everything else is pretty good, though I wouldn’t ask it at once (overwhelming and a negative social signal)
Also, the questions re: benefits etc. are more well-suited towards the recruiter you’re working with or HR; it is highly unlikely that the hiring manager knows enough about those things to answer your question effectively.
Everything else is pretty good, though I wouldn’t ask it at once (overwhelming and a negative social signal)
Weird list.
I usually ask, in no particular order: What do you do, how do you do it, how can I help you, can I remote.
I usually ask, in no particular order: What do you do, how do you do it, how can I help you, can I remote.
Interviewed by some startups (Berlin) I have been asked if I know or to explain them what they are doing... and the funniest thing is they were serious.
Most companies should have that explained on their website - If you haven't done enough diligence to repeat what's on the website, you may not be a good candidate.
Oftentimes what the website says, what the sales team is selling, and what the engineering team is doing are three different things
Maybe they want to know if you know their business? Seems like a fair question to ask.
It's a fair question.
The only trouble is that the vast majority of companies can't be understood if you don't already know the business.
The only trouble is that the vast majority of companies can't be understood if you don't already know the business.
Research before the interview. Always know going into the job what the company does, as it'll help you infer where you can add value.
My point being that the vast majority of research will not tell you anything meaningful about the company.
And that’s a valid answer. “I went over your web site and read some press releases but I’m not quite sure what you do yet. I think it is along these lines...can you explain further?”
Why would you interview at a company if you don't know what they do?
Interviewing is a chore, I'm not going to invest my time in doing it unless I think I'll enjoy being there, which requires at least approving of what the company does.
(I would be a little less choosy if I didn't have a current job, but still probably don't want to write software I have strong moral objections too)
Interviewing is a chore, I'm not going to invest my time in doing it unless I think I'll enjoy being there, which requires at least approving of what the company does.
(I would be a little less choosy if I didn't have a current job, but still probably don't want to write software I have strong moral objections too)
Of course I know what they're doing (or the external reflection of thereof). I still ask. I have yet to find a question that will tell me so much using so little.
I thought I was good at hiring - doing it for 20y - but have no idea.
Three things I want to learn from a candidate:
- Does she/he feel responsible?
- Does she/he self reflect and learn or blame others?
- Can he/she solve problems on her/his own?
Any ideas on how to find out?
Three things I want to learn from a candidate:
- Does she/he feel responsible?
- Does she/he self reflect and learn or blame others?
- Can he/she solve problems on her/his own?
Any ideas on how to find out?
Situation Behavior Outcome questions do a good job of forcing candidates to reveal their motivations and thought processes.
Some examples https://www.themuse.com/advice/30-behavioral-interview-quest...
Some examples https://www.themuse.com/advice/30-behavioral-interview-quest...
Thanks!
Minimum viable interview research: https://codeformore.com/minimum-viable-interview-research/
Knowledge is power: Why are they hiring? https://codeformore.com/knowledge-power-hiring-new-developer...
Knowledge is power: Why are they hiring? https://codeformore.com/knowledge-power-hiring-new-developer...
Another list of questions can be found in this Tech Interview Handbook:
https://github.com/yangshun/tech-interview-handbook/blob/mas...
https://github.com/yangshun/tech-interview-handbook/blob/mas...
I think the "Team" and "Tech" section are interesting, it's the kind of question that you genuinely need to know, but the interviewer might find them a bit "personal".
One question that I like is “Who do you admire on your team?”
One thing I would like to figure out is how often I can ask for help. Any ideas how to phrase that ?
I worked in a small company where I was the only programmer and had to figure everything on my own, plus search engines, IRC, StackOverFlow. Then an interviewer at Intel was mildly unsatisfied that I didn't ask about a test question that wasn't entirely clear. Also, one company where I worked very briefly considered question asked a sign of weakness.
I worked in a small company where I was the only programmer and had to figure everything on my own, plus search engines, IRC, StackOverFlow. Then an interviewer at Intel was mildly unsatisfied that I didn't ask about a test question that wasn't entirely clear. Also, one company where I worked very briefly considered question asked a sign of weakness.
Asking questions for the sake of asking questions, while currently necessary, is stupid. I wish it would go away.
As a founder who sits in on all interviews I agree, but also believe that every question/answer is an opportunity to show more personality — on either side — and as such welcome it.
As it is, I choose my interview battles carefully. One of my favorite questions I ask is whether my position is new (rare for my situation) or if I am replacing someone who left.
This very naturally opens up a conversation about expectations from both sides. If someone separated, why do the interviewers think it didn't work out? If this is a new position, how do they imagine the first year?
Suddenly you're talking about culture, performance and policies without having asked directly about any of those topics.