
Questions to ask a company during a job interview - viraptor
https://github.com/viraptor/reverse-interview
======
harimau777
A problem that I've had is that every company says that they value code
quality, emphasize developer growth, value developer's technical feedback,
etc. even if they don't in practice. I've debated taking a page from old
school behavioral interviewing and asking questions like:

Tell me about a time that you made a decision to improve code quality or
architecture at the expense of a deadline.

Tell me about a time that you invested resources into an engineer's technical
development even though there would be no immediate, short term benefit to the
company.

Tell me about a time that you pushed back on a decision from business or
design because one of your engineers said that it was the wrong technical
decision.

~~~
drongoking
I came here to say basically this. I've worked at enough companies to know
that their ideas of what their values are may not be accurate.

Instead of asking about values, ask about behavior. No one is going to say no
to "Do you value code quality?" Aking what they've done (and sacrificed) to
support code quality will give you a better idea of what their relative values
are.

Asking about their tech ladder will get you an HR answer. Asking "Who was the
last person promoted to X? When?" will give you a better answer. And if they
can't remember the last time, that's an answer in itself.

~~~
war1025
I listened to a podcast recently [1] that talked about "embodied knowledge",
which is basically the idea that what we know is often very different from
what we think we know.

The idea being that you will learn much more about someone / something if you
ask questions that are anchored to a time and place rather than generic
"unembodied" questions.

So the first question you list "Do you value code quality?" is an "unembodied
question" and there is no hook for the person to dig into reality and give you
an honest answer.

The second, "Who was the last person promoted?" is "embodied" in that it is
anchored in time and place. And because of that, a person is going to use
their memory, rather than their rehearsed "value system" answers.

Anyway, it's basically exactly what you said, but I just wanted to recommend
that I thought the podcast was a worthwhile listen.

