Coding Interview Questions for SDETs (Arrays, Strings, Logic)

Overview

The coding screen is where SDET offers are quietly decided. It is also the round that candidates from a testing background dread most, because they spend their days finding bugs in other people's code, not producing correct code from scratch against a running clock. The good news is that SDET coding screens are narrower and far more predictable than full software engineering loops. Master a handful of patterns over arrays, strings, and hash maps, learn to think out loud, and you clear the bar that filters out most of the field.

This guide is a working set of the problems that actually appear, with the reasoning that turns each one from a blank page into a clean solution. Every example includes how to approach it, short pseudo-code, the complexity, and the edge cases an SDET is expected to raise. Treat the pseudo-code as scaffolding for your own implementation in Java, Python, JavaScript, or C-sharp, not as lines to memorize.

One promise up front: you do not need competitive programming skills for this. You need fluency with basic structures, a repeatable method for attacking an unfamiliar prompt, and the testing instinct that is your home advantage. This article builds all three.

How SDET Coding Screens Differ From Developer Screens

A developer coding loop can dip into dynamic programming, graph traversal, and tricky recursion. An SDET screen almost never does. The topic set is bounded: array manipulation, string processing, hash maps and sets, basic sorting and searching, and light logic puzzles. Most interviewers let you pick your language and care more about how you get to a solution than about squeezing out the last microsecond. That narrower scope is a gift, because it means focused practice pays off fast.

What they are actually grading is often invisible to nervous candidates. Do you clarify the problem before writing anything. Do you state the brute force and then improve it. Do you name the time and space complexity without being asked. And, the SDET tell, do you test your own code with concrete inputs including the empty case and the weird case. A merely-correct solution delivered in silence scores worse than a slightly slower solution narrated with clear reasoning and a real test plan.

A Repeatable Method for Any Coding Prompt

Under stress, people freeze because they have no procedure. Give yourself one and run it every single time, even on an easy problem. The five steps below take thirty seconds to start and keep you moving when your mind goes blank. The interviewer hears a structured thinker, which is exactly the signal a test-engineering role rewards.

• Restate the problem in your own words and confirm you understood it.
• Clarify constraints: input size, types, duplicates, empties, sorted or not.
• State the brute force with its complexity, so a baseline exists on the board.
• Optimize: name the pattern (hash map, two pointers, sliding window) and code it.
• Test out loud: trace one normal input, one edge case, one nasty input.

Array Problems You Should Solve Cold

Move all zeroes to the end while keeping the order of non-zero elements, in place. The naive answer builds a new array, but they want O(1) extra space. Use a write pointer: `write = 0; for read in 0..n-1: if a[read] != 0: swap(a[write], a[read]); write += 1`. Non-zero values slide forward, zeroes collect at the tail, and you touch each element once for O(n) time and O(1) space. Edge cases you should say aloud: an array of all zeroes, an array with no zeroes, and a single-element array.

Maximum subarray sum, often called Kadane's problem: find the contiguous slice with the largest total. Track a running sum and a best sum: `best = current = a[0]; for x in a[1:]: current = max(x, current + x); best = max(best, current)`. The insight to verbalize is that a running sum which has gone negative can only hurt what follows, so you drop it and start fresh at the current element. That is O(n) time, O(1) space. Flag the all-negative case, where the answer is the single least-negative number, not zero.

String Problems That Come Up Constantly

Are two strings anagrams. The clean approach is a frequency count: build a map of character counts from the first string, decrement it while scanning the second, and confirm every count lands at zero. `count = {}; for c in s1: count[c] += 1; for c in s2: count[c] -= 1; return all values == 0`. That is O(n) time, better than the O(n log n) sort-and-compare, and it lets you show judgment. Before coding, ask the questions an SDET always asks: does case matter, do spaces count, and are we in ASCII or full unicode. Those clarifications are worth real points.

First non-repeating character in a string. Two passes over a count map: first build the counts, then scan the string in order and return the first character whose count is one. `for c in s: count[c] += 1; for c in s: if count[c] == 1: return c; return null`. The subtlety worth naming is that you must scan the original string on the second pass, not the map, because a hash map does not preserve first-seen order in every language. Return a clear sentinel when every character repeats.

Stacks and Bracket Logic

Valid parentheses is the canonical stack question and shows up in SDET screens because parsers and validators are everywhere in test tooling. Given a string of brackets, decide whether every opener has a correctly ordered matching closer. Push openers onto a stack, and on each closer check that the stack top is its matching opener before popping. `for c in s: if c is opener: push(c); else: if stack empty or top != match(c): return false; pop(); return stack is empty`. It is O(n) time and O(n) space.

The mistakes to avoid, and to point out that you are avoiding, are forgetting the final emptiness check (which catches an unclosed opener like a lone left bracket) and mishandling a closer that arrives with an empty stack. State both edge cases before you run your trace. This problem is a favorite precisely because it rewards careful state handling, the same discipline that makes someone good at writing test frameworks.

Hash Map Problems: The SDET Workhorse

Group anagrams together from a list of words. The trick is choosing a canonical key that all anagrams share. Sorting each word gives a key in O(k log k) per word, or you can build a 26-length character-count signature for O(k). `for word in words: key = sorted(word); groups[key].append(word); return groups.values()`. Talk through the trade: the sorted key is simpler to explain, the count signature is faster for long words. Interviewers love hearing you weigh two valid options rather than committing blindly.

