We've all gotten to that point at the end of an interview when it comes your turn to ask the questions. We've all probably blanked in the stress of the moment, fumbled a question about the free snacks, and ended up in a job we regretted because we didn't know what to ask. Here's help.
This is a list of things to ask a potential employer when you're interviewing for a technology job. It's compiled from books, the web, contributors, and personal experience. Asking good questions will not only give you a better idea of what a company is like, but they will respect you for digging (if they don't -- run!).
Some questions are just for information and have no "correct" answer ("What's the makeup of your team?"). Most follow generally settled wisdom ("Do you have unit tests?"). A few have opinionated or controversial answers ("Could your manager step in and do your job?"). If you don't like a question, just ignore it; feel free to submit an alternative.
The list is in YAML format so it's human- and machine-readable;
you can filter the questions for the company, position, or interviewer;
and sort by priority. It's also easy to merge in your own questions or have domain-specific "question packs."
pri) are a rough sorting of importance from 1 (high) to 3 (low); the default is 3.
Don't get too worked up over priority; it's easy to change them to suit your preference.
Contributions welcome -- add your question to the bottom and submit a PR, or just make a new issue with your question. Evidence- or consensus-based questions with a link to references are preferred, but it is recognized that hiring is still a squishy subject. Standard questions like salary and benefits are not included (but of course you should still ask them!).
Before an interview, go through the questions, pick out the ones you want to ask, and order them by importance to you.
I like to print them out, without the answers, with space under each question to write in as many answers as there will
validate.py will convert your YAML to JSON, see
filter.sh for basic filter and sort, and
to get basic HTML.
When it comes time for you to ask questions (typically at the end of the interview), take out your questions and start by saying something like, "I have a bunch of questions here, so I'll just go down the list and you can stop me when you have to go." Many interviewers are not accustomed to being barraged with questions, and you want to respect their time. Typically not much time is allotted for your questions, so you want to move quickly and cover as many questions as possible, but still leave psychological space for the interviewer to reflect, open up, and give candid answers. You want it to feel like a conversation, rather than a reverse interview. That is an art. Practice by interviewing with companies where you don't really care if they hire you or not.
Most questions should be asked to every interviewer (of the appropriate type), so you can get a meaningful sample of answers. Asking six people "How many hours did you work last week?" will give you a better picture than asking one person "How many hours a week did you work for the last six weeks?" This technique borrows from survey methodology to avoid faulty memories and all sorts of memory biases.
Interviewers are often curious about someone so curious; they may ask why you asked a particular question, or what answer you were looking for; feel free to share and send them here.
After the interviews, if you feel you didn't get enough complete answers out of your interviewers, don't be afraid to come back for more. You can say something like, "I'm really interested in the company and position, and I think we both want to make sure it's a great match. I'd like to come back and spend a little more time getting to know each other." Many companies worry about making the interview process too long and fret about not having enough information about candidates; showing you're interested and willing to invest more time can by itself give you an advantage. A great time to visit is after they've made an offer but before you accept. Getting to know the people may be more important than any questions you could ask. Another good source of information is to track down former employees and ask them why they left.
You may choose to review the answers and assign a score to each question, weight it by how important the question is to you, and compute a score for the company. Or you could compute a score for several dimensions and graph it on a radar chart to summarize the company's strengths and weaknesses. Feel free to share what you come up with.
Edit the appropriate
.yml file; copy an existing
q, paste it at the bottom, and edit. Submit a pull request and it
will automatically be validated.
You can test your changes locally with something like
$ ./validate.py schema.json < questions.yml
If it validates, it outputs a JSON list of question objects; if not, it should give you a more-or-less helpful message.
You will need Python 3 with the PyYAML, jsonschema, and jinja2 packages installed.
python3 -m pip install -r requirements.txt
should do it.
Tools for filtering and ordering questions, converting to various formats, pretty-printing, etc. would be very welcome. Question files for specific industries, roles, stacks, etc. are also welcome.
Questions are key-value pairs; all are optional except the question. Most values are strings or lists of strings.
q: The question.
a: An answer, if appropriate. Keep it brief but explain why a particular answer is important when looking for a job.
followup: Question(s) to ask after the main
q; generally contingent on the answer. String or list.
tags: The topic(s) of the question. List of strings. Valid values are in the top-level document
[process, culture, people, tech, management, hiring, issues].
pri: Integer priority used to order questions so you can ask the important ones first. 1 (highest) to 3 (lowest). Defaults to lowest.
ref: Reference the source of the question or desired answer. URL or list of URLs.
who: Type of person to ask the question to, so you can tailor the questions to the interviewer. List of strings. Valid values are in the top-level document
[engineer, manager, exec, hr, other]. Missing means appropriate for anyone.
where: Type of company for which the question is appropriate. Valid values are in the top-level document
[startup, bigco]. Missing means appropriate for most companies.
There is a JSON Schema against which questions are validated.
Questions to ask a potential tech employer is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.