[1]
[https://www.thepermaculturepodcast.com/2019/1912/](https://www.thepermaculturepodcast.com/2019/1912/)

~~~
Tronno
Without having listened to the podcast, another way to frame this is using the
concept of yes/no questions, who/when/what/why/how questions, and open-ended
questions.

Y/N questions are not very revealing and are likely to lead to dead-ends in
the conversation.

WWWWH questions reveal a specific bit of information, but can also lead to
dead-ends.

Open-ended questions ("Tell me about...", "What do you think of...", etc) will
foster good conversations and uncover new threads to pull. In my experience,
this is by far the best way to interact with other people, whether they are
interviewing you or not.

Coming up with good/relevant questions on the spot is a skill that can be
difficult to master, but is extremely valuable.

~~~
war1025
To expand on this, people will commonly give you unintentional "hooks" for
where you can go to increase the depth of the conversation.

For example, people use common words as short hand for many things ("Work was
stressful", "The kids are being a pain", "We had a really nice weekend"), and
a mistake people run into when talking with others is that they assume the
person they are talking with meant they same thing they themselves would have
if they had used that phrase. This leads to lots of people "listening but not
understanding".

So basically, offhand comments and common phrases are a great place to get a
person to dig in deeper into their feelings on a topic. Usually they indicate
something that is on the person's mind but that they probably haven't worked
through enough to put into words. That means you will get a much more raw and
unfiltered response from them.

Also it's always good to remember that people _love_ to talk about themselves,
even if they say they don't.

------
Diederich
I've been interviewing with Google since 2006 or so, off and on, though I've
never accepted an offer from them. I do this because I always learn several
things from the rigorous on-site interviews, it's a lot of fun, and the
machine that runs the process seems to not mind being turned down in the past.

Back in the beginning of that time period, I used to ask (fairly jokingly) the
same question: "How many servers do you have?" I would use the response to
gauge the interviewer, and mostly just for fun.

Of the dozens of Google interviewers I've spoken to over the years, only one
responded with a number range, and the rest of the responses were largely
grouped into either active playful discomfort.

In my last two rounds of interviews (with various companies, including
Google), I asked three questions:

1\. What brought you here?

2\. What keeps you here?

3\. What keeps you up at night?

The responses to those three have been illuminating.

~~~
vkou
> Of the dozens of Google interviewers I've spoken to over the years, only one
> responded with a number range, and the rest of the responses were largely
> grouped into either active playful discomfort.

That's because most employees don't know, and the ones who do, know that it's
a company secret.

~~~
Diederich
Sure, I never expected a real answer.

------
Beldur
In my experience it's important to not ask "easy" questions that can be
answered by a simple yes/no.

Instead of: Are you friendly to remote work? Ask: Will I be working with
anyone who is remote, or who works from home on a regular basis?

Instead of: Is the work life balance good? Ask: How responsive are people to
emails/Slack over the weekends and after 6pm?

Instead of: Can I have a good career path? Ask: Did any of your senior
engineers start out as junior engineers here?

~~~
rhizome
I've never asked it yet, but I've been thinking along these lines, and for the
last one I think a good construction is "Do you work with anybody who was
hired under a different title than they have now?"

------
protonfish
One I am going to start to ask is "Are all developers allowed to have local
admin access of their computers?" I've struggled against this in my last 3
positions. This is a dealbreaker for me, and should be for all developers.

~~~
relax88
From an infosec professional perspective, this one is always a challenge for
security sensitive places.

I agree with you that developers need admin rights on their development
machines, but I have witnessed first hand why many companies attempt to take
away local admin rights.

When I'm responding to security alerts where developers have downloaded random
.dll files from the internet, or some "troubleshooting utility" that is
actually malware, it doesn't take long until the local admin conversation
comes up.

This is one of those classic "technical solutions for bad human behaviour"
scenarios where a small number of idiots ruin it for everyone. If you want
local admin as a developer, then we need to be able to trust that you aren't
going to do something stupid.

It seems the best way to do this is to issue developers multiple boxes
(corporate laptop + dev box only for dev), and or use a good software
whitelisting program that tracks elevations & the reasons for them, instead of
just blanket giving everyone local admin on their own PC.

~~~
kemiller2002
As a person whose straddled infosec and development, I always struggled with
this. The multiple development machines is probably the best approach, but
I've never truly seen it implemented correctly. I would love to not need admin
access to my machine, but each time the companies I've worked for try this,
it's always a struggle to do anything. This is everything from, "I need to
modify/monitor core components of the operating system" to "The development
tools came out with an update that needs to be installed." Most of the time,
the response I've received was, "Enter a ticket, and we'll get to it." Often
management seems to understand, "I'm waiting someone else" as "I'm behind,
I'll work the weekend." You're right the downloading random things from the
internet is an issue. Sadly I think a lot of this can be solved by the
organization spending the money to buy all the needed tools and evaluate the
correct open source ones, but there always seem to be budget and time
constraints.

I think a lot of this stems from the fact that most of the managers in infosec
for companies aren't developers and haven't ever been one. They really have no
idea what developers really do. I'm not belittling them. It's just not the
career path they took to get where they are. It's difficult to explain to them
how frustrating being hindered is, and this causes a lot of good people to
just leave an organization like that to find something better.

~~~
devdas
IT security people also have different incentives. If developers got bonuses
for uptime while being compliant with all security policy requirements, while
security and operations got bonuses based on features reliably delivered, you
would have different results.

------
sanj
For many years I gave a talk titled "Questions Engineers _Should_ Ask"

This list is missing the two _most_ important [busines] questions:

1\. How do you make money?

If you can't understand, or the interview can't explain, then I'd run away.
This can also lead to interesting questions about risks, competitors, etc.

2\. What's preventing you from making _more_ money?

The answer that you want to hear is _engineering_ _effort_. If not, you're (at
best) a wallflower at the party. Don't be the chump that's at Goldman Sachs
acting as a code monkey for the traders. Don't be writing code at a company
(like Enron) which has its success based on digging holes in the ground.

I can dig up the slides if anyone is interested.

~~~
uniclaude
That's highly disrespectful to software engineers working outside of software
companies. There are many of them and they are not necessarily less smart than
others.

Working in the profit center of a company is often enviable, but let's not
forget that cost centers in large companies can also offer benefits in things
like work/life balance.

~~~
smashface
I don't think the GP intended to call engineers at those kinds of companies
lesser. I think the point that was made was that working at companies where
the company makes more revenue by having better software is a better company
to work for. If your role is a cost you're treated (explicitly or implicitly)
as such. It's a lot easier to show your value to a company by being part of
the revenue side of the equation. Reducing costs is great but there is a bias
towards investing to generate revenue vs investing to reduce cost.

~~~
gonzo41
\--companies where the company makes more revenue by having better software.

You can get vibe of a company by asking if IT is seen as a cost center. If
software is a competitive advantage you know that it's green pastures for your
and yours. But places where culture holds back engineering, like being slow on
the uptake of GIT or CI/CD which is often talked about online, these are
places to be wary of. Those latter companies are either going to have growing
pains or will die out as digitization starts to take them on.

~~~
smashface
I think this may be a better way to phrase what I was thinking. It doesn't
have to be directly related to revenue. The revenue relation just makes it
easier to be counted as core to the business model. I think it's important to
say business model too. IT is core to essentially every business now, but when
IT is core to the how the company fundamentally positions itself in a market
it really changes things.

Though in the context of this thread, I don't know a good question to ask in
an interview to tease out that information when it's not already clear. If you
simply ask "is IT/engineering considered to be vital to the business model or
core to company success", everyone will answer yes regardless of how the
IT/engineering is actually viewed.

------
jcadam
Problem: Interviewers lie.

I once interviewed with a company that brought me into a new, shiny, well-
appointed building on the corporate campus for an interview.

I did well answering their questions. And they answered my usual questions
correctly. Stuff like "Can developers here choose their own tools?" and "My
title is going to be Lead Engineer, will I actually be a Lead Engineer?"

After I was hired, I found out everybody uses Eclipse, no exceptions, and I
was absolutely not going to be leading anything (I was basically going to be
used like an overpaid junior engineer).

The best part: "Oh, you won't be working in the new building..." and was taken
to an old, windowless, leaky, mold-smelling building with peeling paint and
flickering fluorescent lights (think the opening scene from "Joe vs the
Volcano"). My office was a supply closet that was being converted into an
office (by that I mean, "we just pulled most of the stuff out of here, but
otherwise just rearrange the furniture however.") I was given an old 70s
vintage desk that was too low, a sort-of broken chair, and a laptop and left
to my own devices for three weeks while waiting for my new project to get
started. Then I was suddenly moved to even worse accommodations - a cubicle,
which belonged to an employee who had recently died (his stuff was still
there, and it was a month before anyone came to take it away).

I started looking for a new job about 2 days in. Took me a year to find
something else (I eventually had to move to a new city).

~~~
BurningFrog
Recruiters will possibly say anything to get a sale.

But when talking to your future peers/team mates, I think you can expect a lot
of honesty if you ask the right questions about how things _really_ are.

I know I'm always 100% honest, because _if_ they get hired, we'll be
coworkers, and they'll know if I lied!!

PS It's weird that you didn't get the title in the contract

~~~
hrktb
Sometimes they’ll tell lies that their boss tells everyone willing to listen.
Everybody knows these are lies, but they won’t always give you that “read
between the line” interpretation during an interview.

The most obvious one is usually “we’re on an agile process”, but there’s so
many other ones more subtle and hard to get a grip on, short of reading
interviewer’s clues when they answer the canned answer.

Sometimes the same words just don’t mean the same things to them. Sometimes
they don’t realize how bad their situation is.

“Reality shock” in the first days at some workplaces is a thing.

~~~
neilv
Reality shocks I've seen personally:

1\. Workspace/office not the one you were shown/told. This is the most common
one, in my few data points. I think people know it's a factor in appeal of the
job, so it's mentioned, but the followthrough doesn't always happen.

2\. Person you interviewed with is leaving. (One of the people I hit it off
really well with in interviews was a tech co-founder of the established
company. When I arrive as a new Architect, he apologizes and says he had been
looking forward to working with me (which is not something I normally hear),
but he just got an offer for a supercomputer startup that he couldn't resist.
Fortunately, some other great people remained, and I ended up working directly
with one of the other tech founders. I supposed I might've been hired due to
the company knowing that some people were looking to transition out.)

3\. Job not as described. (I've mostly avoided this common pitfall, but once
got bit by it. I was recruited as the Research Scientist who'd execute on an
idea that was sorta outside the scope of two professors who'd come up with it,
but that they wanted to see it done, and it was up my alley. But, subsequent
to discussion, when I'd been told I'd be the sole person leading&doing, one of
the professors' grad students decided to do the idea for their dissertation,
and I didn't find out until the first day on the job. It got worse from there,
but the saving grace was that an all-around great 3rd person was also an
"assistant" on the team, so, morale-wise, I was able to complete the entire
year-long appointment I'd agreed to. I declined when the PI renewed the
appointment for another year, and both us assistants asked not to have our
names on the papers. It was unfortunate, because we did some good work, and
the PI was willing to help me get my own ideas funded, but I couldn't commit
to another year of the accidentally-bait&switch project.)

4\. Famous culture broken. (My anecdote wasn't a first-day reality shock for
me, but first-year. A successful with-revenue early Web tech company in a
university town had a locally well-known policy slogan about how you advance,
which seemed much more widely quoted than the "don't be evil" of another
company, and was repeated to me when I interviewed. Long story short, while I
was working there as a Senior Engineer, someone in company leadership was
willing to spoil culture and morale, to let someone's nephew (or similar)
break the slogan. I went and talked with the head of engineering, who normally
had amazing poise and charisma, but he had no good explanation for that one.
This was when other dotcoms were hiring the then-rare experienced developers
like crazy... but companies sometimes do things that employees don't
understand, creating new reality shocks.)

5\. Representative from new parent company, walking around with representative
from offshoring company, talking to employees about what they do, for multiple
days. A bit like in "Office Space", but at an advanced Web tech company.
(Also, I was concerned when they started asking me about an elaborate 3D
puzzle that someone had assembled near my workspace before I was hired, they
seemed skeptical when I said I didn't know anything about it, and then one of
them asked where they might buy such a 3D puzzle, which I happened to know,
and I couldn't resist being knowledgeable/helpful, even as I suspected it was
just a trick.)

Reality shocks like these are another reason I'd rather talk with prospective
employers, and get as much sense of the team and company as I can, rather than
get distracted with one-way leetcode whiteboarding.

------
reallydontask
> Is there a support / marketing / other call-heavy team close to my new team?

This is so important.

I can probably live with most open plan set ups, sure there will be annoying
times, but if there is a call-heavy team nearby, forget it.

I refuse to wear noise cancelling headphones all day long.

FWIW, interviewers will blatantly lie.

I asked at an interview about equipment quality and was told that they'd not
heard any complaints.

This was 100% bullshit. I was given an ancient laptop, which seemed to re-
ignite complaints about the quality of the equipment and were taken up with,
none other than my interviewer.

~~~
Diederich
> I refuse to wear noise cancelling headphones all day long.

May I ask why? Even when I work at home alone, and there are no stray noises
at all, I'll still wear my headphones when I want to really focus. Years of
mental conditioning has led me to a place where it's much easier to deeply
focus when I'm wearing headphones listening to white noise.

~~~
viraptor
Not the op, but also wouldn't wear them. Weird ear shape means earbuds start
hurting after a while, while the over-ear solutions make me
sweaty/uncomfortable.

~~~
matneyx
Not to mention earrings -- I've yet to find headphones that I can wear
comfortably for a couple of hours that won't leave my piercings sore.

------
tomekowal
I would change the part: ``` Do you use source control? Do you test code? Do
you use bug tracking? Do you use CI/CD? ``` to ``` How do you use source
control? How do you test code? How do you perfrom bug tracking? How do you
solve CI/CD? ```

For really good companies asking if they test code seems insulting :P

~~~
wastedhours
That also moves the question from being closed to being open - potentially
leading to a secondary question that will highlight your ability to ask
insightful Qs.

------
jrjarrett

      How much annual / personal / sick / parental / unpaid leave is available?
    

This is a great question; when I have searched for jobs, it's one of the more
important benefits to me.

Sadly, however, I've found most places have gone to "PTO" \-- combining time
off for illness and vacation into one bank -- how have others successfully
negotiated an appropriate level of time off?

(Context: For a very long time, I worked for companies where sick time was
essentially a non-issue; it was essentially unlimited, with appropriate rules
around requiring a doctor's explanation or having to switch to short-term
disability after a protracted period, but the occasional day or two to recover
from a cold and not spread virus to the whole company without having to choose
between that and visiting family.)

~~~
iamthepieman
I just tell them how much time off I'll need during salary negotiations. I
know you offer two weeks PTO and 3 weeks after 5 year, 4 weeks after 10 years
etc. But I'm not restarting my PTO every time I switch companies. So I will
come in with PTO equal to my experience at a minimum.

~~~
scarface74
PTO is nothing special. It’s just another benefit you can place a monetary
amount on. If they won’t give you more than two weeks paid time off and they
will let you take _unpaid_ time off, add the amount that week of unpaid time
off is worth to your required salary - of course take into account that PTO is
a non taxed benefit.

I feel the same way about 401K matching.

~~~
iamthepieman
yeah sure but depending on the company it's easier to take PTO than UPTO.
People expect you to take all your PTO generally. That's not always true if
it's unpaid.

~~~
scarface74
I know, and I said _and they will let you take unpaid time off_

------
a3n
Why doesn't the interviewee ever ask the interviewer a whiteboard or puzzle
question, "to see how you think?"

~~~
dominotw
Because unless you are some sort of celebrity engineer, "interview is a
conversation between both parties" is nonsense.

Company is interviewing the candidate not the other way around, no matter what
we like to think.

Edit: Sorry I should've clarified. I am specially referring to companies that
don't really have to care about your feelings towards their interviews. FAANGs
for example. They simply don't care and there are million others who are
willing and happy to go though whiteboarding. They just don't have to put up
with your stuff.

Ofcourse you have leverage when you are interviewing at your local java
enterprise shop. But who cares about those jobs, pointless to interview them
with your smartass questions, we all know they are pretty much all the same
more or less.

~~~
nathan_long
> Because unless you are some sort of celebrity engineer, "interview is a
> conversation between both parties" is nonsense.

I disagree. Unless the candidate desperately needs this job, he/she can walk
away. The candidate is free to consider "company won't bother to answer my
questions at the point when they have most reason to be nice to me" as a bad
signal.

> I am specially referring to companies that don't really have to care about
> your feelings towards their interviews

"This company doesn't have to care about my feelings because they are huge and
have lots of applicants and a giant incessant interview machine chugging
through them efficiently" is certainly something I'd consider in whether I
want to work for them, because it tells me I'd be a cog in a machine. (And if
enough people consider that, perhaps they will have to care.)

To the parent question: I wouldn't ask a whiteboard question exactly, but I
would certainly ask some questions about existing architecture and rationale
so I have an idea what I may be working on.

~~~
dominotw
> it tells me I'd be a cog in a machine.

Aren't you a cog regardless though. Why would one work for half the salary
just because of an interview. If one can get over the interview part, he/she
can retire 10 yrs sooner.

~~~
jerf
Well, to take the metaphor too far, there's cogs that are greased and used
only within spec, then there's cogs that are never greased and deliberately
run beyond spec, rust ignored, etc., and in the worst cases, cogs that are
used as, err, bulletproofing or something. Metaphors. Never trust 'em, they
always turn on you.

For what I'm paid, I don't mind being a bit of a cog. Work is a means to an
end for me, not my identity. But I would like to be kept greased and worked
within spec, not constantly in crunch time. And while I am fundamentally
disposable, I prefer to work in a place that sees I'm lot more valuable _not_
being disposed of. (Again, metaphor breaks down here; planning on your
personnel being routinely disposed means you are planning on nobody ever
actually developing any skill in your systems.) It's not all the same thing.

------
EnderWT
I'll give a shoutout to [https://www.keyvalues.com/culture-
queries](https://www.keyvalues.com/culture-queries) where questions like these
are explained in more depth, for example:

Can you give me an example of a mistake you've made here, and how it was
handled?

Ideally, your interviewer will answer honestly. If people are comfortable
discussing big failures, it suggests that the company has created a safe
environment for people to fail, and signals that it’s an environment conducive
to taking risks and experimenting.

On the other hand, if people are guarded when it comes to discussing failures,
they might be working in a culture of blame.

You can follow up by asking about their practices around investigating issues,
writing post-mortems, and overall documentation.

------
CalRobert
That's a really good list. I really wish I'd asked a few of those in the past.

"Where do you plan to be in 5 years" is actually a really good question to ask
a company. Many have no idea (which is possibly fine, but good to know)

Interviews can also be a fantastic place to get real feedback - but you have
to do it during the interview; almost nobody gives real feedback after the
fact.

"What would give you concerns about hiring me?"

"If you could have your dream candidate for this role, what would they look
like?"

"What in my application caused you to call me in for an interview?"

Are a few that I've found helpful.

------
quotemstr
I use the comment test. It's pass/fail and goes like this: "Suppose I'm
reading some code and I see an obvious typo in a comment. What's the process
for fixing it?"

(Note: I've actually gotten all of these answers, albeit sometimes only after
I joined a group (prompting me to develop this test in the first place)).

Fail: "just edit the file lol"

Pass: "edit the file and check it in"

Pass: "edit the file, send a diff, get a +1, and check it in"

Suspicious: "edit the file, send a diff, get your code and style approvers,
wait for presubmit, and check it in"

Hard fail: "file a bug..."

WTF are you even doing: "we can focus on code quality issues after this
milestone"

~~~
protomyth
Remember to ask about 'code lockdowns', some coding jobs have seasons of a
sort.

------
neilv
> _What 's the status of / view on diverse hiring?_

As someone who believes in value of diversity (just to be clear), for both
organizational and societal reasons, I think this is an important question,
for a variety of reasons -- but also a question that candidates might not want
to ask.

Candidates might not want to ask, due to not knowing how the asking will be
perceived. Or due to not wanting to mention some unapparent quality (e.g.,
being gay), because they don't know how welcome that will be, or they just
want to be treated as, say, a developer, at that stage of meeting prospective
colleagues.

It's much better if the company communicates its real
policies/practices/culture and status proactively (beyond the standard HR
equal opportunity statements), so no one has to ask.

~~~
umvi
It could also be asked for the opposite reasons. For example, some developers
might consider it a "red flag" that companies prioritize diversity hiring and
will want to stay away.

------
codingdave
I'd focus your questions to only the ones where answers might make a
difference as to whether you accept the job. Are you really going to turn down
a job because their on-boarding process isn't optimal? Or to a bad tech
answer... would you turn down the offer, or help them improve from the inside?

I do like this list, but filter it down to what you need to respond to an
offer. And that filter will be different for everybody.

Typically when I am in an interview, I explicitly draw that line with the
interviewer, saying, "I have more questions, but I also have the answers I
need to make a decision if you extend an offer, so we can get the rest
answered later if we move forward together."

~~~
viraptor
Turn down an interesting offer because of onboarding? Maybe not. Choose
between two roughly equivalent companies, because one has a good onboarding
process which likely means both investing in growth and caring about
documenting things for people who didn't have lots of existing context?
Definitely possible.

~~~
codingdave
Good point.

Like I said, everyone's filter will be different. There are probably valid
reasons to ask every question on the list. And also valid reasons to skip
every question. We all have different goals and preferences with our careers.

------
jfb
I am now a Mr Manager Person, so I have a different but related set of
questions:

1\. What is the demographic breakdown of the engineering team? And, what does
the company affirmatively do to foster diversity?

2\. What resources do the founders have available — investors, board, mentors,
for instance — to help them as the company grows?

3\. What is the near term vision for the company? 1yr/5yr?

4\. What resources are available for professional development for
managers/directors?

5\. At $CURRENT_COMPANY, the company is serious about reviews upwards — as a
manager, my direct reports are consulted in a formal process at review time.
Is there a similar process at $POTENTIAL_EMPLOYER?

6\. What is the cadence and process for reviews?

~~~
corey_moncure
What does "diversity" mean in your question #1 and how is it relevant to
successful outcomes?

~~~
jfb
Demographic diversity, diversity of backgrounds, diversity of experience.
Monocultures are actively destructive of successful outcomes, and lead to
miserable working environments. The question is asked open-ended in that
fashion because I want to discover what a potential employer thinks is
important.

~~~
james_s_tayler
What about if you're a hiring manager for a software company in Japan or
Korea?

~~~
jfb
I'll cross that bridge if I come to it.

------
kostarelo
I wrote this[1] a few years ago. Since then I changed these questions quite a
lot (I need to write a new post) but the concept is still the same. Whenever
I'm going to interviews I never go as I will be the interviewee.

For quick reference:

\- What will my job be? At first and after few months?

\- What is your work policy for employees?

\- Software/hardware that I will get?

\- Can I participate on/run side projects?

\- Is there a budget for conferences, further education, bonus?

\- What is the history of this company and how do you see the future?

\- Will you measure my productivity and how?

[1]: [https://kostasbariotis.com/interviewer-vs-
interviewee/](https://kostasbariotis.com/interviewer-vs-interviewee/)

------
2rsf
Hmmm, I did discuss some of the technical questions from the list and I have
to admit that it's not easy to make a decision based on them. It's a great
start for discussions, and definitely something to consider but your time is
limited, the other side will beautify the answer, the same as you do, and you
might end up in another totally different team than this of your interviewer.

Remember that things tend to be fluid, re-organizations happens often, having
a bug tracking system doesn't make bug handling efficient and CI/CD doesn't
mean your time to deliver is necessarily short.

~~~
viraptor
Completely agree. Would you mind if I stole your second paragraph? (Or could
you submit it as a pr?)

Those are definitely seeds of conversations rather than something you can 100%
rely on. But if you have doubts about the organisation and then hear "no bug
tracking, we don't need it" without explanation, then something's definitely
fishy. That's one of the red-flag questions. Then again if they don't but have
an explanation, maybe there's something really interesting behind it.

~~~
2rsf
Sure no problem, go ahead and steal it

------
wonderwonder
"Does the company provide hardware and what's the refresh schedule?" \- I
really wish I had thought to ask this on my first remote job. Everyone is
surprised when I show up at company meetings and don't have a laptop I can
develop on. I work on a desktop, if you want me to have a laptop capable of
running windows docker at the meeting we have every 6 months on the other side
of the country, buy me one.

------
jupiter90000
Ask a question like "Given a non-negative integer numRows, generate the first
numRows of Pascal's triangle." If they can't answer without using Google I end
the interview as they didn't pass the round. :-)

~~~
kempbellt
I'm not sure if this is satire. Sounds like it may be, considering your emoji.

Getting asked questions like this, in most cases, is enough for me to end the
interview. I don't want people who can cite off memorized answers to random
questions. I want driven people who are excited to learn what needs to be
learned in order to push the company forward and make work a fun place to be.
Confident people can learn to solve difficult problems on the fly, with ease.
This is more valuable than being able to recite a textbook answer during an
interview.

One of my favorite interviews of all times:

Interviewer: "Hello. I have your resumé in front of me. I am going to ask you
a bunch of questions in rapid succession, and I just want yes and no answers.
Are you ready?"

Me: "No."

Interviewer: "Excuse me?"

Me: _click_

------
rajacombinator
I tried this in my last round of interviews. It is very difficult to get any
meaningful information from this process, because, just like candidates,
interviewers are incentivized to not tell the full truth. Except in the worst
cases when the interviewer just dgaf, they can’t really share negative
information for fear of reprisal. (And it doesn’t benefit them either.) Your
best bet is to ask a question that allows them to answer honestly, without
sounding like they are answering negatively. The problem is it’s hard to come
up with such questions.

~~~
megous
"If I was hypothetically a person that likes to refactor/maintain confusingly
tangled mess of a code, would I enjoy working here?" :D

------
mttyng
> What's the on-call plan/schedule? (what's the pay for standby and call-out)

I’ve never been in a position where we were paid for on-call (i.e. fix prod at
2am) work. Is that not typical?

~~~
viraptor
I've never been in a position where I've _not_ been paid for each call out.
(And only one place which didn't pay for standby)

~~~
mttyng
Whoa.

That gives me pause. It makes absolute sense, but it never occurred to me.

~~~
bri3d
When I have seen this done, the amount is often inconsequential in relation to
the amount of effort to be on-call. I don't love this incentive structure
because the cost of being on-call is somewhat fixed up front. Needing to avoid
being out of page coverage / availability and having a computer available is a
high cost paid by the employee regardless of actual page-out workload. Paying
for standby certainly helps, but I haven't seen standby pay match well with
the perceived effort. Maybe some companies do this right, but higher
negotiated upfront pay has appeared more effective in my experience.

------
dredmorbius
Meta-comment: I'm increasingly suspecting that it's not tech hiring that's
broken, but the tech labour model.

Specialisation is high, training is long, skillsets frequently expire quickly
(at least relative to careers / education), certification lags worse than
training does, in many instances, and information aquisition costs on _both_
sides of the hiring line are high: employers have difficulty in finding
good/suitable candidates, candidates have difficulty in finding and/or
assessing good employment fits.

Rewards _once on a gig_ are highly disproportionate, with some high-paying
companies, a strong gamble on equity (usually fails to pay off, very rarely
does), and increasingly draconian employment terms and contracts (again,
California law is exceptional, but as labour gets priced and simply slotted
out by housing prices and unavailability, other centres with far less
favourable working conditions may gain traction).

The idea of working as an individual at a given company for 18-36 months, then
moving on (typical job tenancy) seems highly inefficient.

Chunking labour into a force that can be deployed might address that. Less a
union than a guild, perhaps. Structuring that (and accommodating various
state's and nation's employment and organisation laws) is an interesting
challenge.

------
sabujp
At a faang you'll never get the chance to ask the team you're joining this
many questions directly, unfortunately it's also really heavily dependent on
the team and manager. HR will usually give you some of these answers and will
often stretch the truth except for benefits. Even then expect things like
promotion processes to evolve, many things are never statically configured,
even down to the small perks you receive every day. So here's the #1 question
you need to ask, esp. at large companies:

1) How long has the team/project I'll be joining been around?

Are you joining a team that's in maintenance mode or are they projects other
than just refactoring/simplifying or migrating code to the latest and greatest
<programming language/stack(cloud)/jdk version/whatever>. As an eng and even
manager you _really_ want to join very young teams and large teams >= 6 people
(is the company serious about this project? burn rate > 1 million year). That
gives you most runaway to develop something new and then brag about all the
features you landed at promotion. Most large companies give fledgling teams
2-3 years to become viable. Try to stay away away from teams that have been
around for a long time unless it's your area of expertise or you're excited
about the project/work.

2) What's the churn rate? Who's the oldest eng. team member (in terms of how
long they've been on the team of course) and was the person promoted while
working on the project? The higher the level this person is on the team the
easier it will be for you to get promoted.

------
exabrial
I'd love to ask, "Why do people quit?" during an interview, but can't think of
a way to phrase it without sounding accusational or pretentious.

~~~
CPLX
I think asking something like “when people don’t work out and end up leaving
the company what are some of the typical causes of that mismatch?” wouldn’t
raise a red flag.

~~~
exabrial
That gives the interviewer a reason not to say 'well we messed up'

------
dustinmoris
I hate these typical questions which hiring managers or candidates ask each
other with no real meaning behind.

E.g. "how do you use source control"?

What is the intention of this question. What value do I gain from this
question? It implies that I have a specific way of interacting with source
control in mind and if they don't follow the say way then I'm unhappy or what?

Interviews take such a long time, I am of the opinion that I only want to ask
questions which genuinly help me later to make a decision.

e.g. instead of "what tech do you usually use?" I'd ask "I've been recently
playing with X and think it's a brilliant use case for doing Y. If I were on
your team and I'd want to do Y with X, would that be an option, or what's the
protocol in tech decisions in your team?"

With a concrete question like this the interviewer has to explain to me how
they _actually_ decide on tech and give me a more or less yes/no answer to
whether what I want would be possible. I find this a lot better than a generic
tech question and then get bombarded with a ton of buzz words which don't
really say much about how open the tech teams are to picking their own tools
for the job, etc.

------
weliketocode
The phrase 'hiring is broken' seems to have become synonymous with companies
improperly judging candidates.

BUT! This problem pales in comparison to the difficulty involved for
candidates trying to judge companies.

Now, I won't go as far as some of the other posters here and point to rampant
deceit. However, interviewers will generally try to be positive, and it's very
difficult for an interviewer to say "don't work here".

------
dredmorbius
What's your disaster recovery plan?

What circumstances does it cover?

What is your threat model?

(Depending on response, address missing elements: external threats, natural
disasters, power out, hardware failure, fumbling fingers, network-based
attacks, insider threats, APTs. Acknowledging _and not further addressing_
some particular threat is acceptable, ignoring it completely is not.)

How frequently do you drill for threats / failures? Practices such as
Netflix's "chaos monkey" are close to best of class. Not at all is
unfortunately the norm. Here I'd _like_ to see some positive answer, but a
widened eyes "oh, we should do that" would be encouraging, Dismissal would be
many red flags. People respond to disasters according to their training and
drilling, and failure to do either leads to poor response.

What is your professional development process? Name specific programmes /
practices for entry-level to senior staff.

"What's a really good day?"

"What's a really bad day?"

Who's been promoted recently? Why?

What reasons have you had for making staff redundant?

What reasons have staff had for leaving?

------
destitude
Has anyone tried to get the company they are interviewing for to provide
written and signed answers to any of their questions relating to the company
or job? Maybe even have ramifications if what was written turns out not to be
true? Seems like this is the only way to keep companies from falsifying
everything they say just to get a hire.

------
PorterDuff
So, am I actually going to start laying down track for this new product you
hired me to do? or are you going to kidnap me to work on legacy software
emergency patches the second I walk in the door?

An invaluable question if honestly answered.

------
donretag
For companies that offer "unlimited" PTO, it is good to ask what is the
average number of days actually taken off by employees. Are multi-week
vacations doable? Have vacations ever been denied (happened to me)?

------
dnl_pozzobon
I'm slightly bothered by the "reverse-interview" concept. To me interviews
should be bidirectional you are there to find out about the company as much as
they are there to find out about you. It should be treated as the starting
phases of a negotiation where you gain information about the value of the
asset you are going to acquire.

I'm certainly happy that viraptor shared this valuable resource, don't get me
wrong, every little step in the right direction is a good thing. I simply
would have liked it to have a better name in order to convey a different
message.

~~~
AmericanChopper
Interviews already are bidirectional, even if the interviewer thinks they’re
not. If you’re so keen for the job that you don’t ask any questions, then you
look a) desperate and b) like you’re trying to bs your way through the
interview, which isn’t great. My only objection to these questions is a some
of them are essentially negotiating the terms of employment, which isn’t
appropriate for most interviews.

