We recently spoke with Timur Shahmuratov, the Team Lead of the Apliteni Backend. Let’s dive into the interview!
“How do you communicate within your team?“
We hold one mandatory meeting a week. On Mondays, we analyze our achievements, add new tasks, distribute resources, and plan for the next week. Planning Poker determines how we estimate our tasks and whether our sprint is loaded. If we fill that sprint still has capacity in terms of sprint points, we add more jobs.
“What’s Planning Poker?“
Planning Poker, or Scrum Poker, is a consensus-based estimation technique. It helps us eyeball the effort or the relative size of development goals.
The process involves team members receiving imaginary decks of cards with numbers. The team discusses each task, and each member chooses a card representing their estimate independently of the task’s complexity. All choices are revealed simultaneously to avoid influencing one another.
The team discusses the high and low estimates to understand the different viewpoints. The process repeats until the group reaches a consensus. This method is beneficial for incorporating diverse perspectives, minimizing biases, and encouraging team discussions.
“How do you build daily communication?“
We strive for asynchronous communication. All discussions occur in public channels, as far as all our team members are distributed globally.
“How does asynchronous communication work?“
Asynchronous communication refers to communication that doesn’t require all participants to respond immediately. This method allows for conversations and exchanges of information to happen at the convenience of all participants, regardless of time zone or schedule.
Messages can be sent without expecting an immediate response from the recipient. This allows participants more flexibility when they send and receive news. It can lead to more thoughtful and comprehensive answers. We also strive to have communication done in public channels.
Asynchronous communication can also help reduce work-hour meetings and interruptions, increasing productivity.
“How do you handle complex tasks?“
If we have doubts or difficulties with a task, we create an RFC (Request For Comment) before starting work. This helps us to ensure everyone understands why and what we are doing, especially regarding complex tasks.
We follow the agile methodology, incorporating weekly sprints. We decompose large tasks into smaller ones to see the progress better.
“How do you communicate with other teams?“
All communication between teams also takes place in public channels. Because our large tasks involve creating an RFC, the interaction format between the backend and frontend is formed at this level, minimizing possible mismatches and problems.
When a developer completes a task, he creates a merge request. Once it is made, we perform a code review. Every team member has valuable and rich experience, thus every idea and opinion matter. We expect that every new feature or bug fix will be covered with test cases. Receiving feedback is extremely important, and we strive to ensure it gets noticed.
When people understand why something was done this way or another, they are better at developing the product. To work effectively, you need to know in which direction the “ship” is going. For this, we use the “5 why” practice.
“How does it work?“
“Five Whys” is a technique used to explore the cause-and-effect relationships underlying a particular problem. The primary aim of the method is to identify the root cause of a defect or issue by repeatedly asking the question, “Why?”. Each subsequent question is posed in response to the answer to the previous question. The number “5” is chosen empirically and is considered sufficient to find solutions to typical problems.
Not all problems have a single root cause. If necessary, to find several root causes, the technique should be repeated with different sets of questions. The method does not offer strict rules and constraints, such as what questions to ask or how long to continue asking questions to find additional causes. Thus, even when following the method, the results largely depend on the knowledge and persistence of the people involved.
For example, the problem “the car engine won’t start” might have such a chain of questions:
– Why? – The battery is dead.
– Why? – The alternator is not working.
– Why? – There are problems with the alternator belt.
– Why? – The belt was fine until now, but it was never replaced.
– Why? – A regular technical inspection was not carried out, which would have revealed that the belt’s lifespan was exhausted (root cause).
“How do you choose which candidate is right for your team?“
In terms of hiring, if it is immediately apparent that a person is toxic, this is a red flag. We value soft skills, but hard skills are also necessary. Sometimes in an interview, a candidate speaks well and logically, but his skills may need to meet expectations when it comes to code. Balance is important. We hire people who will improve our team, and who will move us forward, advancing the overall competencies of the team. It’s great if the candidate has the knowledge we need to gain.
Conclusion
Our enlightening conversation with Timur Shahmuratov offered valuable insights into the unique strategies that drive the success of Apliteni’s backend team. Their innovative approaches set a remarkable precedent. Their importance on feedback, a balance of hard and soft skills in their hiring process, and their value on team members’ creativity and adaptability further solidify their commitment to excellence.
The team’s unique blend of strategies and values underscores the importance of innovation, collaboration, and balance in achieving success in the complex landscape of backend development. This interview is an inspiring testament to the power of effective teamwork and innovative thinking in the tech industry.
Do you want to join Apliteni’s team? Check our available positions:
