Onsite Coding Patterns

Clear the CodeSignal screen and the onsite still has coding rounds waiting, but they change character. Gone is the timed sprint against hidden tests. In its place is a live conversation over a shared editor, one problem at a time, where an interviewer watches how you think as much as what you type. The bar rewards range, not one rare algorithm.

eBay's onsite coding profile is broad and medium-weight. Almost everything sits at LeetCode Medium. Hard problems surface, but rarely, and they are not where the round is won. You are usually expected to land about two problems in the time you have, and interviewers tend to wrap each one in a long story before the real task appears. Clean working code with a unit test or two, plus an honest word about the tradeoffs you made, beats the most optimal Big-O every time.

The round checks range more than depth. eBay runs a large marketplace on Java and Spring microservices, and the daily work spans product listings, search, payments and seller tools. An engineer there touches a lot of surface area, so the interview samples widely rather than drilling one topic to its floor. Expect a medium graph problem, then a string problem, rather than one brutal dynamic-programming puzzle.

The eBay angle

The people who do well here are not the ones with the flashiest single solution. They are the ones who write code an interviewer can read, test it against a case or two without being asked, and then say out loud where it would break or slow down. That is the actual job on an eBay team: ship something clean that a teammate can extend on Monday, and be honest about its limits. So treat the round as a demonstration of engineering judgment, not a race to the lowest complexity. Land your first problem cleanly and completely before you reach for the second.

No single topic dominates. The problems are pooled from a wide set, and the smart move is to be solid across the common ones rather than deep in any one niche. The weight falls like this, heaviest first.

• Arrays, strings, two-pointer, sliding-window: 25 to 30%. The largest single slice. Container-with-most-water and daily-temperatures recur, and so do maximum-subarray and longest-substring-without-repeating. Array rotations and next-permutation turn up too.
• DP and backtracking: 18 to 22%. The second-heaviest group. Word-break and its harder sequel both appear, alongside decode-ways and decode-string. Classic backtracking shows up as n-queens and sudoku-solver.
• Graphs and grids: 12 to 15%. Number-of-islands is the one to expect, sitting next to max-area-of-island. Course-schedule-II and word-search cover the topological-sort and grid-search corners.
• Trees and BST: about 10%. Range-sum-of-BST and kth-smallest-in-a-BST are the typical asks, with vertical-order-traversal saved for a harder day. Nothing here goes past a clean recursion.
• Linked list: 8 to 10%. Merge-two-sorted-lists is the floor, and merge-k-sorted-lists is the step up. Copy-list-with-random-pointer is the one that separates careful coders from quick ones.
• Stack and queue: 8 to 10%. Valid-parentheses is a near-guarantee, sometimes as a warmup. Basic-calculator-II and decode-string are the meatier versions, and a queue-from-stacks design question rounds it out.
• Heap and top-K: about 8%. Small but reliable. A Premium question-elements is the single most repeated problem in the whole onsite pool, so drill it until it is muscle memory. Find-median-from-a-data-stream is the harder heap sighting.

A few design-flavored utilities float around the edges too. Design-a-skiplist has appeared more than once, and an LRU cache is always fair game. These lean less on a clever insight and more on getting the object model right the first time, which is the same muscle the low-level design round tests.

One problem is eBay's own, and it deserves more of your prep than any single item above, because it has a habit of showing up more than once in the same loop. It usually arrives dressed as a feature. You are building autocomplete for a search box or a code editor. A dictionary of words goes in, a user starts typing, and after each keystroke you surface the words that begin with the typed prefix. The story is marketplace-flavored, but the shape underneath never moves. It is a prefix problem, and a trie is the tool built exactly for prefixes.

You could answer it by scanning every word and testing each one against the prefix. That works, and for a small dictionary it is fine, so say so if the interviewer only wants correctness. But eBay will usually push on scale next. A search box calls this on every keystroke against a dictionary that can be huge, and a fresh full scan per keystroke does not hold up. A trie stores the dictionary once as a tree of shared prefixes, so answering a query means walking down the typed letters and then reading off whatever hangs below. That is the version worth building, and the one below.