------
docker_up
One of the most important questions:

What is the attrition rate for the manager and for the company in general. If
a manager has high attrition rate, that's definitely a red flag.

~~~
samirm
wdym by attrition rate?

------
kempbellt
Why should I work here?

It's a forward question, but your time is valuable. If you are going to spend
a large chunk of your foreseeable future working at a company, they should
have a good answer to this question. If they hop around all awkwardly while
trying to come up with an answer - next. I want to work with people who are
excited by the work they do. Plain and simple.

Always remember, the interview goes both ways. Be sure to interview the
interviewer.

------
longcommonname
How often do you load to production? What's a project here you are most proud
of? What was your last prod issue, how was it observed, how long to
resolution, what changes did you implent to help going forward?

These are sre focused, the first one indicates if sres are toil driven or
overloaded.

The second shows that you have agency as a sre and can have a positive impact.

The third goes into their culture around mistakes, monitoring and on call.

------
okaleniuk
I think, the "source control question" comes from the Joel Test which is 19
years old. Almost every company uses source control now so it doesn't make as
much sense.

A better question would be "why do you use [the source control they use]". The
answer, if coming from a knowing person, may tell you quite a lot about how
the technical decisions are taken in the company.

~~~
mcv
There was definitely a time when that was an important question, because the
answer could be "CVS", "nothing" or even "what is that?". Nowadays the answer
is practically always "git".

