Tech Mahindra SDET Interview Questions and Preparation

TL;DR

Tech Mahindra SDET preparation should cover coding, object design, Selenium synchronization, API automation, framework architecture, CI, parallel execution, flake diagnosis, and client communication. Because roles are account-specific, use the current job description and recruiter guidance to prioritize the language, tools, and domain.

Key Takeaways

• Map preparation to the requisition and client stack because SDET expectations vary across Tech Mahindra accounts.
• Write maintainable code with tests, clear contracts, complexity reasoning, error handling, and deterministic behavior.
• Design automation as a product with layers, configuration, data, observability, ownership, and safe evolution.
• Use Selenium synchronization and stable locators without sleeps, global state, or excessive page-object abstraction.
• Combine UI, API, contract, component, and database evidence according to risk and feedback speed.
• Treat parallelism, retries, quarantine, and test selection as correctness-sensitive engineering decisions.
• Prepare client-facing stories about framework adoption, production incidents, tradeoffs, and mentorship.

Tech Mahindra sdet interview questions examine whether you can write reliable code, design maintainable automation, test services and user interfaces, diagnose failures, and deliver quality engineering in a client environment. Prepare as a software engineer who specializes in feedback systems, not as a tester who only knows tool commands.

The company supports varied client accounts, domains, locations, and stacks. An SDET opening built around Java, Selenium, and REST Assured can differ substantially from one built around TypeScript, Playwright, cloud services, or mobile automation. The current requisition and recruiter guidance should control your priorities.

This guide covers the durable skills behind those variations: coding contracts, framework architecture, synchronization, API quality, CI, parallelism, flake control, observability, and client-ready technical leadership.

TL;DR

Choose one language and one automation stack for depth. You should be able to build a small executable solution, test it, review it, and explain how it operates in CI.

1. Tech Mahindra sdet interview questions: Identify the Actual Engineering Role

Read the job description for engineering outputs. "Develop automation framework" implies API design, configuration, fixtures, data, reporting, CI integration, documentation, and adoption. "Improve regression" implies selection, reliability, execution cost, coverage, and release decisions. "Troubleshoot client issues" implies logs, distributed traces, data inspection, communication, and incident ownership.

Classify the role across five dimensions: primary language, system under test, automation surfaces, delivery platform, and domain. A Java web role may require collections, exceptions, streams, concurrency basics, Selenium, REST Assured, Maven, and Jenkins. A cloud service role may trade browser depth for APIs, containers, queues, observability, and resilience. A lead role adds architecture, estimation, review, migration, and client decisions.

For every named technology, prepare one example of correct use, one failure mode, and one tradeoff. For Selenium, you might show an explicit wait, explain how stale elements occur, and compare page objects with smaller component abstractions. For a CI system, show a gate, explain how credentials are isolated, and compare per-change with scheduled coverage.

Your introduction should describe the engineering product you created. State the teams or systems served, the feedback problem, constraints, your implementation, and the result. "I maintained Selenium" is weak. "I redesigned checkout test setup to create isolated orders through APIs, which made parallel browser checks deterministic" reveals a decision and mechanism.

2. Tech Mahindra sdet interview questions and Client-Aligned Assessments

A role may include recruiter discussion, coding or online assessment, technical interviews, managerial discussion, client evaluation, and HR steps, but the sequence is not universal. Ask whether the coding exercise is general or automation-oriented, which language is accepted, whether execution is available, and which client stack can be shared.

Prepare for depth from the resume. If you list Java, expect collections, object equality, exceptions, immutability, generics, streams, threading basics, and test design. If you list Selenium Grid, expect session creation, browser capabilities, node failure, concurrency, and artifacts. If you list REST Assured, expect HTTP and business assertions beyond given, when, and then syntax.

Client rounds often value communication as much as recall. State assumptions, use neutral language, and connect choices to their constraints. If you do not know a proprietary tool, say what comparable problem you solved, what concepts transfer, and how you would validate the new API. Do not bluff methods or versions.

Build an evidence sheet for each resume claim: baseline, workload, change, measurement, guardrail, limitation, and personal contribution. A claim about reducing runtime needs the suite size in honest terms, parallel capacity, flake impact, and whether infrastructure cost changed. Confidential numbers can be expressed as relative scope without fabricated precision.

