A list of developer questions to ask prospective employers

As someone who has recruited hundreds of candidates at this point I would urge caution with lists like this.

By all means read the list, but rather than trying to grind through as many of the questions as possible, try to use it as inspiration and think of what you're actually curious about and which might tip you over one way or the other if you're on the fence. It's far better to have a good conversation about 1 thing which might affect your decision than a superficial sprint through a bunch of topics you don't actually care that much about.

Secondly, consider that if you do well you are likely to have multiple rounds of interviews. Think about which questions are likely to be most enlightening when you ask each interviewer. Don't shy away from asking 2 people the same question if you think you'll get different perspectives. If you ask a peer engineer the diversity questions you may well get quite a different answer from asking the HR/recruiting person for instance (eg one might give you a cultural insight vs the other might just give you the policy/factual answer).

I once interviewed a candidate[1] who had printed off a whole list like this and insisted on grinding through the whole thing. It was weirdly offputting, but he was such a monster programmer that he was already a clear hire. It gave an insight into the thoroughness of his nature though and showed that he was absolutely perfect for the (critical) role we were hiring him for where mistakes were extremely costly.

[1] Hi Fluffy! If you see this I hope you're doing well.

I'm obviously cherry picking, but if an applicant asks me a series of questions akin to "what source control tool do you use and why" I'm going to begin doubting that this person can focus on actually shipping product. There's this whole scene of people who do performative, almost theatrical, quality programming but nigh on forgot how to actually ship features, and questions like those are a hint they might be in that camp.

EDIT: to add some context, i run a small startup, we need the whole team able to ship. I can imagine that in certain bureaucratic bigcorps, performatively obsessing on code/process quality can be useful, because the distance between the programmer and the customer/user is so long.

A lot of the comments in here are reacting to the large list of questions being very off-putting. There's a deeper issue here that we still don't have a good answer for: it is incredibly hard to tell what a company is like until you start working there, and asking questions either leads to very surface-level answers or just flat out catfishing candidates. Companies being transparent and detailed about how they operate is the exception.

The company gets to spend 3+ hours finding out information about a candidate, but the candidate has little option to discover company culture for themselves. They can snoop around on LinkedIn but this doesn't answer much about culture unless there is someone who is prolifically producing content inside the company. There's glassdoor which might answer part of it but generally the reviews there are extremely shallow and biased by the skills, mindset, and treatment of whoever wrote the review.

So what's the answer? I think "ask targeted questions" is fine as long as it is not "ask 100 general questions". I haven't seen a single article on the meta of how to pick what questions to ask or how to get past shallow answers. I also think the entire industry is performing pretty terrible in this space and we don't have a good answer for how to handle it that is common or even well-known. This leads to lost candidates or (intentionally or unintentionally) catfished candidates who will leave after joining.

Heya, I'm TwippedTech, the author of this repo.

Every few years somebody spots this and it goes viral on HN again, and I hear all the same complaints that people made the last few times around. I don't know how many disclaimers I have to put on the text to get people to stop whining about the wording of something, or the size of the list, or the implication they would draw from someone asking one of the questions. There's always dozens of "hiring managers" who swear they wouldn't hire anyone who asked things from this list (good, I wouldn't want to work for you anyway).

Every question on this list came from somebody's pain point, something that made their job uncomfortable. When a whole bunch of discomforts add up, it leads to an environment you can't stand working in. Nobody is going to reject a job over tabs vs spaces, but it CAN serve as a reminder to ask questions about their code linting and style requirements, and wow can there be surprises in there. You'd be surprised how quickly you can get annoyed when a company's style requirements clash with your natural habits, especially if there are other things making you dislike the job.

And please, I am begging people, notice that this repo is almost a decade old. I'd bet a whole lot of people reading HN today weren't even coding when I made the first draft of this list. There are questions in here that probably aren't relevant in today's startup culture, and those questions will seem very dated, but there's also still a lot of very old companies doing things in very old ways, and these questions can be important to have in mind when interviewing with them.

Just because you've never worked in anything but git doesn't mean that there aren't still tons of companies out there that never switched off of Subversion, or worse.

Personally, I also ask more questions about on-call:

- is there a SLO?

- what is the schedule? 24h is no go for me.

- is non-business hours on-call compensated (even when there are no pages)?

In particular, I strongly believe we (as profession) should push more the employers for the last point. Being oncall during weekend means I need to seriously adjust my plans; need to have corporate devices somewhere close, etc. In particular this also means I don't fully disconnect from work if I have to carry laptop/phone with me. This kind of stress slowly accrues long term. All in all: staying alert for oncall is some sort of work. A physical security guard gets paid for keeping an eye on things even when nothing happens; it's startling that so many devs don't.

I think most of these need to be up-leveled to being open ended like “tell me about your development process” or “describe my role in the organization”. Even then differing questions will be asked to various interviewers either with you guiding the conversation or asking in Q&A at the end. I mean, is your entire decision going to be made on GIT being used?

You should use this list if you don't want to be hired. Any applicant that expects an interviewer to spend the better part of a day or so on answering a laundry list of questions had better be unicorn grade themselves or they'll be looking at another interview shortly.

The reason is simple: an interviewer is trying to establish some level of rapport and to try to get a basic idea of whether you are going to be a good fit for the company and the team. If you are going to show up with this list you spell 'trouble' and you won't get to the 10th question before the interview is going to be terminated.

But best of luck if you try.

If you were to ask questions make sure they are in the ballpark of what is expected for an interview, deal parameters such as salary range, equity, any kind of vesting arrangement, transportation options, a chat with your future colleagues etc are all fair game and you should focus there.

If you do want all these questions answered you should approach them sideways, not frontally: ask for a contact within the team that you will be working with and try to establish some kind of rapport before dumping your payload, it will likely have much better results than to show up to an interview with such a detailed list.

I find that this list[0] is extremely geared towards a fairly specific style/culture/stack kind of thing.

Lots of companies will "fail" this list, and it could be a real missed opportunity.

SOURCE: I ran an organization that "failed" a good many of these, yet retained top-shelf C++ talent for decades.

[0] https://github.com/Twipped/InterviewThis#developer-coordinat...

Quite a lot of detailed questions but I think, over a few interviews, most would be easily covered without even resorting to just reading a huge list Maybe even check the ones off after each interview.

There is also something to keep in mind. The interviewer may also simply lie if they wish to retain you.

A few years ago I was told I could use a Mac but when I got there I found I could have a Mac on my desk but I could not use it for anything as it was not allowed to be connected to the corporate wifi. Even a brand new one.

The other one I have found in conflict is purchasing software. I wanted to use Datagrip as I used it extensively before. It was said that it would be no problem. Over the next year I asked once a month for fun and the answer was yes every time. Sometimes I was asked to provide the cost and details, which I did four times. Nothing ever eventuated and I simply kept paying for myself.

Did they lie? Maybe not but it was pretty disingenuous.

So I recruit ... A lot. If a candidate just ask canned questions or kind of not super relevant questions like this I might spot that as a red flag.

Also those questions are very developer centric, not company centric Ie. Is this environment good for me developer, which is ok but you need to balance it.

For example:

what is your current pain points in the company?

How do you think I could help your company if I join?

^^ it is a huge red flag if you get BS responses on those as a candidate. Every single company sucks or way or another and if they hire it should be to improve it.

Pretty amazing list. There's also funny questions: "tabs or spaces?" is in there.

Now that I have a family, I always ask: "when was the last time you worked weekends?" There's a question in the list "What hours does the team work?" but I feel that doesn't quite cover overwork.

There's a problem with GitHub lists that accept PRs. They accumulate over time. Almost nothing is removed. No one wants to remove someone else's contribution.

This list needs heavy editing, and some form of feedback mechanism by which those questions that perform best are weighted higher.

I can't imagine asking "how verbose is your logging?" in an interview as if that's a question that's germane to whether the position is a good mutual fit.

A few of these are good, but others remind me of that "How To Professionally Say..." list that was making the rounds a few months ago, which was actually a list of snarky, passive-aggressive and shockingly unprofessional phrases.

By all means, ask your interviewer good questions! But please don't say this:

  "Does your code review process promote empathy?"  

  "Tabs or spaces?" 

  "Does the company provide snacks and/or drinks?" 

Ugh.