~~~
okaleniuk
Indeed. But why git? I worked for 3 companies that adopted git for completely
different reasons.

The first was open sourcing parts of their code so they just started using
GitHub. Makes sense.

The second used to work with Subversion, and they stayed with it. The process
was built around having one and only one server with all the CI, and the
hooks, and the locks. Git was used with the SVN gate purely for developers'
convenience. Makes sense.

The third one was on TFS, and they couldn't quite align their process with it.
So they thought "our process is a mess so let's do git". This is a red flag.
If you can't get your process straight with relatively simple tool, some more
sophisticated tool will (and it did) only make it worse.

~~~
mcv
> _" why git?"_

Honestly? Because it's become accepted as the industry standard. People who
need to make the decision without having knowledge about the topic just go
with whatever everybody else is doing. In the past, that used to be whatever
IBM was offering, then whatever Microsoft was offering. In that respect, git
is a lot better. It's flexible enough to adapt to different kinds of
workflows, at least.

------
SamuelAdams
I'd like to see a section specific to large projects. It's not uncommon for
companies to hire for specific projects, especially in the contracting world.
ERP, SAP, and other projects come to mind.

Something I wish I asked during my last big interview: Do you have a project
schedule? Can you show that to me?

If there is no schedule, or a very ambiguous one, that's a big red flag.