Candidate reports are useful for practice ideas, not guarantees. A durable method works even when the first round changes: clarify, model, implement, test, inspect failure, and communicate the tradeoff.

3. Write Production-Quality Code, Not Interview Fragments

Core preparation includes strings, arrays, maps, sets, stacks, queues, intervals, linked structures, trees, graphs, sorting, searching, and basic dynamic programming. Automation-flavored exercises may parse logs, schedule tests, deduplicate events, compare JSON, retry work, or find dependency order. Practice both standard problems and these applied variants.

Clarify null behavior, input limits, duplicates, ordering, mutability, error policy, and deterministic output before coding. Work an example, explain a simple solution, then optimize if necessary. Use meaningful names and functions small enough to test. End with time and space complexity.

In Java, understand equals and hashCode, immutable records, checked and unchecked exceptions, resource cleanup with try-with-resources, generic collections, stream tradeoffs, and concurrency primitives at the level needed by your projects. A HashMap does not promise sorted output. A parallel stream is not a free performance switch. A mutable key can make an entry unreachable.

Write tests during the exercise when allowed. For a retry scheduler, cover immediate success, retryable failure, permanent failure, limit reached, backoff calculation, interruption, and deterministic time. Inject a clock or sleeper rather than waiting in real time. For a log parser, cover malformed and partial lines instead of assuming clean input.

Review your solution as production code. What happens on a large input? Can errors be diagnosed? Is shared state safe? Are secrets or personal data logged? The strongest SDET candidate sees the algorithm, test contract, and operating environment together.

4. Design Automation as an Internal Product

Framework design starts with users. Feature engineers need fast checks and readable failure output. QA engineers need expressive domain actions and controlled data. Release owners need trustworthy gates. Platform teams need resource limits, security, and maintainability. These needs determine architecture more reliably than a fashionable pattern name.

Separate concerns without hiding behavior. Tests express scenarios and assertions. Domain helpers express user or business actions. UI or API adapters contain transport details. Fixtures manage lifecycle. Data builders create minimal valid objects. Configuration handles environment facts, while secret stores provide credentials. Reporting collects safe artifacts and correlation identifiers.

Avoid a base class that owns driver, data, logging, waits, and assertions through global mutable state. Composition makes dependencies explicit and parallel execution safer. Introduce an interface when there is a real boundary or substitution, not for every class.

Plan evolution. Define versioning for shared libraries, examples, documentation, deprecation, migration, and consumer feedback. A framework succeeds when teams can add and diagnose valuable checks safely, not when the architecture diagram has many layers.

5. Explain Selenium 4 Synchronization and Browser Isolation

Current Selenium code should use the W3C WebDriver model and explicit waiting around observable conditions. In Java, WebDriverWait works with Duration, and ExpectedConditions provides common conditions. Do not use removed Selenium 3 timeout signatures or invent helper methods.

Stable locators prefer accessible roles or durable product attributes where the stack supports them, then unique IDs or semantic CSS. Avoid absolute XPath tied to layout. A page object should represent meaningful page behavior, not copy every locator into getters. Component objects can model repeated widgets such as date pickers or tables.

Synchronization is about state, not delay. Wait for visibility when a user must see an element, clickability when WebDriver must interact, URL or title after navigation, and application-specific state when built-in conditions are insufficient. A fixed sleep neither proves readiness nor explains failure. Set a bounded timeout and attach the current URL, screenshot, page source or DOM excerpt, console output, and network evidence where available.

Create a fresh driver or isolated browser session per test unless a deliberate fixture has a narrower safe scope. Shared sessions leak authentication, cookies, storage, navigation, and feature state. Parallel workers need independent data as well as independent browsers. Driver cleanup belongs in a guaranteed teardown path.

Frames, windows, and alerts require explicit context changes. After switching into a frame, return to default content. Track the original window handle before opening another. Accept or dismiss an alert through the alert API. The Selenium wait best practices guide is useful preparation for synchronization follow-ups.

6. Combine API, Contract, UI, and Database Evidence

