Introduction

Companies offering Developer/Software Engineering roles sometimes tell us little about the engineering culture. In fact we are asked tons of interview questions to determine whether we are a good fit for the role. Finally it is our time to ask a few questions. What should we ask to get an understanding of the place we are going to work? The company has vetted us, its our time to grill them.

In this post we will be discussing the kind of questions that we should be asking our interviewer (either at the end of our interview or almost at the beginning) for devs/devops and QA (Engineering Team) roles.

What do we want?

Some key things that are likely to make Us Devs feel satisfied in a role within organization (apart from compensation) are :

• We want to feel empowered to be the change - Autonomous teams right?
• We don't want the constant feeling of pressure to deliver. We should be part of the team that knows its velocity - Agile 101.
• We want to be proactive, not reactive. It drains us.
• We want a vibrant atmosphere where we grow and learn even if sometimes the projects at hand keeps us stuck on certain practices and tech for long periods of time. - Code Dojos/Katas
• We would like a chance to innovate and change the tech status quo. Learn or create something which might make our life easier, or be better for our team or the organization. - Innovation/hackathons
• We would like less bureaucracy. We are here to write idiomatic code not push paper - again Autonomy.
• Career progression/chance to grow. Once we are in the job settled we would want to stay in the hunt for the next exciting thing. We cannot let our skills or mind settle. Either we progress to the next step up or we keep learning the next cool thing or both (in some cases).

Few years ago we had Joel Test to determine the kind of place we were going to work at. Now its a given. However, what kind of questions should we devs ask to understand the lay of the land we are heading into? Companies come in all forms - autonomous culture, agile culture, devops culture or no idea culture.

Diving Deep

1. Autonomy - with great power comes great responsibility.

Autonomy means onus is on our team. We need autonomy to ensure we keep our house in order - with as little maintenance as possible. So what does taking responsibility looks like

• Testing - We as a team chose the right testing framework, code and decide on our test coverage metrics. Onus is on us as team to get our deployment confidence high. Team decides the benchmarks.

• CI/CD & Devops - We as a team maintain the pipeline, its fitness. We have a DevOps culture. Everyone in a team is responsible right down from inception to delivery. We start with documenting our deployment confidence and then automating the pain points. We don’t rely on Platform Engineering or anyone outside the team to deploy to production.

• Site Reliability Engineering - Logging and Alerting on Production. We monitor the production environment. We do the logging and active diagnostic monitoring. We set alerts. We do Site Reliability Engineering to ensure everything is running smooth. We as a team don’t rely on anyone outside the team to tell us if our product broke down on production. If we break it we fix it.

• Availability Statistics on Production - We as a team monitor it and strive to ensure it stays as high.

• Cost Monitoring on Production - We as a team monitor this and work on bringing this down over a period of time.

• Engineering Improvements - Developing features is business requirements. Product Owners tell us the priority for that. But, we do we have an engineering improvement budget? If yes autonomy means team get to chose the engineering improvement tasks and work on it. Bottom line it is our product as a team and we need to work towards making it better.

Whoosh, looks so much responsibility, may be we are better off without the power. Why do I still want to embrace it? Because it cuts through the red tape. We as a team rely less on people outside the team to get our work done. Also we choose our work to make our product better. We set our own benchmark and objectives. We search for code coverage metrics, pipeline fitness and availability statistics on production. We show improvement on these metrics. We show management how we have improved on those metrics over a period of time. If we don’t have the power how will we show improvement even if we want to? We work as a team together to reach same objectives that we decide.

So assuming we want responsibility that comes with autonomy - how to measure do we have the autonomy we deserve?

Q- Do you have the autonomy to deploy when your team is confident?
Q- Do you have the autonomy to choose your own tools/tech within a broad range?
Q- Do you have the autonomy to decide the tools for deployment?
Q- Do you have the autonomy w.r.t. task planning and estimation (Planning Poker) without influence from PO/BA/higher powers?
Q- Do you have the autonomy to monitor your products in Live environment?
Q- Do you have the autonomy to develop set of metrics to show improvement and achieve KPIs/OKRs?
Q- How do you define the KPIs/OKRs needed to show the higher powers that you are progressively getting better at your job?
Q- How much autonomy is given to the overall team? Describe in detail in terms of engineering practices, deployment, sprint planning and SITE Reliability Engineering.

2. Sprint Planning and Agile

Most companies boast they are agile however the reality is likely to be project management works in waterfall mode and dev teams deliver in agile sprints. We might need to dig into the nitty gritty to best understand how our day to day is going to look like.

Assuming you work in Agile sprints.
Q- How long is the sprint cycle?
A - 1/2 (generally)/3 weeks.

Q- Is the whole team involved during refinement and estimation?
A - No i.e. higher powers estimate and give it to us to execute.
A - Yes i.e. we play planning poker.