------
disordinary
In the past when I was unsure I've asked to just have a candid chat outside of
the office with my prospective co-workers.

Worked well.

------
alfiedotwtf
For early startups, these are important:

    
    
        - Are you profitable
        - If not, how long is your runway

~~~
lysium
I did that. Turns out, things change fast. (Or the answer was not truthful? I
don't know.)

~~~
jfb
Sometimes, it's both!

------
ensiferum
Let's be honest, most developers are not in capable of performing at
interviews at such a level that they can actually get to "choose" where they
want to work. They get one offer out of a round of interviews and that's and
you either take it or leave it.

------
oe
I created a short questionnaire with TypeForm that asks some of these
questions and linked it to my LinkedIn profile. Now any recruiter either
answers ten or so qualifying questions or skips the questionnaire and goes
straight to trash for not even reading my profile.

------
MichaelMoser123
'how do you know that somebody has done a good job at your company' and follow
up questions on what kind of processes they have: in build automation and CI /
bug database etc / are unit tests required for fixes? Do you do integration
tests?

------
jeygeethan
"Definitely don't try to ask everything from the list."

^ I wouldn't agree to this. If the interviewer can ask many questions about my
working style, why can't I ask the same about the company with whom I am going
to spend the most of my daylight with?

~~~
viraptor
It's more about "choose what's important to you and respect each other's
time". Not all questions will apply to a company. Many of them you can answer
by reading company's website/blog, maybe looking at public repositories.

If you ask something that shows you did no research or don't understand the
role description at all, that's actually going to count against you later.
Same for holding someone busy with simple questions if you had a scheduled
interview slot.

------
reubeniv
I normally ask what opportunities for growth exist, eg training/certs/online
courses etc, and what they like about the company, can normally tell if they
like the job/you by how enthusiastic they answer or whether it comes across as
scripted

------
peterwwillis
OP: I am too lazy to file a PR, but here are some of my questions, feel free
to use as you wish:
[https://pastebin.com/7ztvPwnY](https://pastebin.com/7ztvPwnY)

------
Wildgoose
I usually like asking what their staff turnover is like.

It was very telling many years ago when I was told "very low, almost non-
existent" and then promptly learned from my new colleagues that it was
extremely high....

~~~
muttled
I wonder if you could ask something like "Do you have going away parties for
departing employees?" Can be very telling.

------
bcyng
Now that I’m the interviewer, I think it’s better to not ask questions than
ask a question you don’t really want the answer for. Most questions I get
asked by interviewees lower the impression I get of them.

------
k__
Pro tip: Get the stuff that is important to you into the contract!

------
testing_aws
* how many aws account do you currently run across your entire company?

* how much time does it take to approve/create certificates?

* how many engineers quit within first year of joining company?

------
CalChris
There is a question about funding. So I'll assume the company is a startup at
some stage. But I'm surprised there aren't any questions about stock.

~~~
viraptor
Actually it wasn't supposed to be about a startup only. Established companies
also grow through external funding, whether it's a loan, partnership, selling
shares, or something else. Each of those may change how the company works and
whether you're comfortable working that way.

~~~
CalChris
Not only. But if you’re going to ask about runway then some intelligent
questions about stock are in order.

------
Balanceinfinity
When was your last vacation? Where did you go?

When was the last time you thought about changing jobs? Why?

When you joined this company, what were your goals? How many of them have you
met?

------
agumonkey
I asked about turnover on the last one, recruiter wasn't at ease. Is it a lack
of tact on my side or were they hiding something ?

------
alkonaut
My 2 favorites:

\- how many quit in the last 3 years (followed by ”why so many” or ”why so
few”)

And

\- can I sit with someone that shows me some code I’ll be working on?

------
worldexplorer
Data science version of this is highly required and must be asked with every
company one is supposed to join.

~~~
viraptor
I'm not familiar with that environment, but if you have specific questions -
there's always space for more sections :-)

------
matneyx
I -just- started compiling my own list as I head back out to find a new job.
This will be so helpful!

------
carapace
"Can I talk to the last dev to work on this?"

"What happened to the last dev to work on this?"

------
wodenokoto
> Is there a support / marketing / other call-heavy team close to my new team?

What does that mean?

~~~
smashface
I assume the author meant that since those teams will be speaking a lot to
people as part of their daily work they add a lot of ambient noise to a
workplace. That could matter to some people in open office plans or cube farms
where you can't separate yourself from that noise.

~~~
viraptor
That's it. "Is the office loud" is subjective. "Is there a team handling calls
a few metres away" has a simple objective answer... usually.

------
waynesonfire
it's insufficient to know the questions. to gauge whether a company is the
right fit, you must understand what it is that you're looking for. this is a
culmination of past experiences and lessons learned. the questions will
follow.

------
destitude
What affects does it have on a company to not hire ANY junior level
developers?

~~~
viraptor
One effect I'm familiar with: lack of documentation. Everybody is experienced
with the system, everybody knows how things work... until they don't. Having
someone around to ask the simplest questions and prompt for explanations is
very healthy.

Another is that people with lots of experience know and rely on
straightforward, correct, reasonable solutions. It sometimes takes a someone
new to say "why don't we try X?".

Finally, sometimes there's just work to do, not new things to figure out. If
everybody is senior but lots of work is pretty basic, at some point they'll
get bored and leave.

------
dobleboble
What are the hardware specifications of the average developer workstation?

------
sohodlers
Do you pay for this job?

------
apocalyptic0n3
One thing to note with these is that they seem to target companies/jobs where
you will work on a single product/suite of products. A lot of these questions
would be out of place in many agencies or the interviewers would not have
answers or the answers would just not be as good as you would expect from a
more focused team. Of note:

\- What does the onboarding look like?

In large part because of how rapid development is in agencies, how often you
change projects, and how small agencies tend to be, onboarding is often non-
existent beyond showing you the software they use and showing you how to set
up your Vagrant or Docker. Most of it is on an as-needed basis and you'll be
given the information you need for each project you work on, thanks in large
part to how ad hoc each job can be. I've experienced this myself at all three
agencies I've worked at, I have friends at two others who say the same thing,
and it's what I was told to expect in school.

\- How do you test code?

This will almost always be "put a dump in the code and see what's wrong".
Agencies don't often unit test and because of how often they switch projects,
having a consistent debugging environment is often more trouble than it's
worth. You should still ask this, just don't expect the greatest answer.

\- How do you integrate and deploy changes? Is it CI/CD?

Due to the quantity of projects, this will often be "no" unless the agency
primarily focuses on larger, months/years-long projects. For the most part,
clients don't want to the time it takes to pay for automated tests/deployments
and often don't host with you anyway, so it's usually either "run a git pull
and compile assets" or "package the code in a zip and send via Dropbox".

\- How do you prepare for disaster recovery?

Disaster recovery is often an after thought at agencies. Usually the disaster
recovery is "spend a few days restoring backups and eat the costs". Unless you
are interviewing for a security or senior position, this question doesn't
really make sense to ask at an agency anyway as you are unlikely to be
involved in any recovery.

\- How quickly can you respond to security issues in the code or dependencies?

Because everything is paid for by the clients, if they don't pay for it, they
don't get it. Don't expect much more of a response from your Agency
interviewer. If you get an intricate response, I would suspect it's
exaggerated. There are exceptions, but agencies don't make money making sure
the sites and apps they build are up to date, unless the clients want them to
be (and most clients do not see the value in it)

\- What's the product/service schedule? (n-weekly releases / continuous
deployment / multiple release streams / ...)

Again due to how many projects you work on regularly, this may not get a good
response. Maybe a "Our Wordpress sites take 2-3 weeks to build, 1 week to test
and fix, and 1 week for client review" type response, but anything more
standardized than that likely isn't happening.

\- What are some ongoing challenges the team is experiencing that you are yet
to resolve?

This one also likely won't get much of a response due to how many projects
there are and given that most of the team is working on different things than
their neighbor.

\- What's the promotion process? How are requirements / expectations
communicated? \- Is there a separate tech and management career path?

Agency structures are generally really flat. 1 guy at top, maybe a few seniors
below him, then everyone else (but everyone, including the seniors, report to
the 1 guy at top). Don't expect promotions, but raises will happen regularly.
You can ask this one, but you'll probably be more interested to hear when/what
to expect from your raises (agencies are often generous in this respect)

\- Are there any company-wide resources for learning available, like ebooks
subscriptions, or online courses?

Regardless of company type, know that this will depend entirely on company
size. If you're interviewing with a 300 employee company, you should expect
it. If it's a 10-40 person company, you probably shouldn't and it may not be
worth asking and may make the interviewers think you're looking for something
they aren't providing.

\- Can I contribute to FOSS projects? Are there any approvals needed?

This is a GREAT question to ask during the interview if you are hoping to work
on FOSS. Agency rules on this vary greatly and it's one I personally like
hearing from candidates.

\- Are there any non-compete or non-disclosure agreements I'll be asked to
sign?

Another great one to ask simply because you will work on so many different
projects from so many different clients from so many different industries. My
previous employer tried to get me to sign one saying I wouldn't work with any
competitor of their customers for 3 years after I left. That would have killed
my ability to find a job at another agency afterward. It was part of the
reason I quit there. My current agency is basically "Don't talk about
specifics that may be confidential during development, don't steal our
customers after you leave" which is more reasonable and acceptable.

\- Are you profitable? (+ the other financial questions)

If your interviewers are developers at an agency who don't also own the
company, they likely will not know any financials specifics

\- Remote Work

If this is important to you, make sure to ask about it in the interview. It
varies greatly from agency to agency. I interviewed at a place that only
expected you be in the office once a week and work from home 4 days a week. My
current place prefers if you keep the remote work to a few days a month at
most.

------
acollins1331
Interviewing the interviewer has been THE best way to get the job. It just
oozes a confidence that you already know you're good enough to get the job,
and you're trying to figure out if they are good enough for YOU. Figure out
questions before hand that describe the type of good working environments or
fixes for bad ones that you've had in the past. The interviewer will quickly
shift and try to sell the position to you (harder than normal). It sounds
silly, and like something they'd probably be used to by now, but in every case
I've done this it's landed me an offer. This is coming from someone who needs
to interview well because my degree/experience doesn't usually perfectly line
up to the jobs I'm applying for.

~~~
theamk
At my job, we have "do you have any questions for us" part as a standard part
of every interview -- and my experience shows that most people always have at
least one question.

~~~
pm215
I suspect most candidates have at least one question because it's pretty
widely known that many employers will ask "do you have any questions for us"
at the end of an interview, and so will have prepared something that makes
them sound interested in the employer in some way, even if they don't
necessarily actually care that much about the answer. (For instance the advice
on [https://www.wikijob.co.uk/content/interview-
advice/interview...](https://www.wikijob.co.uk/content/interview-
advice/interview-questions/questions-ask-your-interviewer/) suggests "Have two
or three interesting and intelligent questions prepared before the interview,
to show that you are interested in the job and eager to find out more" etc.)

~~~
bradlys
I'll give my anecdote on this:

When I used to not have any questions after the interview - I got rejected
what felt like a weirdly high amount and definitely a weird tone from the
interviewer.

When I started asking questions - the interviewer seemed to have a much more
positive outlook on me and my acceptance rate went up.

I've interviewed a lot and there are people you have to ask questions to or
else they will reject you.

~~~
ramzyo
As an interviewer and hiring manager, a candidate not asking questions
indicates a lack of interest in the company/role. I appreciate when a
candidate interviews me about the role, the team and the company. It
demonstrates a desire to take advantage of an opportunity to gather more
information about whether this is the right opportunity for them.

------
sectorcleaar
I have a similar problem about the question "mention 5 advantages in you and 5
deficiencies in you".