SDET coverage should be layered according to risk and diagnosis. Pure unit checks protect algorithms and domain rules. Component tests exercise a service with controlled dependencies. Consumer-driven contracts protect interactions. Deployed API tests validate routing, identity, serialization, persistence, and policies. UI tests protect critical user journeys and presentation behavior.

For an order API, validate authentication, object authorization, required fields, boundaries, state transitions, durable data, events, idempotency, concurrency, errors, and observability. Avoid building a generic sendRequest(method, path, body) wrapper that erases type and intent. Domain clients such as OrdersClient.createDraft can preserve contracts while sharing transport setup.

Database assertions are appropriate when the test purpose is data integrity or migration and the team owns the schema. They can over-couple an external behavior test to implementation. Prefer public API state for black-box contracts, and use direct data access deliberately for setup, cleanup, diagnosis, or internal invariants.

Mocks and stubs provide speed and deterministic failure control, but they can drift. Contract tests verify that consumer expectations remain compatible with the provider. Integration tests still cover runtime configuration, credentials, routing, and real middleware. Review REST Assured request and response specifications for Java suite structure and Pact contract testing for compatibility concepts.

Keep secrets out of source and reports. Use approved runtime identity, least privilege, rotation, redaction, and separate test accounts. Test code is production-adjacent software and deserves the same security review.

7. Make CI, Parallelism, and Test Selection Correct

Design CI around feedback decisions. Fast deterministic checks should run early. Broader component and integration coverage can gate merge or deployment according to cost and risk. Expensive browser, performance, or resilience suites may run at scheduled or release gates. The pipeline should show which risk each stage protects.

Parallelism reduces wall-clock time only when tests and infrastructure are independent. Give each worker unique data, ports, files, accounts, queues, and environment namespaces. Limit concurrency against shared dependencies. Preserve worker, shard, attempt, seed, and configuration in results so a failure can be reproduced.

Retries need a named mechanism, bound, and evidence policy. A retry can collect information or tolerate an approved transient dependency, but the first failure remains visible. Quarantine needs an owner, reason, replacement coverage, and expiry. Otherwise the suite slowly converts known failures into permanent blind spots.

Test impact analysis can select checks from dependency data, but missing generated code, configuration, schemas, or runtime dependencies can create false confidence. Use conservative invalidation, explain why each test was selected, and fall back to broader coverage when the graph is uncertain. Periodic full runs help discover misses.

Useful pipeline measures include queue delay, execution duration, first-attempt reliability, diagnosis time, quarantine age, and escaped-risk learning. Do not reward teams for raw test count. More tests can make feedback slower and less trustworthy if their oracles and ownership are weak.

8. Run a Deterministic Java Sharding Exercise

This complete Java program assigns test names to shards using a stable hash and verifies the contract with built-in assertions. It avoids external libraries, so it can run on a current JDK. Save it as StableSharding.java, then run javac StableSharding.java and java -ea StableSharding.

import java.nio.charset.StandardCharsets;
import java.util.List;

public final class StableSharding {
    private StableSharding() {}

    static int shardFor(String testName, int shardCount) {
        if (testName == null || testName.isBlank()) {
            throw new IllegalArgumentException("testName is required");
        }
        if (shardCount <= 0) {
            throw new IllegalArgumentException("shardCount must be positive");
        }

        long hash = 0xcbf29ce484222325L;
        for (byte value : testName.getBytes(StandardCharsets.UTF_8)) {
            hash ^= Byte.toUnsignedInt(value);
            hash *= 0x100000001b3L;
        }
        return (int) Long.remainderUnsigned(hash, shardCount);
    }

    public static void main(String[] args) {
        List<String> tests = List.of(
            "login.valid-user",
            "checkout.card-decline",
            "orders.cancel-pending",
            "profile.unicode-name"
        );

        for (String test : tests) {
            int first = shardFor(test, 4);
            int second = shardFor(test, 4);
            assert first == second : "assignment must be deterministic";
            assert first >= 0 && first < 4 : "assignment must be in range";
            System.out.printf("%s -> shard %d%n", test, first);
        }
    }
}

