Company’s engineering blog reveals challenges and openness to share best practices. Company’s GitHub account shows quality standards.
That’s all I know before the interview. But the question “do you want to know something about the company” during an interview puzzles me.
The questions below unveil distinctive factors that may affect your choice whether to proceed with them or not.
Why? Answers to those questions come to you sooner or later when you join a company. And often you’re unable to change or handle that truth. Those questions can reveal the factors that make your job a breeze, or a nightmare. Knowing the answers helps you make a serious decision with more certainty.
If the salary motivates you most, those questions are NOT for you. But is it?
I wrote those questions from a Ruby developer standpoint. Languages don’t play such a big role those days, but YMMV. Operational, administrative, organizational and architectural questions still apply for companies using other platforms.
Those questions are dry. Make sure you understand why to ask the question and pros and cons of possible answers.
Psychological tests ask the same questions in different ways to detect a deviation in the answers.The questions below have similar interlinked traps that may reveal the real state of affairs.
Interviewee’s question time has limits. Make sure that the interviewer knows in advance that you have a fair amount of questions.
Ask what matters most to you.
How an idea of a change progresses towards a release to production?
Do you have an engineering blog?
Do you prefer “boring” time-proven or bleeding edge technologies?
What made you think I am a good fit?
What’s the size of the engineering department?
What roles or titles the engineering department has?
How do different roles communicate?
What’s the size of the team?
How do you communicate in the team?
Do employees promptly react to mail and instant messenger?
What other services do you use in the team?
What meetings are mandatory for the team? How much do they take out of the working hours?
Do you assess meeting efficiency and necessity?
How friendly and willing to assist co-workers are?
What’s the level of developers in the team and the other teams?
What’s the level of trust towards regular engineers in terms of supervision?
Do you have any algorithmic or mathematical tasks?
Is backend, frontend, test automation, and DevOps code written by the same people?
Do you have engineering duty? How often? What does it encompass?
What’s the worst duty accident you can remember?
What’s the release cycle like?
How up to date is the toolset?
What databases you use and consider using, and why?
How do you document best practices and guidelines?
How detailed and unambiguous engineering documentation is?
How do you document the product you’re working on?
Is it easy to search and change the documentation?
How do you know who’s the most knowledgeable person given a topic?
How do you deal with the bus factor?
How do new hires learn what they need to know to become productive contributors?
Do you have a new hire playbook?
Do you practice mentoring? Is mentoring only for the new hires?
How do you build the frontend code?
How does frontend communicate with backend?
What languages and frameworks you consider as an option when starting a project from scratch?
What’s the toolset for DevOps?
Do you have any specific tools that require specific hardware or operating system?
Where the data for local development come from? Is it real, or fake?
Do you review every code and documentation change?
What are code reviews like?
How many rounds of code reviews do you typically have for a big change?
How many people perform a code review of a single change?
What happens if one of the code reviewers isn’t happy about a part of the change?
How do you deal with bugs?
How do you deal with technical debt? Who’s responsible to rank it?
Are the tests fast? Are they reliable? Are they trustworthy?
How do you document the code?
How do you deal with badly documented, unreadable legacy code?
How do you deal with complicated database queries, do you use raw SQL, advanced framework features, or stored procedures?
What checks developers perform locally and what on CI?
Are you a consumer only, or do you pay back in some way to the open-source?
What’s the company vision of the open-source?
Is it allowed to work on the open-source during working hours?
Is it allowed to work on distantly related open source projects?
How you motivate employees to work on the open-source during working hours?
How does a product requirement look like when it reaches the developer?
To what extent is it possible for a developer to affect this requirement?
What’s the formal development process? Why you chose it?
How well you documented this development process?
To what extent a team can make amendments to the development process to fit their needs and improve their pipeline?
How hard the product pressure is?
How transparent are performance reviews and rules behind it?
How do performance reviews affect the salary?
How to go up in terms of the role and responsibilities?
How do you deal with the turnover?
How does the turnover compares with other companies?
Do you have a percentile graph of employee engagement length with the company in the engineering department?
How fast do you grow?
How to quit or get fired from the company?
How do you locally run dependent services?
How do you synchronize releases?
How do you decide the boundaries of those services?
Is the database shared between services? Do services have dedicated databases?
What do you use to imitate inter-service communication? How are the inter-service protocols documented? How are the inter-service communications tested?
Alright, you’re using microservices or are tearing apart a monolithic app.
What problems did you have you decided to solve with microservices?
Have you considered alternative approaches to those problems?
How do you deal with the problems of:
- M*N emitter to consumer communication (note: “the bus” isn’t an answer)
- message log retention
- message schema versioning
- stream and table dualism
- keeping an actual dimension of data
- data store separation
- inter-service join queries
- deployment synchronization
- transactional atomic updates of data spread over several services
Do you perform manual testing?
Do you have a dedicated QA engineer in the team?
How thorough is the manual testing?
When manual testing is happening?
What do you cover with automated acceptance tests?
Do you perform automated load testing?
Do you perform penetration testing?
Do regular developers have access to production logs and console?
Who’s responsible for deployments?
How do you automate deployments?
How long does the deployment take?
Can you perform a quick lossless rollback?
Can you do a hotfix?
Do you practice zero-downtime deployment?
Do you use atomic and fast schema migrations?
How do you deal with data migrations?
How do you run data migrations interleaved with schema migrations on deployment?
Who’s receiving production and staging error messages?
How do they react to those messages?
What’s the culture of the company?
Does the engineering department have its own culture?
To what extent the culture applies to everything that the company does in reality?
What are the exceptions?
Did you grow the culture?
Or is it an inapproachable ideal you are struggling to reach?
How do you teach employees why the culture is good?
Do you teach employees to become good at doing it the company way?
How do you deal with those who make an unintentional mistake that costs the company its profit or increases maintenance costs?
Under which circumstances is it possible to work on non-profit or profit projects in spare time?
Please feel free to comment with your suggestions. I’ll be happy to add to this list, as I’m going to use it myself in the future.