Approaching the Coding Round
Fast recall
Quick revision
Core answer
Whether you follow the process (clarify, example, approach+complexity, code, trace, edge cases) and talk while coding.
Jumping to code before clarifying, or silent coding (interviewer can't follow your thinking).
Clarify -> example -> approach + complexity -> code (idiomatic Ruby) -> trace -> edge cases. Talk while coding; correct before optimal.
Interview-ready guide
Interview answer
I treat a coding problem as a contract first. I restate what must be returned, ask about input size, ordering, duplicates, mutation, invalid input, and whether one or every solution is required. Those details can change the correct data structure and even the meaning of an example.
I then trace a small normal case and an edge case. For a first-duplicate problem, [7, 2, 5, 2] should return 2, while [1, 2, 3] has no result. A direct pairwise search is correct but repeats membership work and can take O(n²).
For example, a one-pass hash can preserve all values already visited. Before storing each value, I check whether its key exists; if it does, the current index and value identify the first duplicate encountered from left to right. The invariant is that the hash contains exactly the earlier values.
I code that version with descriptive names, avoid unrelated abstractions, and talk through each branch while writing. Then I run the examples by hand, including an empty array, a duplicate at the end, repeated nil if nil is permitted, and an input with no duplicate. I fix correctness before polishing syntax.
Finally, I state expected O(n) time and O(n) auxiliary space and explain that the hash trades memory for removed rescanning. If the constraints are tiny, the simpler quadratic version may still be acceptable, but the chosen solution and its boundary are explicit.
Approaching the Coding Round
Direct Answer
A sound coding-round approach makes the problem testable before making it clever: restate the required input and output, clarify constraints, work one small example, describe a correct simple solution, identify its bottleneck, improve only when the constraints require it, then code in short verifiable steps. Finish by tracing normal and edge cases and stating time and auxiliary space. In Ruby, choose clear core collections and do not hide an unexplained algorithm behind a convenient built-in.
Deep Dive & Architecture
Clarification reduces ambiguity, not time. Whether input is sorted can unlock binary search or two pointers; whether the array may be modified determines if in-place sorting is legal; whether original indices are required changes what must be stored. Writing those facts beside the example prevents solving a nearby but different problem.
A baseline gives a correctness reference. Its bottleneck should be named as an operation, such as rescanning earlier values, sorting only to find a minimum, or copying a growing substring. An optimisation is justified when a data structure or invariant removes that operation without changing the contract.
A dry run should track state, not narrate source code. A small table of index, current value, remembered keys, and decision exposes ordering mistakes and off-by-one errors. Edge cases should come from boundaries in the contract rather than a memorised list attached to every problem.
Ruby can make an answer concise, but built-ins need explanation. tally, sort, group_by, or bsearch may be valid when their behaviour and cost match the constraint. Reimplementing every library method wastes time; invoking one without understanding its output, mutation, or complexity hides the reasoning being assessed.
Code Example
def first_duplicate(values)
seen = {}
values.each_with_index do |value, index|
return [index, value] if seen.key?(value)
seen[value] = true
end
nil
end
raise unless first_duplicate([7, 2, 5, 2]) == [3, 2]
raise unless first_duplicate([nil, 1, nil]) == [2, nil]
raise unless first_duplicate([]).nil?
Common Mistakes & Pitfalls
Jumping to code before clarifying, or silent coding (interviewer can't follow your thinking).
Check your understanding
Answer these without looking back at the article.
- Which contract question most often changes the data structure you choose?
- How does an invariant make a dry run more useful than reading code aloud?
- When is a Ruby built-in appropriate in a coding round?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.