Explain the tradeoffs. Stable hash assignment is simple and reproducible, but it does not balance historical duration, browser requirements, data incompatibilities, or scarce devices. Changing the shard count can move many tests. A production scheduler can consider constraints and estimated duration, then persist the final plan for diagnosis.

Follow-up questions may include a worker crash, one very slow test, dynamic capacity, or reruns. Separate logical test identity from attempt identity. Results should be idempotently ingested so a delayed worker cannot overwrite the accepted final status incorrectly.

9. Diagnose Flaky Tests With a Cause Model

Flaky means the observed result changes without a relevant intended input change. That label describes a symptom, not a cause. Possible mechanisms include product race, test race, leaked state, data collision, unstable dependency, wall clock, randomness, browser behavior, resource pressure, environment drift, or incorrect oracle.

Preserve evidence from the original failure: build, commit, worker, attempt, seed, time zone, browser, data identity, request IDs, logs, screenshot, trace, and resource signals. Compare pass and fail timelines. Use repeated execution only as an experiment, and change one suspected variable at a time.

Replace sleeps with observable conditions. Control time with an injected clock where possible. Seed randomness and print the seed. Isolate data and files. Use deterministic synchronization in concurrent code. Record dependency responses for analysis, but do not automatically turn recordings into permanent mocks that miss contract change.

Measure first-attempt reliability and developer impact. A suite that passes after three retries can still waste significant time and hide product races. Classify causes, assign owners, set quarantine expiry, and track recurrence. Prevention may require product testability, environment observability, or platform changes, not only edits to the test.

The flaky test root-cause guide can help structure investigations. In an interview, describe one mechanism you actually removed and how you proved the fix, rather than saying you "added waits."

10. Build a Four-Week Tech Mahindra SDET Plan

Week one covers language and coding. Review collections, object semantics, exceptions, streams, files, concurrency basics, and the chosen unit-test library. Solve timed problems with tests and complexity. Implement one parser or scheduler related to automation.

Week two covers UI and API automation. Build a small browser flow with stable locators, explicit state waiting, isolated data, and useful artifacts. Build service tests for authentication, authorization, schema, state, idempotency, and errors. Be ready to explain why coverage belongs at each layer.

Week three covers architecture and delivery. Design a framework, CI pipeline, data lifecycle, configuration and secret model, parallel plan, retry policy, and reporting. Add compatibility, versioning, migration, documentation, and ownership. Practice adapting the design for a second client stack.

Week four covers debugging and interviews. Investigate a deliberately flaky test, review unfamiliar test code, run two coding mocks, one framework design, one client scenario, and one behavioral mock. Rehearse stories about adoption, production failure, disagreement, mentorship, and a decision that did not work.

Ask interviewers which quality problem the role owns, who consumes the automation, which client constraints can be discussed, how framework contributions are reviewed, and how success is measured. These questions expose whether the job is framework maintenance, product engineering, delivery testing, or technical leadership.

Interview Questions and Answers

Q1: How would you design an automation framework from scratch?

I would first define users, systems, feedback objectives, languages, environments, data constraints, CI, and ownership. The design separates scenarios, domain actions, transport adapters, fixtures, data builders, configuration, assertions, and diagnostics without hiding behavior. I would pilot one valuable workflow, measure reliability and diagnosis, document contribution patterns, and evolve through versioned changes.

Q2: What is the difference between implicit and explicit waits in Selenium?

An implicit wait configures element lookup polling for a driver, while an explicit wait polls a defined condition until a deadline. I prefer targeted explicit waits because the expected state and timeout are visible near the interaction. Mixing wait types can create confusing timing, so I keep the strategy consistent and avoid fixed sleeps.

Q3: How do you make Selenium tests safe for parallel execution?

Each test receives its own driver or isolated session, unique data, and independent files or namespaces. Shared configuration is immutable, while mutable test state stays within the test scope and cleanup cannot affect another worker. Results record worker, session, data identity, and artifacts for diagnosis.

Q4: How would you test a REST API in Java?

I model domain requests and responses, then validate authentication, authorization, inputs, schema, business state, errors, side effects, idempotency, and dependencies. Reusable request and response specifications can centralize safe transport defaults without hiding each endpoint contract. Data setup, cleanup, correlation IDs, and failure logging are explicit and parallel-safe.

