
A List of Essential Questions to Ask During Technical Interviews - gravyboat
https://github.com/gravyboat/interviewee-questions
======
dalke
To make it clear, these are questions for the interviewee to ask the
interviewer.

They are also designed for an candidate in a job working with many other
developers, and deploying primarily web-based software in an IT-heavy
environment.

If you are hired as the sole software developer for a non-programming group,
then most of the questions make no sense. For example, I mostly work with
chemical research groups, where there is no mandatory code review as I am the
only developer, and where the deployment is to install to /usr/local/bin .

Also, '100% test coverage' is a meaningless goal. It's trivial to force 100%
coverage, and does that mean line or branch coverage? Coverage testing is a
way to find where you need more test, but it mustn't be the end goal.

~~~
preston4tw
Hey, thanks for taking a look. This is spot on. Most of the technical
questions are aimed at startups / software shops that are hiring for growth /
large enterprise companies with tons of IT. They become less relevant if
you're the sole IT guy in a non-software shop. There still are a number of
questions we feel are relevant to any position that are important to ask such
as health care provider, retirement fund, etc. If you have any suggestions for
questions to add we'd love to hear them. The removal of questions (ex. the
test coverage) we put more consideration into. I think questions like that are
valuable to the extent other people find it valuable. Certainly if no one
thinks test coverage is a good question to ask then we'd remove it. Thanks for
the feedback.

------
preston4tw
Hey, one of the authors here. While there is some prior art we (me and
gravyboat, the other author) felt that this is an improvement upon what's out
there, especially the part where it's collaborative with the community as a
GitHub repo. With HN hosting the monthly "Who is hiring" threads we'd like to
see more companies be more open about these things and realize that quality of
life for people in the technical line of work isn't just about what perks the
company provides, but also about how painless it is to be an individual
contributor.

It's a cliche that we all want to change the world, but there's a bit of truth
in it. If as an employee I have to fight against your ancient development
environment and painful deployment model to get my code changes into
production while being chained to a desk, I probably don't want to work at
your company.

If I would have known to have asked these questions I might not have had some
of the jobs I've held. My hope is that by sharing some of that experience the
junior people can avoid trial by fire in less than optimal work environments
by asking the right questions, and that table stakes for companies to attract
talent will be to have great answers to these questions.

