ACCELDATA Senior SDET Interview Experience (Round 4) – Questions, Approach & Solutions

Introduction

Recently, I appeared for the Senior SDET Round 4 interview at Acceldata, which was conducted by the Hiring Manager. At the time of this interview, I had around 4+ years of experience working in automation testing and backend systems.

This round was less about textbook definitions and more about real engineering experience, system thinking, and how you approach problems in production environments.

The discussion covered a mix of:

Product understanding
Real release testing experience
Multi-region failover testing
Kubernetes, Docker and AWS fundamentals
Coding problem solving
Test strategy and system thinking

The interviewer focused heavily on depth of understanding rather than surface-level answers.

In this blog, I’ll walk through the actual questions asked and the approach expected by the interviewer.

1. Understanding the Company and Product

The interview started with a simple but very important question:

“What does your current company do?”

This question is often underestimated, but it is actually meant to evaluate whether a candidate truly understands the business domain of the product they work on.

The interviewer expected a structured explanation including:

What problem the company solves
What kind of product/platform is built
Who the customers are
High-level architecture

A strong answer usually explains the product ecosystem rather than just naming technologies.

For example, a structured answer could look like this: My current company builds a data platform that helps enterprises monitor and manage large-scale data pipelines. The platform provides observability into data flow, pipeline performance, and infrastructure usage across various data systems like Spark, Snowflake, and Kafka. It helps organizations ensure reliability and efficiency in their data platforms.

After this, the interviewer asked several follow-up questions like:

What scale of data does your platform handle?
What type of customers use your product?
What technologies are used internally?

This discussion helped the interviewer understand how deeply the candidate understands the system they work on.

2. Roles and Responsibilities

The next question was:

“Explain your roles and responsibilities in detail.”

The interviewer wanted to understand how much ownership I had in my team.

A good answer should include the following areas:

Automation Development

Designing and implementing automation for backend services such as:

API automation
Integration testing
Regression automation

Framework Development

Building reusable automation frameworks using:

Python
Pytest
Client libraries
Utility layers

CI/CD Integration

Automation pipelines integrated with:

Jenkins
Docker
CI/CD workflows

Debugging and Root Cause Analysis

Investigating failures using:

logs
system metrics
debugging tools

Collaboration

Working closely with:

Developers
DevOps teams
Product managers

The interviewer asked several follow-up questions to evaluate how deeply I understood the systems I was testing.

3. Explain a Feature From the Last Release

This was one of the most important parts of the interview.

The interviewer asked:

“Take the last release and explain exactly what feature you tested.”

They expected a complete walkthrough of the feature lifecycle.

A good explanation should include:

Feature overview
Why the feature was introduced
System architecture changes
Testing strategy
Automation coverage
Edge cases tested

For example, a strong explanation could look like this: In our recent release, we introduced a feature that enabled cross-region data replication to improve system availability and disaster recovery capabilities.

The feature allowed the system to replicate critical data between multiple cloud regions, ensuring that if one region fails, the system continues operating from another region.

Testing Strategy

The testing strategy included several layers:

Functional Testing

Verifying that data replication occurs correctly across regions.

Failover Testing

Simulating failure of the primary region to ensure traffic is redirected to the secondary region.

Performance Testing

Ensuring the replication process does not significantly increase system latency.

Data Integrity Testing

Validating that replicated data remains consistent across regions.

Automation scripts were written to validate API responses and database states after failover scenarios.

4. Multi-Region Failover Testing

The interviewer then went deeper into the concept of multi-region failover testing.

They asked:

“Explain how you performed multi-region failover testing.”

What is Multi-Region Failover?

Multi-region failover is a cloud architecture strategy where services are deployed across multiple geographic regions.

If the primary region fails, traffic is automatically redirected to the secondary region.

This ensures:

High availability
Disaster recovery
Reduced downtime

Typical Architecture

A simplified architecture looks like this:


Users
  |
DNS (Route53)
  |
Load Balancer
  |
Primary Region
Secondary Region

Traffic normally goes to the primary region, but if health checks fail, it automatically shifts to the secondary region.

How Failover Testing Was Performed

The failover testing process typically involves several steps.