When I was a junior engineer, I thought that the tools I used and the products I worked on mattered most. But now, after two decades, I can see that what actually mattered was the people I worked with. If you're interviewing, focus on the people you meet. Are they kind to you? If you had to correct a mistake of theirs, how do you think they would react? How do they interact with each other? Would you enjoy spending time with them? Do you feel like you might learn something from them?

Take these questions (from the article) and focus on the interpersonal parts:

* How do you estimate work?

* How often does your team interact with other teams?

* If we have a very successful year, what would that look like?

Some questions I would add:

* Can you tell me about someone who was promoted recently? Why were they promoted?

* Can you tell me about some feedback you gave someone? How did it help them?

My two most important questions don't appear to be on here.

"What has employee turnover looked like?" This is the biggest signal to me, a lot of businesses hire and are unable to retain anyone after the honeymoon period wears off. If you can't keep employees I'm not interested. They also can't really lie about this since once I join the team git blame is going to give away that they had lots of previous employees working on the project who are no longer here.

"What would my on call expectations be? Would you expect to reach me out of hours?" They cover monitoring and on call but not as directly as you need to. Devs may not have a explicit on call rotation, but many orgs have implicit on call expectations. Asking directly like this can make the implict explicit. I need to know this to set a price. "We expect you to jump in when there is an issue so we need to be able to reach you" is 24/7/365 on call in effect.

If you’ve been in the field long enough you can gauge a company simply by the tools they use and roles they hire for. They have vacancies for DevOps folks? Ok I know that the devs are not owning the full software development lifecycle and have no ownership of their products in production. Do they use Teamns and Azure DevOps? Ok it’s going to be a boring corp that dictates the tools which dev teams have to use from top down, because someone at the C level got a good deal for an entire Microsoft suite and now everyone is stuck with it. Do they only have devs working in a single programming language? Ok so they don’t really explore tech as curiously as they claim and don’t look for the best tool for the job. They make their work for their skills, rather than make their skills for the work they want to do.

There are many cues which you get from a company before you speak to an single person. I judge hard, because those cues never lied to me.

I want to find any red flags at the company, so I'll straight up ask my interviewer one or two of:

  - What is the most rewarding part of your job, and what is the most challenging/difficult part of your job?
  - If you could change one thing about your job/the company, what would it be?
  - Would you say it's easy or difficult working with your current team?
  - Are your corporate policies clear & does everyone know what they are?
  - Are there any major impediments to getting your job done?
  - Does your team/company have well-organized documentation?
  - Is it clear how to communicate with other teams?
  - Do you think management is doing a good job?
  - How much would you recommend working here?
  - Are there any major problems here I should know about?

If you’re good enough to ask these questions freely at interview without fear you should be applying for a more senior role.

For candidates, reading these questions are a great exercise and depending on where you are in your career, you need some of these.

In practice, that list has too many unanswerable questions (framed in a way that can only make the company or its team or its manager look bad).

I think this all come from our analytical and correctness bias, and maybe some late bound experimentation plus garbage collection of the details that needs adaptation are a more practical solution.

Feeling the vibe suddenly seems important.

> Windows, Mac or Linux? Do I get a choice?

Beware that if this is a hard-requirement for you, you might get "cheated" and or disappointed. They might tell you it's all fine that you use Linux, but then you go and see it's not linux-friendly at all as there's a shitload of things that keep breaking or you have to use a specific distro version, due to some required software or configurations the company requires you to use ...

I’ve been through many many interviews myself, but the toughest ones in each recruiting processes is the one where you have to speak to a CTO/VP of Engineering or even a CEO/Founder. Here’s an article that helped me out a bit with the last iinterview I’ve had: https://blog.nextonlabs.com/9-questions-to-ask-a-startup-ceo...

How many of these questions can be answered by the prospective hire before ever entering the interview process?

If you take this approach, using lists like this as a guideline, you might be able to find out a lot about the company before the interview, which is a good idea. It'll indicate to the interviewer that you're interested enough in the company to do solid background research, which is likely to be a plus.

The relative success of such background research (% of questions that can be answered, for example about testing, source control, company culture, etc.) will in itself tell you a lot about the company, i.e. if they're unusually secretive perhaps most of these questions won't be answerable before the interview. That might or might not be a red flag (Theranos was a rather secretive outfit, for example...).

