Thoughtworks-Style Machine Coding Round: Format, Tips & Practice Problems
Written and reviewed by Sahil Srivastav
Consulting-style engineering rounds often reveal design through a small evolving requirement. Rounds in the style of Thoughtworks assess whether the code stays clear as rules change, whether tests describe behaviour, and whether the candidate can make trade-offs visible.
The practice problems are Gronex originals; they are chosen for refactoring and domain clarity rather than company-specific claims.
What a Thoughtworks-style machine coding round looks like
Expect a deliberately scoped domain such as pricing, workflow, booking, or billing. Implement a working slice, then absorb one or two changes without losing tests.
The strongest approach is a thin vertical increment: make one behaviour work, protect it with tests, and refactor when the next rule exposes a seam.
Do not hide behind abstractions. A small model with names that match the contract is easier to review than a framework of speculative interfaces.
How you’re evaluated
Behavioural tests
Tests express the rules and protect the next change.
Simple domain model
Names and boundaries make the business language readable.
Refactoring judgement
Duplication is removed when it becomes a problem, not before.
Communication
Assumptions and trade-offs are explained alongside the implementation.
Common mistakes that fail this round
- Building abstractions for requirements that do not exist.
- Testing private methods instead of behaviour.
- Leaving the first design untouched after the rules change.
- Ignoring invalid inputs because the happy path works.
- Optimising before measuring the stated need.
Quick tips for the room
- Start with a thin vertical slice.
- Let tests name behaviour.
- Refactor after the next rule arrives.
- Keep assumptions visible.
How to prepare
Take a small pricing or workflow repository and make one red test green at a time.
Practise narrating why each abstraction exists and what requirement would justify changing it.
Practice problems in the Thoughtworks-style round format
Each is a real backend repository with a failing test suite — the same working-code standard the round applies. Open the brief and read the full problem, no signup required.
Notification Preference & Delivery
Rules that evolve by channel. Free to try.
Open the challenge →FAQ
Were these Thoughtworks questions?
No. They are Gronex originals in the style of collaborative design and coding rounds. Gronex is not affiliated with Thoughtworks.
Should I use TDD?
Use tests to make the contract executable and guide the next change; the exact order is less important than feedback.
How much architecture is enough?
The smallest structure that makes the current behaviour clear and the next stated change affordable.
What should I say while coding?
State assumptions, the invariant under test, and why a new seam is justified.
Related
Gronex is not affiliated with, endorsed by, or sponsored by Thoughtworks. All company names and trademarks belong to their respective owners. The problems on this page are Gronex originals written in the style of such interview rounds — not actual interview questions from Thoughtworks.