The Intercom Interview: Minicom and Data Modeling
Intercom's engineering loop leans on two distinctive rounds: Minicom, a long live-coding session on a real starter repo, and a data-modeling interview that evolves a schema screen by screen. We are not going to reveal the actual tasks here, since the value is in seeing them ahead of time. What this guide does is tell you exactly what each round looks like and how to prepare so nothing on the call is a surprise.
Two rounds that decide the loop
Most of the Intercom engineering signal comes from two rounds. We will not reproduce the tasks, because the whole point of preparing is to know them in advance. Instead, here is precisely what each looks like and how to walk in ready.
The Minicom live-coding round
Minicom is a long live-coding interview, not a take-home. You are handed a real starter repository that simulates a simplified Intercom, with a customer site, an admin site, and a server, and you implement features on the call while an engineer watches. Expect roughly 45 minutes on your own followed by 45 minutes pairing.
What to expect:
- You pick your stack: the repo ships with Rails, Spring, Node, and Django scaffolds, so you work in whichever you know best.
- The first block is solo implementation; the second is pairing, where the interviewer probes your choices and pushes follow-ups.
- You are expected to think out loud the whole time.
- AI editors are allowed, but over-reliance is explicitly judged. Let the AI scaffold; you make the decisions.
The probe areas the interviewer follows up on are consistent: reading an unfamiliar codebase quickly and finding the seams, adding a feature without breaking existing behavior, writing tests at the right granularity, and trading off speed against correctness under time pressure. Prepare by doing exactly that on any medium codebase you have never seen, narrating as you go. The specific features you will be asked to build are listed in our bank.
The data-modeling round
This is a system-design interview focused entirely on a relational data model. You are told it is a normal monolith with one relational database, and the interviewer shows you a UI screen, asks you to model just enough to support it, then reveals another screen and asks you to evolve the model. It repeats across several escalating stages.
What to expect:
- An ERD-style answer: entities, attributes, relationships, and explicit cardinalities.
- A standing rule to model only what the current screen needs and to avoid fields or entities nothing uses yet.
- Requirements that grow each stage, so your earlier model has to bend rather than be rewritten.
- Follow-ups on how data flows when users and admins interact with each screen.
The discipline being graded is restraint and timing: introduce an entity exactly when a screen forces it, keep cardinalities correct as relationships get more complex, and reason about read performance as lists and inboxes appear. Prepare by practicing incremental schema design and the standard moves it leans on (when to split out a new entity, when a relationship becomes many-to-many and needs a join table, and when to denormalize to avoid N+1 reads). The exact screens and the full stage-by-stage question are in our bank.
How Intercom scores these rounds
| Dimension | Weak | Strong |
|---|---|---|
| Codebase fluency | Gets lost in unfamiliar code | Finds the seams fast and changes the right place |
| Safe change | Breaks existing behavior | Adds a feature without regressions, tests at the right level |
| AI judgment | Lets the editor drive design | Uses AI for scaffolding, owns the decisions |
| Incremental modeling | Over-models or rewrites each stage | Models only what the screen needs, evolves cleanly |
| Cardinalities | Vague or wrong relationships | Correct 1-to-many and many-to-many as complexity grows |
| Communication | Works in silence | Thinks out loud and justifies trade-offs |
Knowing the format is half the battle; knowing the exact Minicom features and the precise screens in the data-modeling round is the other half, and that is what the bank gives you.
The exact tasks are in the bank
Get the full Intercom question bank
We do not print Intercom's actual tasks here, because what makes the prep work is having the exact screens and features in advance. The full bank carries the complete Minicom feature set and the entire multi-stage data-modeling question, with the rubric, compiled from people familiar with the process and cross-verified across sources.
Intercom interview FAQ
What is the Intercom Minicom round?+
A long live-coding interview (not a take-home) on a provided starter repository that simulates a simplified Intercom. You implement features on the call while the interviewer watches, typically around 45 minutes solo followed by 45 minutes pairing with an engineer.
What is the Intercom data-modeling interview?+
A system-design round where you design the relational data model for a chat product. The interviewer reveals a UI screen at a time and you evolve the schema to support it, modeling only what each screen needs. The full multi-stage question is in our bank.
Can I use AI tools in the Intercom Minicom round?+
Intercom permits AI assistance but explicitly evaluates whether you over-rely on it. Drive the design and logic yourself and let an AI editor handle scaffolding and boilerplate, not the decisions.
How do I prepare for the Intercom interview?+
For Minicom, practice reading an unfamiliar codebase fast, adding a feature without breaking existing behavior, and testing at the right granularity while thinking out loud. For data modeling, practice incremental ERD design with correct cardinalities. The exact tasks to rehearse against are in our bank.
Where can I find the real Intercom interview questions?+
Pichup maintains an Intercom question bank compiled from people familiar with the process, with the complete Minicom feature set and the full data-modeling question, their follow-ups, and the rubric.