Q5: When do you use a page object?

I use a page or component object when it gives stable names to meaningful UI behavior and localizes interaction details. I avoid giant inheritance trees, assertions buried in navigation, and one method per locator with no domain value. Tests should still reveal the user journey and expected outcome.

Q6: How do you handle dynamic elements?

I identify the stable business attribute and the state that makes interaction valid. I use a durable locator plus a bounded explicit wait for visibility, enabled state, content, or another observable condition. I do not solve changing identifiers with broad XPath or use sleep as synchronization.

Q7: What causes stale element references?

A stale reference points to an element that is no longer attached to the current DOM, often after navigation or rerender. I locate the element after the state change or wait on a condition that reacquires it, rather than caching WebElements for long periods. I also investigate whether the application has unnecessary churn that harms testability and users.

Q8: How do you reduce automation execution time?

I measure queue, setup, execution, and teardown separately, then remove waste at the right layer. Options include moving rules below the UI, reusing immutable build artifacts, creating data through faster supported APIs, safe parallelism, and conservative test selection. I protect first-attempt reliability and coverage so speed does not create false confidence.

Q9: What is your approach to flaky tests?

I preserve the first failure and classify a mechanism using environment, timing, data, dependency, and product evidence. I reproduce or amplify the mechanism, implement a deterministic fix, and verify it under stress and relevant environments. Retries and quarantine are bounded controls with ownership, not permanent fixes.

Q10: How would you test a CI pipeline?

I test triggers, change selection, build reproducibility, secret access, stage dependencies, failure propagation, cancellation, retries, artifacts, approvals, deployment identity, rollback, and notification. Small fixture repositories can exercise pass, fail, timeout, and partial infrastructure failure. Production canaries and audit invariants protect behavior that pre-release tests cannot fully reproduce.

Q11: How do you review automation code?

I prioritize correctness, isolation, determinism, security, useful assertions, diagnosis, and maintainability before style. I check whether the test can fail for the intended reason, whether data or state leaks, and whether helper abstraction hides important behavior. Feedback states the mechanism and impact and distinguishes blockers from suggestions.

Q12: How would you migrate a client suite to a new tool?

I start with the client problem, constraints, and success criteria rather than assuming migration is necessary. I compare capability, skills, ecosystem, CI, diagnostics, maintenance, and transition cost, then pilot representative risky tests. If evidence supports migration, I run old and new signals in parallel, document gaps, train contributors, and retire coverage incrementally with rollback available.

Common Mistakes

• Preparing one generic Tech Mahindra loop instead of the current client-aligned role.
• Memorizing Selenium methods while neglecting coding and HTTP fundamentals.
• Designing a framework by listing patterns before identifying users and constraints.
• Putting driver, data, logging, and assertions into one mutable base class.
• Using fixed sleeps as the standard synchronization strategy.
• Sharing browser sessions or test accounts across parallel workers.
• Hiding all API behavior behind one generic request helper.
• Treating direct database assertions as appropriate for every black-box test.
• Reporting a retry pass as if the first-attempt failure did not occur.
• Selecting tests from an incomplete dependency graph with no safe fallback.
• Optimizing runtime without protecting signal quality and diagnosis.
• Naming tools you cannot explain through a real design or failure.
• Presenting client work or metrics beyond what you are authorized to disclose.

Conclusion

Tech Mahindra sdet interview questions reward connected engineering skills. Write and test clean code, design automation around developer needs, use reliable synchronization, layer API and UI evidence, build correct CI behavior, and investigate nondeterminism from preserved facts.

Calibrate depth to the actual requisition and client stack. Your next step is to run the Java sharding exercise, diagram one framework you built, and practice defending its data, parallelism, diagnostics, rollout, and limitations.

Interview Questions and Answers

Frequently Asked Questions

Related Guides

• Accenture SDET Interview Questions and Preparation
• Adobe SDET Interview Questions and Preparation
• Airbnb SDET Interview Questions and Preparation
• Apple SDET Interview Questions and Preparation
• Atlassian SDET Interview Questions and Preparation
• Booking.com SDET Interview Questions and Preparation