Build the autocomplete end to end. Insert a handful of words, then return every stored word under a given prefix, sorted so the output is predictable. The edge cases carry the weight here. A prefix that matches nothing should come back empty. A prefix that is itself a full word still counts as its own match. And the empty prefix should hand back the whole dictionary. The live-typeahead follow-up, where the letters arrive one at a time, is worked at the end.

1

Autocomplete: Words Under a Prefix

MediumSignature problem

Problem

Build an autocomplete backed by a trie. Implement an Autocomplete class.

Autocomplete() creates an empty autocomplete with no words in it.
insert(word) adds word to the dictionary. Inserting the same word twice is harmless and leaves a single copy. Returns nothing.
search(prefix) returns every stored word that begins with prefix, as a list sorted in lexicographic order. A word begins with itself, so a prefix that exactly matches a stored word includes that word. If no stored word begins with prefix, return an empty list. If prefix is the empty string, return every stored word.

Input encoding. Each test case is a JSON array of operations. The first is ["Autocomplete", []]; each later entry names a method and its arguments. Every operation records its return value: insert records null, and search records its sorted list of matches.

Input: Autocomplete(); insert("apple"); insert("apply"); insert("apron"); search("ap"); search("app"); search("z")

Output: [null, null, null, null, ["apple","apply","apron"], ["apple","apply"], []]

All three words begin with "ap", returned in sorted order. Narrowing the prefix to "app" drops "apron". The prefix "z" has no matching word, so its search returns an empty list.

How this uses the pattern

Store the words in a trie: a tree where each node is one character and a path from the root spells a prefix. A query walks the prefix once, then gathers every word in the subtree that hangs below.

Autocomplete: Words Under a Prefix

Python

Focus Mode

Loading...

OutputSubmissions

Run

Submit

Click "Run" to execute your code

Test Cases

Input: [["Autocomplete",[]],["insert",["apple"]],["insert",["apply"]],["insert",["banana"]],["search",["app"]]]Expected: [null,null,null,null,["apple","apply"]]

Input: [["Autocomplete",[]],["insert",["apple"]],["insert",["banana"]],["search",["cat"]]]Expected: [null,null,null,[]]

Input: [["Autocomplete",[]],["insert",["app"]],["insert",["apple"]],["insert",["apply"]],["search",["app"]]]Expected: [null,null,null,null,["app","apple","apply"]]

Input: [["Autocomplete",[]],["insert",["dog"]],["insert",["cat"]],["insert",["bird"]],["search",[""]]]Expected: [null,null,null,null,["bird","cat","dog"]]

Input: [["Autocomplete",[]],["insert",["node"]],["insert",["node"]],["search",["no"]]]Expected: [null,null,null,["node"]]

Input: [["Autocomplete",[]],["insert",["car"]],["insert",["card"]],["search",["care"]]]Expected: [null,null,null,[]]

Input: [["Autocomplete",[]],["insert",["ebay"]],["insert",["echo"]],["insert",["ebook"]],["insert",["extra"]],["search",["e"]]]Expected: [null,null,null,null,null,["ebay","ebook","echo","extra"]]

Need a hint? (3 available)

The eBay angle

This is the coding problem most identified with eBay, and it rewards the exact habits the round is looking for. Get a correct answer out first, even the plain scan of every word, and name it as the honest baseline. Then reach for the trie and explain why: a live search box calls this on every keystroke, and re-scanning the whole dictionary each time will not survive the scale eBay runs at. With the trie, a query costs the length of the prefix plus the matches it returns. Walking an interviewer through that tradeoff matters as much as the code.

Take it further

Turn it into a live typeahead. The letters do not arrive all at once. They come one keystroke at a time, and after each one you return the current matches. Re-running the whole prefix search on every keystroke re-walks the same path from the root again and again. The fix is to remember where the last keystroke left you and step down a single edge for the new character. That worked version is below.

Show solution & walkthrough