Find the first duplicate in an array, returning the element that appears a second time earliest. A seen-set does it in one pass: `seen = set(); for x in a: if x in seen: return x; seen.add(x); return null`. This is O(n) time and O(n) space. If they add the constraint that values are in the range one to n and you must use O(1) space, that is your cue to pivot to index marking or cycle detection, and saying so out loud shows you recognize when a constraint changes the whole approach.

Logic and Puzzle Questions

The missing number from one to n, given n-1 of them. Two clean answers. The sum formula: expected total is `n * (n + 1) / 2`, subtract the actual sum, and the difference is the missing value, O(n) time and O(1) space. The XOR approach: XOR all indices and values together and the survivor is the missing number, which sidesteps the integer overflow risk that the sum method has on very large n. Naming that overflow caveat is a small detail that reads as senior.

FizzBuzz still appears, but the real test is often the follow-up: make it extensible so a product manager can add rules without a code change. That is your opening to show design instinct. Instead of hard-coded if-else branches, model the rules as data, `rules = [(3, 'Fizz'), (5, 'Buzz'), (7, 'Bazz')]`, then for each number build the output by appending every label whose divisor matches, falling back to the number itself when nothing matched. You just turned a trivia question into a demonstration of open-for-extension design, which is what an SDET who builds frameworks should reflexively do.

Pattern Recognition: Two Pointers and Sliding Window

Half of these problems collapse the moment you recognize the pattern. Two pointers suits sorted arrays and in-place partitioning: one pointer reads, one writes, or two converge from the ends. Sliding window suits substring and subarray questions with a running constraint. The classic is the longest substring without repeating characters: expand a right pointer, track characters in a set, and when you hit a repeat, shrink from the left until the window is valid again, recording the best length as you go.

Pseudo-code: `left = 0; seen = set(); best = 0; for right in 0..n-1: while s[right] in seen: seen.remove(s[left]); left += 1; seen.add(s[right]); best = max(best, right - left + 1)`. Each character enters and leaves the window at most once, so it is O(n) despite the nested loop. Being able to say the amortized complexity, rather than panicking at the nested `while`, is a strong signal of real understanding.

Write Code an Interviewer Would Actually Merge

Correctness gets you a passing grade; readable code gets you the offer. Use descriptive names (`writeIndex`, not `w`), keep functions small, add guard clauses for the empty and null inputs at the top, and avoid magic numbers. As an SDET this is your natural edge: you have read thousands of lines looking for bugs, so you know what fragile code looks like. Write the opposite. If you extract a tiny helper because it makes the logic testable in isolation, say why, because that is precisely the judgment a test-engineering role is buying.

When you finish, do not sit back and wait. Run your own code against a normal case, an empty input, and one adversarial input, tracing variables out loud. This closing move is where SDETs pull ahead of developer candidates, who often declare victory the instant the happy path compiles. Testing your own solution unprompted is the single most on-brand thing you can do in the room.

Talking About Big O Without Sounding Rehearsed

State complexity as a natural consequence of your data structures, not as a memorized label. For example: a single pass is linear, the hash map adds linear space, and I traded that space to avoid the quadratic nested loop. That sentence tells the interviewer you understand the trade rather than reciting a chart. Always give both time and space, and if you optimized, name what you gave up to get there.

• O(1): direct index or hash lookup, arithmetic on a fixed set of variables.
• O(log n): binary search on a sorted array, balanced tree height.
• O(n): a single pass, one loop over the input, most hash map solutions.
• O(n log n): a sort as a preprocessing step, then a linear pass.
• O(n squared): nested loops over the same input, the brute force to avoid.

Mistakes That Fail Otherwise-Strong Candidates

The failures are rarely about not knowing the algorithm. They are about process. The most common is diving into code before clarifying the problem, then solving the wrong thing. Close behind is coding in total silence, which denies the interviewer the reasoning they are there to grade. Others: never stating complexity, ignoring the empty and single-element inputs, over-engineering a five-line problem, or freezing at the brute force and never attempting to optimize even when nudged.

• Writing code before restating the problem and confirming constraints.
• Long silences that hide your reasoning from the person scoring it.
• Skipping the complexity discussion until forced to give it.
• Never testing your own code with an empty or adversarial input.
• Giving up at the brute force instead of trying the obvious optimization.

A Practice Routine That Actually Transfers

Volume is overrated; deliberate reps are not. Pick twenty problems spread across arrays, strings, hash maps, stacks, two pointers, and sliding window, and solve each one out loud on a timer as if a person were watching. The talking is the skill under test, and it does not develop while you solve silently in your head. After each attempt, write one line naming the pattern so your brain files it for retrieval under pressure.

Re-solve your weakest five problems a week later from a blank editor. Spaced repetition beats fresh volume for interview recall. In the final week, run at least three full mocks with a friend or a mock-interview tool, because the gap between knowing a solution and delivering it while a stranger watches the clock is the exact gap that decides your result.

Frequently Asked Questions

Related QAJobFit Guides

• Docker Interview Questions for SDETs
• SDET Coding Interview Questions for Testers (2026)
• Airbnb SDET Interview Questions and Preparation
• Booking.com SDET Interview Questions and Preparation
• Java Coding Interview Questions for Testers (2026)
• JavaScript Coding Interview Questions for Testers (2026)