Minimum Edit-Distance String for Each Query
Reported by candidates from Target's online assessment. Pattern, common pitfall, and the honest play if you blank under the timer.
Target reported this one in July 2026, and the detail that trips people is the tie-break: when several candidates sit at the same minimum edit distance, you return the lexicographically smallest. The rest is classic Levenshtein DP run across up to 100 candidates and 50 queries, with strings capped at 50 characters. If you've seen edit distance before, you already know the core. If you blank on the recurrence mid-assessment, StealthCoder runs invisibly on your desktop as a safety net and gives you the solution in real time.
The problem
You are given an array of distinct candidate strings strings and an array of query strings queries. The edit distance between two strings is the minimum number of single-character insertions, deletions, and replacements needed to transform one string into the other. Each operation costs one. For each query, return the candidate string with minimum edit distance to that query. If several candidates have the same minimum distance, return the lexicographically smallest candidate. Comparisons are case-sensitive and use the characters exactly as provided, without additional normalization. Implement findClosestStrings(strings, queries). Function findClosestStrings(strings: String[], queries: String[]) → String[] Examples Example 1 strings = ["cat","bat","rat"] queries = ["hat","cats"] return = ["bat","cat"] For "hat", all three candidates are one replacement away, so the lexicographically smallest, "bat", is returned. For "cats", deleting the final 's' gives "cat" in one edit. Example 2 strings = ["Apple","apple"] queries = ["apple"] return = ["apple"] The comparison is case-sensitive, so "apple" has distance zero and is selected. Constraints 1 <= strings.length <= 100. 1 <= queries.length <= 50. Every string has length between 1 and 50, inclusive. Candidate strings are distinct. Strings contain printable ASCII characters.
Reported by candidates. Source: FastPrep
Pattern and pitfall
The trick is simple. For every query, compute the Levenshtein distance to every candidate with a 2D DP table where dp[i][j] is the cost to turn the first i characters of one string into the first j of the other. Match costs dp[i-1][j-1], otherwise take 1 plus the min of insert, delete, replace. Track the best (distance, string) pair and compare the string only when distances tie. Pitfalls: forgetting base rows (dp[i][0]=i, dp[0][j]=j), normalizing case when the problem says case-sensitive, and returning the first minimum found instead of the smallest lexicographically. Work is 50 x 100 x 50 x 50, about 12.5 million operations, so no optimization is needed. If the recurrence slips under pressure, StealthCoder is the hedge on the live OA, but the logic is short enough to write cold.
If this hits your live OA and you blank, StealthCoder solves it in seconds, invisible to the proctor.
You can drill Minimum Edit-Distance String for Each Query cold, or you can hedge it. StealthCoder runs invisibly during screen share and surfaces a working solution in under 2 seconds. The proctor sees the IDE. They don't see what's behind it. Built by an Amazon engineer who would have shipped this the night before his JPMorgan OA if he'd had it.
Get StealthCoderRelated leaked OAs
This OA pattern shows up on LeetCode as edit distance. If you have time before the OA, drill that.
You've seen the question.
Make sure you actually pass Target's OA.
Target reuses patterns across OAs. Built by an Amazon engineer who would have shipped this the night before his JPMorgan OA if he'd had it. Works on HackerRank, CodeSignal, CoderPad, and Karat.
Minimum Edit-Distance String for Each Query FAQ
How hard is the Target minimum edit distance OA question really?+
It's medium if you know Levenshtein distance and easy-medium if you've coded it before. The DP is standard. The only extra step is the lexicographic tie-break, which is a single string comparison. Constraints are tiny, so brute force over all candidates works fine.
What's the core trick?+
Run the standard edit distance DP between the query and each candidate. Keep the best distance seen so far. If a new candidate ties on distance, keep whichever string is smaller lexicographically. That's the whole solution.
Do I need to optimize for time?+
No. With at most 100 candidates, 50 queries, and length 50, you're near 12.5 million cell updates. A plain 2D table per pair is fast enough. You can use two rolling rows to save memory, but it isn't required.
What mistakes cost people the most?+
Wrong base cases, off-by-one indexing on the table, and lowercasing strings when the problem says comparisons are case-sensitive. Example 2 tests this directly with Apple and apple. Also don't return the first minimum you find without checking ties.
How do I prepare in 48 hours?+
Write edit distance from memory three times until the recurrence is automatic. Then wrap it in a loop over candidates with the tie-break and test on the two examples. Practice handling empty-ish edge cases like length-1 strings and queries longer than every candidate.