Practical preparation / algorithms

Coding interview practice: patterns, tests and original worked problems

A disciplined way to prepare for coding interviews without memorizing answer keys: choose a pattern, state an invariant, write runnable code and test the boundary cases.

Start
Clarify the contract
Implement
Correct code first
Finish
Test and explain
Developer working through an original coding exercise with a notebook and editor
Coding practice: an editorial illustration for the preparation path below.

Preparation map

Four moves before the interview

  1. 1

    Read the contract

    Define inputs, outputs, limits, duplicates and failure behavior.

  2. 2

    Choose a baseline

    Explain a correct simple algorithm before optimizing it.

  3. 3

    Name the invariant

    Say what each iteration or recursive call guarantees.

  4. 4

    Test and reflect

    Run edge cases, measure complexity and log the failure mode you missed.

Visual coding practice loop from constraints through approach, implementation, tests and reflection
Repeat the full loop during practice. The point is transferable problem solving, not a count of completed puzzles.

01 / FIELD NOTES

Prepare for evaluation, not for a leaked question

Microsoft and Amazon both publish guidance that emphasizes problem solving, clean working code and testing. The original exercises below follow those skills without copying proprietary question banks or book solutions.

  • A useful practice session has four outputs: the clarified contract, a correct implementation, test cases and a short explanation of complexity and trade-offs. A solved puzzle without those outputs often teaches only recognition.
  • Practice in one strong language. Know collection operations, sorting semantics, integer behavior, string encoding and how to run tests. A second language is valuable only if you can explain it equally well.
  • Use a timed session occasionally, but spend most review time on the step where you failed. If you picked the right algorithm but missed duplicate keys, more random graph problems will not fix your testing gap.
  • Treat problem collections, including popular interview books, as practice material. Do not assume any company will repeat those exact prompts; interviewers can change constraints and ask for reasoning.

02 / FIELD NOTES

Six patterns worth understanding deeply

  • Hash map or set: useful when you need fast membership, counts or joins. State collision-independent complexity assumptions, memory cost and behavior when keys repeat.
  • Two pointers and sliding window: useful for sorted arrays or contiguous segments. Define exactly when each pointer moves and why the window remains valid.
  • Binary search on an answer: use it only after proving monotonicity. Test whether endpoints are feasible and whether your mid-point update can stall.
  • Trees and graphs: choose DFS or BFS based on the property requested. Track visited nodes for cyclic graphs and describe recursion depth or queue memory.
  • Heap or priority queue: useful for top-k or streaming minimum/maximum. Explain which items remain in the heap and why its size is bounded.
  • Dynamic programming: write the state meaning, recurrence, base cases and evaluation order. If you cannot explain the state in one sentence, step back to a smaller example.

03 / FIELD NOTES

A reusable answer template

  • First restate the task and produce two examples. Ask whether ordering, mutation, duplicates and invalid input matter. Do not let a hidden assumption decide the algorithm.
  • Give a simple correct solution and complexity. Propose an improvement only after identifying the actual bottleneck or input bound that justifies it.
  • Write code in small chunks. After each loop or helper, say the invariant. Use descriptive names so your explanation and implementation remain aligned.
  • Run a normal case, minimum input, duplicate or tie case, and a stress-shaped case. If the tool is runnable, execute them rather than declaring them obvious.
  • Finish by saying where the solution can fail: integer overflow, recursion depth, concurrency, memory, or ambiguous requirements. Offer a measured mitigation.

04 / FIELD NOTES

A two-week plan with useful feedback

  • Days 1–4: practice one hash-map and one window problem each day. Review the invariant and tests, not just whether a judge accepted the code.
  • Days 5–8: alternate trees, graphs and binary search. Explain why one traversal or search boundary is correct before coding.
  • Days 9–11: practice heap and dynamic-programming examples, then revisit the two problems that exposed the worst mistakes.
  • Days 12–14: run three timed mocks with a peer. Score contract clarity, code correctness, test quality and communication separately; use the scores to choose the next practice block.

Original practice bank

Three tasks to work through aloud

These are ApplyDjinn practice prompts, not questions obtained from an employer. Use them to rehearse the reasoning and verification expected for the role.

Exercise 1

Sliding window: noisy sensor

Prompt: Find the longest contiguous run of readings whose maximum minus minimum is at most a given threshold.

Approach: Use two monotonic deques for the current minimum and maximum. Extend the right edge; while the difference is too large, advance the left edge and remove expired indices.

Test: Test empty readings, threshold zero, repeated values, descending input and a single extreme outlier.

Follow-up: Why is each reading inserted and removed at most once?

Exercise 2

Graph: dependency release

Prompt: Given package dependencies, return a valid build order or explain why none exists.

Approach: Use indegrees and a queue for topological sorting. Define edge direction carefully; emit nodes only when all prerequisites have been emitted.

Test: Try independent nodes, duplicate edges, a self-cycle and two components with one cycle.

Follow-up: How would you report one actionable cycle rather than only saying the graph is invalid?

Exercise 3

Binary search: capacity

Prompt: Given jobs in a fixed order and a number of days, find the minimum daily capacity that finishes every job.

Approach: Observe monotonic feasibility: if capacity C works, every larger capacity works. Search between the largest job and total work, using a linear feasibility check.

Test: Test one day, one job, an exact boundary and a large sum that could overflow a narrow integer.

Follow-up: What changes if job order can be rearranged?

Source check

Primary sources

Company process details come from these official pages. The exercises and preparation framework are original editorial material; confirm your own interview format with the recruiter.

Continue preparing with evidence

Choose a current role, map its requirements to projects you can defend, then practice the round your recruiter actually scheduled.