Q- Does backlog grooming/refinement take place during the sprint or just before beginning of the new sprint?
A - Yes we do sprint planning for future sprints continually in the current sprint i.e. we keep the pipeline of work healthy. Also anyone can pick the next work item as the estimation happens together across the team or at least with 3 amigos.
A - No we do this at the beginning of the new sprint i.e. chaotic start or we just do as we are told by higher powers.

Q - How do you derive the velocity in sprint?
A - Using story points.
A- Time !!! i.e. If you are late by half a day you might be docked :(

Q - If you estimate in story points does that equate to time or complexity?
A - Time !!! :( wrong answer
A - Complexity. Great, thank you :)

Q - Does your team have complexity scale mapped out? i.e. certain tasks/stories/bugs done in the past equated to certain story points? It helps new developers estimate new stories in planning poker based on order of complexity.

Some context on story points and wild world of agile software estimation.
Task A is estimated to be 8 hours to be delivered in time estimation world. Task B is 3 story points in story points world. Lets assume 1 story point change means one line code change which has to go through whole test regression cycle. 3 story points on complexity scale means it looks 3 times more complex than 1 story point (significantly complex). This also means that no one can hold a gun to our head to deliver the Task in a certain time period just because we promised. Story points does not equate to time, it equates to complexity involved in working it out. Complexity scale and velocity are internal to the team.

Q - Do you undertake sprint retrospective and take actions from them?
Q - Do you undertake occasional team health checks?

3. Pair Programming and TDD Culture

Q - Do you encourage Pairing/Pair programming?
Q - What about TDD. Do you like writing test first and do blue green refactoring?
Q - What about integration testing? How much code coverage do you have?

4. Innovation Time

Q - Do you give a certain percentage of development time to engineers for innovation? Caveat, we as engineers understand the innovation that we get is proprietary of the organization and we love to do a show and tell when we take this time.
A - Of course yes 5-10% of our sprint time is allocated for that. Google gives you 20%.
A - No we don't. We own you on our time :)

5. Code Kata/ Code Dojos/ Hackathon

Q - Do you have regular code katas/hackathons sessions in your company for engineers to practice/learn new skills ? This is an essential option that should be given to devs to ensure they have a place to pair up, practice and improve their skills.

6. Access To Learning Resources

Q - Do you provide access to either Pluralsight, Udemy, Linked In Learning?
A- Yes we do.
A - No but we give you a training budget.
A - No. Period !!!

7. Career progression

Q - How is the organization going to help us achieve our next progression plan? Whether that is promoting us to Leads/Engineering Managers or Principal Engineers or Architects. Also if there is a glass ceiling or end journey in terms of titular progression Q - What can the organization do to allow us to grow as a professional?
Q - Do you sponsor certifications like MSCD/MCPD, Amazon, TOGAF et all. If yes, what is the annual budget for that?

8. Open Source

Q - Does the company have a policy on our contributions to open source projects?
A - Yes, however it does mandate the work you are doing is unrelated to organizations intellectual property.
A - No, we don't do that. You cannot contribute while you are on our payroll.

9. Some Tech Questions

Q - PR reviews before merge, Branching/merging strategy?
A - Example 2 PR reviews for major change. 1 for minor, GIT Flow or trunk based.
Q - Microservice or monolith architecture?
Q - If microservice then choice of poison. Serverless or Containers :D?
Q - Cloud Provider if you want to know Azure/AWS/GCP/In-Premise?

10. Time to Production. Continuous Delivery or Continuous Deployment?

Q - How much time does it take usually from merging the code to deployment on production?
This will give us an idea about deployment confidence, scale of automation and the pace of working. Time on lower scale (means in hours) Shift Left Engineering culture. Higher side (in days or weeks) means a lot of manual testing and deployment after merge.
Q - CI/CD tools you are using?
Q - Monitoring diagnostic tools you are using?

11. Hardware

Please don't shy from asking this question. I have made this mistake so many times, sometimes I forgot or out of courtesy. This is one common denominator that can make your life miserable or okay. THE BLOODY DEVICE WE WILL WORK ON !
Q - Laptop or PC. Could you tell me the spec of the device. Do I have a choice or an option here in a certain budget?
Q - Can I buy a docking station within a budget for my device?
Q - In this remote working era do you have budgets for some home office setup. Example monitor, keyboard mouse and cheap table?

12. Engineering Vision

A lot of companies may be start up or have projects in greenfield state. They may not have infrastructure/road map set up. Then you ask for their tech vision or plan. How are they planning to set their engineering road map? This gives us an opportunity to talk to them and iron out a plan.

Final thoughts

A lot of the answers to these questions will determine the kind of place you are going to work. Don't be disappointed if the answer is no to some of them. Sometimes it is not possible to have all. The key is to know which ones are non-negotiable for you to stay happy and grow. Idea is thou shall ask and thou shall receive. If you don't ask then you will not get it or know it exists.