Step 1: Deploy Services in Multiple Regions

Services are deployed in:

Kubernetes clusters
Different AWS regions

Example:

us-east-1
us-west-2

Step 2: Configure Traffic Routing

Traffic routing is configured using:

AWS Route53
Load balancers
Health checks

Step 3: Simulate Region Failure

Failure scenarios are simulated by:

stopping services
killing pods
blocking network connectivity
shutting down nodes

Step 4: Validate Failover Behaviour

Key validations include:

traffic automatically redirected
application availability maintained
no data loss
minimal latency increase

Test Scenarios

Typical failover test scenarios include:

complete region shutdown
database failure
pod crashes
network partition
partial service failure

The goal is to ensure the system continues functioning without downtime.

5. Kubernetes, Docker and AWS Questions

The interviewer then asked several basic conceptual questions to verify real experience with infrastructure tools.

Docker Questions

Topics included:

What is Docker?
Difference between Image and Container
Docker lifecycle
Common Docker commands

Docker is a containerization platform that packages applications along with their dependencies so they can run consistently across different environments.

Example lifecycle:


Dockerfile → Image → Container

Common commands include:


docker build
docker run
docker ps
docker logs

Kubernetes Questions

Kubernetes questions focused on understanding core concepts such as:

Pods
Deployments
Services
Scaling
Debugging failed pods

Common debugging commands:


kubectl get pods
kubectl describe pod <pod-name>
kubectl logs <pod-name>

AWS Questions

AWS questions covered basic services such as:

EC2
Load Balancer
Route53
Multi-region deployments

The interviewer wanted to confirm practical exposure rather than theoretical knowledge.

6. Coding Problem – Organization Hierarchy

The final part of the interview was a coding problem involving manager-employee relationships.

Problem Statement

You are given a list of manager → employee pairs representing an organizational structure.

Constraints:

Each manager manages exactly one employee
Each employee has exactly one manager
No cycles exist
Multiple independent hierarchies may exist

Sample Input


B → F
C → D
F → C
E → A
W → X
A → B

Expected Output


E → A → B → F → C → D
W → X

Explanation

We need to find the top-most manager in each hierarchy.

A top-most manager is someone who never appears as an employee.

In this example:

Employees:


F, D, C, A, X, B

Managers:


B, C, F, E, W, A

Top managers:


E, W

Starting from E, we follow the chain:


E → A → B → F → C → D

Another independent chain exists:


W → X

Approach

The approach involves three main steps.

Step 1 – Build a Manager Map

Store relationships in a dictionary:


manager → employee

Step 2 – Find Top Managers

A top manager is a manager who never appears as an employee.

Step 3 – Traverse the Chain

Start from each top manager and keep following:


manager → employee

until the chain ends.

Python Implementation


def build_hierarchy(pairs):

    manager_map = {}
    employees = set()

    for manager, employee in pairs:
        manager_map[manager] = employee
        employees.add(employee)

    managers = set(manager_map.keys())

    top_managers = managers - employees

    result = []

    for manager in top_managers:
        chain = []
        current = manager

        while current in manager_map:
            chain.append(current)
            current = manager_map[current]

        chain.append(current)
        result.append(chain)

    return result


pairs = [
("B","F"),
("C","D"),
("F","C"),
("E","A"),
("W","X"),
("A","B")
]

chains = build_hierarchy(pairs)

for chain in chains:
    print(" -> ".join(chain))

Time Complexity

Building the manager map:


O(n)

Traversing the chains:


O(n)

Overall complexity:


O(n)

Space Complexity

Dictionary storage:


O(n)

Employee set:


O(n)

Total space complexity:


O(n)

Final Thoughts

The Round 4 Hiring Manager interview focused heavily on:

Real production experience
System architecture understanding
Cloud infrastructure knowledge
Problem-solving ability
Clear communication

Key takeaways for candidates preparing for similar interviews:

Be prepared to explain real features you worked on
Understand failover strategies and cloud architecture
Demonstrate structured thinking when solving problems
Focus on clarity rather than complex answers

Hiring managers look for engineers who can explain systems clearly, debug problems effectively, and think about reliability and scalability.