Data

Tools

Indexes

Applications

Experiments

Awesome

An open API service indexing awesome lists of open source software.

https://github.com/nir0s/interview-questions


https://github.com/nir0s/interview-questions

Last synced: 2 months ago
JSON representation

Awesome Lists containing this project

README 

        
# Interview Questions



This is a list of questions I would ask or would like to have been asked for in a job interview for a development or operations role.



The idea is to provide as much background for each question as possible to justify it being asked and to provide blog posts, articles or any other source of information to base it upon.



The list comprises of sections, each related to a different area.



If you're instead looking for technical interview questions, see https://github.com/MaximAbramchuck/awesome-interview-questions



## Before you read



* Some questions might not be relevant to some people/companies.

* Each question is indicative of something. That certainly does not mean that it fully proves something but rather that it confirms it.

* Try not to bombard with questions but rather ignite a conversation. It makes people less defensive.

* Following up on the previous point, asking too many questions exhausts the interviewer so make sure you remove unnecessary questions from your pool. Additionally, a good idea would probably be to try and form a way of asking some of the questions in a manner that would solicit the interviewer to answer other questions also. For example, asking "Do you conduct code reviews" can probably lead to talking about testing methodologies, the VCS system used, coding standards and the process of shipping code to production, without explicitly asking for each of these.

* The main guidelines for any job in our space (and everywhere else, really), as I see it, would be to provide an employee, as per Dan Pink, with [Autonomy, Mastery and Purpose](https://goo.gl/5ZZocQ). As such, the questions should mainly aim towards understanding whether these are provided by the company. Obviously, some questions are helper questions. Asking the interviewer how long he's been with the company helps you understand whether he has enough knowledge to share but has no direct relationship to any of the three.



# Questions



## First, for the interviewer



Q: How long have you been with the company? 



Explanation: Indicative of whether the level of knowledge the interviewer has on the company is sufficient and they can answer your questions in a sufficient manner.



## Company level



Q: What is the company's mission statement? 



Explanation: This is practically like asking "What is the problem the company is trying to solve?". A company without a mission statement is a dangerous thing. If the interviewer seems confused, it's indicative of lack of a declared company-wide purpose.



Q: What is the company's yearly revenue? 



Explanation: Indicative of delivery in relation to company side.



* How many paying customers does the company have? Indicative of adoption

* How many people work in the company and what's the growth rate? Indicative of recruiting habits, hypergrowth, etc..

* How many levels of hierarchy does the company hold? Indicative of how managerial the company is. Too many levels of hierarchy might indicate redundancy.

* Would is the single largest problem the team is facing and would I be in a position to help solve it?

* What's the employee performance review process like and how often is it done?

* What don't you like about working here? What would you change?

* What do you like about working here?

* What are the qualities of successful managers in the company?

* Where will the company be in 5 years?

* Does the company track working hours? Indicative of old-school approaches.



### Communication



* How do people communicate with one another? Slack, email? Is everyone using the same medium?

* How do you communicate with remote employees?

* How are requirements presented?



### Meetings



* Do you have a defined meetings culture?

* Do you put a cap on meeting time?

* Do people have to provide agendas? Does a meeting end with defined action items?

* Is it acceptable to decline meetings if I don't think I can contribute to them?



## Team level



* How are initiatives taken? If I want to take complete ownership of an idea, is that possible? Indicative of autonomous approach.

* What is the goal of the team I will be joining?

* Do you have frequent 1:1 meetings with team members?

* Are people encouraged to admit mistakes? Indicative of culture of improvement rather than fear.

* What's your feedback process on mistakes? Indicative of the health of the improvement process.

* Sprints, Scrums, etc? Do you hold sprint reviews? Do you do sprint planning? Indicative of a healthy development process.

* How do you deal with someone who doesn't deliver?

* What's a typical day like for a team member?

* Who are the people I will be working with?

* Do you do code reviews? What's the process of merging something to master?

* What's the macro vs. micro management balance?

* What's the level of experience in the team i'll be joining?



## Supervisor level



* Details about the direct supervisor



## Job level



* What am I hired to do?

* Do I need any training? How will I be trained?

* Is it possible to work from home?

* What is the compensation plan?

* Is there a relocation option? If so, what is its policy?

* Do you help advance careers (by contributing to open-source projects, going to conferences both domestic and abroad, writing blog posts, etc..)

* Does the job require travelling? How many times a year and for how long?

* Who do I report to?

* ... is my current experience. If I left here in 3-5 years, what would I have gained?

* What skills would make an ideal candidate? Indicative of whether you're the right person for the job.

* Are there accepted working hours?

* Are there promotion opportunities?

* What are the expected availability levels? 24/7? etc..



## Technical level



* What's your stack like? An obsolete stack is indicative of fear of change or lack of architectural skills.

* What is the process of shipping code to production?

* What are your system's KPI's?

* Are there any coding standards?

* What's your testing methodology? unit+integration+system?

* How are architecture level changes accepted?

* Which version control method are you using? Indicative of old-school approach. The companies for which I've interviewed who were using SVN, rather than Git, for example, were also the ones who failed to atract me in other areas.



## Next steps



* When is the starting date for this position?

* What is the next step in the hiring process?

* When can I expect to hear back?

* Who can I ask additional questions?

* What can I help clarify that woud make hiring me an easy decision?



## Last



* I was wondering what your best moment so far at (company name here) was? (https://goo.gl/l0u2RT)