Also, note that some of the questions are phrased in what some will interpret as an unnecessarily antagonistic manner, and some people will confuse directness with arrogance. Others will appreciate the straightforward approach. Figuring out who is which is a common problem.

The advice with this list should be: you can ask anything you want but not all of it. Pick a few topics that matter the most to you and not randomly. But definitely ask questions. Especially when you have concerns around the topics that those questions cover. You can also highlight your own skills by asking pointed questions about things that relate to those skills.

Also, maybe ask open questions rather than closed questions. Several questions on the list are very closed questions. Like what "version control system do you use?" They are not going to give you a lot of insight regardless of the answer and the answer is likely to be not very surprising.

That's also a good trick as an interviewer. Ask really broad and open questions and see what comes back. It's not about what you answer but how you answer. If I was interviewing, I'd bounce those questions back. So in case of the version control question, I'd ask some open question about your experience or opinion on that topic.

My girlfriend has been interviewing recently and she asks shops what their Joel score is. If they know, it's a good sign, and if they don't, it makes her look good dropping knowledge. The places she has been talking to went over their scores on the call, which surfaces details about the actual working conditions.

All it does is it shows we are still in employee driven market, hence the recession hasn't hit yet.

This is a very good question, but you should also dig a few why's into it: "What type of people are successful here? What type of people are not?"

I also like to ask: "what's the best thing about working here? followed up with what's the worst thing about working here" You typically get some insight based on how open they are to the last question.

Reading from the comments, I'm astounded that the recruiters seem to think interviewing for a job is a one-way street where only the employer should validate if the employee is a good fit for the employer.

I'm literally investing 40+ hours a week of my life into your company for at least the next 2 years and you think I won't vet you before accepting your offer?

You need a reality check.

> Does your team encourage the use of SOLID and DRY design principles to avoid cyclomatic complexity?

Whenever someone brings up SOLID in their resume or an interview I ask them to explain the L. So far it’s 0 for 3 this year.

In this case I would also ask them to define “cyclomatic complexity” in a way this question makes sense, because it’s only weakly correlated with either of those.

I'd propose that none of the answers to these questions matter. The follow-up question is what matters: "Is it working? And if not, what is the plan to correct it?"

You'll get far more insights into asking why and how they make their choices than just asking what their current decisions are.

My rule of thumb has been to stay close to the revenue so perhaps asking if you would be working on topline related projects or bottom line related project. Related is to ask what the top priorities are and to try to understand where your focus would be in relation to the top 3.

Unless you have the upper hand from the moment you walk in, I'd advise against machine gunning these questions in the interview.

Yes a lot of them are important, but you can get a lot of answers by the feel from the interview and the interviewers.

I'd recommend to be the guy that can help. Usually interviewers will come forward with what they're trying to fill, what they're lacking... Be that guy.

Most places I joined weren't all there in when it comes to all those questions and what they imply. When I join, I try to make the place better, to provide value. That means also raise their street value, by bringing modern techniques, modern thinking etc.

Sure, knowing what environment like windows or macos could be a deal breaker, but you can get that answer just by walking in, see what the interviewers are using and what's on the desks.

No jobs are perfect and like any relationship, it takes work on both sides. Dream jobs are pretty rare and chances are, you won't get offered one because someone has left it behind...

Some of these are the type of questions you should ask after given an offer and before accepting. Unfortunately the standard interview process does not allow much time for interviewees to ask in depth questions and expect in depth responses.

I'm surprised to see little about how products are managed/defined. PO/PM.

This list is too much. One can take inspiration from the list but ultimately you want answer to your own questions you have for the recruiters/companies.

If I recruited someone and they'd ask me all these questions I would look elsewhere.

If an applicant asked me these questions the answer would be no to all of them.

Do other organisations put that many limitations and control on their developers?

Is there any space for developers to take charge of their own projects and have project ownership?

I used this list recently: https://github.com/viraptor/reverse-interview

For codebase ask LOC. Ask them to run cloc on a repo and tell you what that code does for the business. That will tell you so much.

Hey, Everybody complaining about reading this whole list to your interviewer: please read the 2nd and 3rd paragraphs.

My top question right now: Can I use my own hardware & will you monitor me (time tracking, screenshots, etc.)?