Interview guides · Amino

Amino Software Engineer Interview Guide

Amino Software Engineer interview guide: reported API design, debugging and database questions, take-home tips, behavioral prompts and a 7-day plan.

The 60-second brief

Amino is described as a social platform that connects people with information and communities, where users interact, share content and build relationships. The Software Engineer role is reported to cover backend performance, API integrations and features that have to keep working as usage grows. The reported duties mix delivery with collaboration: shaping specifications alongside product managers and designers, reviewing code, keeping client-server APIs healthy, chasing performance problems and shipping tested features. Because the product is social, it helps to practise with social examples such as posts, comments, follower relationships and feeds.

This guide is for candidates preparing for a Software Engineer loop at Amino. It covers the five technical questions candidates report (API design under high concurrency, debugging a production performance bottleneck, database trade-offs for a social platform, a hard-bug story, and keeping code maintainable and scalable), the three reported behavioral prompts, and how to handle the take-home and live coding stages. The reported requirements ask for one backend language, API development and database knowledge without naming a specific language, so use the one you are strongest in.

Candidates describe an opening conversation, then take-home and live collaborative coding assessments, and meetings with team members from individual contributors to leadership. No fixed round count or order is reported, and candidates say the process usually runs a few weeks.

Focus areas

Coding challenges (general)
API design & API-focused coding
Take-home projects/exercises

Overview

The reported topics are practical rather than puzzle-driven. Candidates describe coding challenges, API design with API-focused coding, a take-home project, onsite technical exercises and some whiteboard coding. The reported technical questions are about systems you would actually maintain: an API that must survive heavy concurrent traffic, a slow production service, and the storage choices behind a social product. That makes working code with clear reasoning the center of your preparation, with algorithm trivia a distant second.

The reported skill list is specific. It names RESTful principles and data serialization, testable and modular code, Git and CI/CD pipelines, caching, load balancing and database optimization, plus decoupled, resilient services built for high availability. Build a concrete answer for each of those: a small API you can walk through with explicit request and response schemas, a cache you can justify (what is cached, who invalidates it, what staleness is acceptable), and a database choice you can defend against a named access pattern.

The take-home deserves its own preparation. Candidate reports describe it as a place where coding practice, documentation and independent reading of requirements show, and they say asking clarifying questions about scope during the take-home or live sessions is acceptable. Have a starter repository ready, write a README that lists your assumptions and trade-offs, and keep a short list of the questions you would send about an ambiguous brief.

The behavioral side is tied to the product-team setting the role describes. The three reported prompts cover changing course after product manager feedback, disagreeing with a teammate on technical direction, and leading a project across functions. Prepare each as a story in which you made a real decision, because the job described involves translating product needs into technical specifications alongside product managers and designers.

Where to focus your preparation

No numbered round sequence is reported, so this guide treats the loop as one preparation focus built from the stages candidates describe. Ask your recruiter for the order and format before you commit your preparation time.

Preparation focus

Candidates report a first call, then hands-on technical work: a take-home and live coding done jointly with the team. They also report meeting a range of team members, from individual contributors to leadership. The reported topic areas are coding challenges, API design and API-focused coding, take-home exercises, onsite technical exercises and whiteboard coding. Because the order is not reported, prepare every stage: have a working starter repository for the take-home, practise thinking aloud while you code, and keep your design vocabulary (idempotency, caching, sharding, replication) ready for the conversation-style questions about APIs, production debugging and databases. Before the loop begins, ask the recruiter which stages apply and which language and tools you may use.

What to demonstrate

Working, readable, tested code on practical tasks, in the take-home and in live sessions
API design fundamentals: REST conventions, data serialization and robust integrations
Reasoning about caching, load balancing and database optimization for a high-traffic social product
How clearly you explain the reasoning behind a technical choice and ask about requirements

How to prepare

Build a small REST service (for example posts and comments) with tests, a README of assumptions and a CI workflow, so the take-home format is familiar
Rehearse aloud the five reported technical questions: high-concurrency API design, production performance debugging, database trade-offs for a social platform, a hard-bug story and keeping code maintainable
Practise writing code without autocomplete while narrating your choices, since whiteboard coding appears in the reported topics
Prepare three behavioral stories and two questions about the team's engineering practices for the conversations with the team and leadership

Where candidates lose points

Answering the high-concurrency API question with a list of endpoints and no handling of overload, retries or duplicate writes

Cover the failure paths explicitly: stateless handlers behind a load balancer, rate limiting, pagination limits, idempotency keys so a retried write does not create a duplicate, caching for hot reads, and what the API returns when it is overloaded. The idempotency fingerprint practice drill is a direct rehearsal.

Naming a database product for the social platform question without tying it to an access pattern

List the operations first (publish a post, read a home feed, list followers, count likes, search), then say which store suits each and what it costs in consistency, joins, sharding key and replication lag. State where staleness is acceptable and where it is not.

Answering the production performance question with a guessed fix such as adding a cache before measuring anything

Start with the symptom and its metrics, check what changed (deploys, traffic mix, a dependency), narrow by endpoint, host or query, profile or read the query plan, and only then change something. Say how you would verify the fix and roll it back.

Submitting a take-home that runs but has no tests, no README and no stated assumptions

Treat the submission as a review artefact: small modules, tests for the main paths and edge cases, a CI workflow, and a README that explains how to run it, what you assumed where the brief was silent, and what you would do with more time. Send clarifying questions early instead of guessing.

Telling a behavioral story in terms of what the team did, with no decision of your own and no result

For each of the three reported prompts, write the story in Situation, Task, Action, Result form, name the decision you personally made, include the outcome, and cut the background to a couple of sentences.

Questions & practice

Walk me through a challenging technical bug you encountered and how you resolved it.

Medium · Technical Proficiency and Problem Solvin

Approach

Pick a bug with a real mechanism (a race condition, a cache that was never invalidated, a timezone or DST boundary, an off-by-one in cursor pagination, a connection leak). Open with the symptom and its impact in a sentence or two.
Show the narrowing: the hypotheses you held, the evidence that ruled each one out, and how you got a reliable reproduction. Mention a minimal failing case, added logging, or git bisect, which finds the bad commit in about log2(n) steps. git bisect run automates it: exit 0 marks the commit good, 1-127 except 125 marks it bad, 125 skips it, and any code above 127 aborts the bisect, so a script that crashes or is killed stops the run instead of marking the commit bad.
Explain the root cause at the level of mechanism, not just the line you changed. For a race, give the interleaving that breaks; for a cache bug, the write path that skipped invalidation.
Justify the fix: why it removes the cause rather than hiding the symptom, the alternatives you rejected, and how you confirmed it in production (the metric or log line that went quiet).
Close with prevention: the regression test that fails without the fix, plus any alert, lint rule or code-review check you added. Use 'I' for your own actions and credit others accurately.

Follow-up

How did you know the fix addressed the root cause and not just one trigger?
What would have caught this bug before it reached users?
If you could not reproduce it locally, how would you have continued?

Canonicalise a request body into a stable idempotency fingerprint

Medium · parsing · canonicalisation · hashing

idempotency_key.request_fingerprint is a SHA-256 over the method, path and canonicalised body, and a retry whose fingerprint differs must be rejected with 422 rather than served the stored response. Write the canonicaliser. Bodies are JSON up to 256 KB nested at most 32 levels; clients vary key order, whitespace and unicode escaping, and some send 64-bit ids as JSON numbers. Produce a deterministic byte string such that semantically identical bodies match and any semantic difference does not. State your complexity and name two normalisations you refuse to perform.

Approach

Parse once into a tree, then re-serialise under fixed rules: object keys sorted, array order preserved, one escaping convention, no insignificant whitespace. Parsing is O(n) and sorting keys is O(k log k) per object, so O(n log n) overall with O(depth) stack, and the 32-level cap is enforced during parsing because hostile nesting is how a canonicaliser becomes a stack overflow.
Sort keys by their UTF-8 bytes and say why the obvious implementation is wrong in some runtimes: a default string comparison that orders by UTF-16 code units places surrogate pairs, meaning code points from U+10000 up, below U+E000 to U+FFFF, which is not UTF-8 byte order, so two services written in different languages disagree on the same document.
Do not re-encode numbers through a double. IEEE-754 binary64 represents integers exactly only up to 2^53, so normalising a 19-digit id through a float changes it, and 1 against 1.0 cannot be reconciled without deciding whether they are the same value. Preserve the literal token, and require ids as strings at the API boundary if you want them comparable.
Reject duplicate keys rather than picking one. JSON permits them and parsers disagree, most keeping the last, so any choice you make ties the fingerprint to a parser detail that the code handling the request does not necessarily share.

Follow-up

A client sends the same logical request with an extra field your API ignores. Same key, different fingerprint, so you return 422. Is that the right answer?
Where does the fingerprint get computed relative to request decompression and the body-size limit?

Identify the heaviest tenants in a five-minute window under memory pressure

Medium · top-k · heavy hitters · streaming

The edge service handles about 3,000 requests per second across roughly 50,000 tenants, peaking near 9,000. Expose the 50 heaviest tenants by request count over the trailing five minutes so limits can be tightened before one tenant's backfill starves the fleet. You may not retain five minutes of raw records. Give the exact solution and its memory, then the bounded-memory approximation with its error stated as a formula, and say which you would ship and at what tenant cardinality that choice changes.

Approach

Do the exact version first, because it is affordable at this cardinality: a ring of 300 one-second counters per tenant, advanced lazily, is 1,200 bytes of counters per tenant and roughly 60 to 90 MB for 50,000 tenants with overhead. Carry a running total and subtract the bucket you overwrite so a window read is O(1) rather than 300 adds.
Extract the top 50 with a size-k min-heap over the tenant sums: O(d log k) for d tenants, against O(d log d) to sort them all. Maintaining the heap continuously instead of on query requires a tenant-to-heap-index map, because incrementing a count already inside the heap means sifting from a known position, and without that map you rebuild the heap on every request.
State the approximation precisely rather than gesturing at sketches. Misra-Gries with m counters retains every item whose true count exceeds N/(m+1), and each retained count underestimates the truth by at most N/(m+1). With m = 1,000 and N = 900,000 requests in the window the error is roughly 900 requests, which is fine for spotting a tenant sending 50,000 and useless for ranking two tenants 200 apart.
Say what breaks when the window slides: Misra-Gries and Space-Saving are insert-only and cannot be decremented as records age out. The workable construction is one summary per sub-window, say ten seconds, with 30 summaries merged at query time, and the merged error is the sum of the per-summary errors, so the bound degrades linearly in the number of sub-windows.

Follow-up

The heaviest tenant is heavy because of one export job rather than user traffic. Should the limiter treat those as the same tenant?
Two tenants sit tied at the boundary of the top 50. Does your answer flap, and does the flapping matter?

Explain why the owner filter ignores the listing index

Medium · composite index · query plans · sort elimination

The only index on resource is (tenant_id, status, updated_at DESC, resource_id DESC). A new endpoint returns one user's resources across all statuses, newest created first: WHERE tenant_id = $1 AND owner_user_id = $2 ORDER BY created_at DESC LIMIT 20. On a tenant with 2M rows it takes 900 ms and EXPLAIN shows a sort above a large scan. Explain precisely why the existing index cannot serve it, give the index that can, and state which of these the new index still will not help: owner_user_id alone across tenants; the same query ordered by updated_at. PostgreSQL 16.

Approach

Separate the two jobs an index does. For filtering, a composite btree is seekable only on a left prefix, so with no predicate on status the scan can at best range over tenant_id and test owner_user_id per row; PostgreSQL 16 has no btree skip scan to jump the unconstrained column.
For ordering, the index is sorted by (status, updated_at) within a tenant and not by created_at, so the LIMIT cannot stop early: every matching row is read and then sorted. That is the 'Sort Method: top-N heapsort' line, and it is why the plan reads 2M rows to answer with 20.
Derive the replacement from the access path — equality, equality, then the ordering column: CREATE INDEX CONCURRENTLY ON resource (tenant_id, owner_user_id, created_at DESC). The scan seeks to the (tenant, owner) range and walks 20 entries in order, so the Sort node disappears along with the row-read.
Treat INCLUDE (title, status) as conditional, not free. An index-only scan still visits the heap for any row whose page is not marked all-visible, so on a table taking 1.2k writes/second the win depends on autovacuum keeping the visibility map current, and the wider index costs more on every insert.

Follow-up

90% of rows are status='active'. Would a partial index WHERE status = 'active' change your answer, and for which of the three queries?
A dashboard runs this for 40 owners in one page load. What changes about the design?

Hold a per-tenant active cap against concurrent creates

Hard · write skew · isolation levels · constraints

A tenant on the standard plan may hold at most 50 resources with status='active'. The create handler runs SELECT count(*) FROM resource WHERE tenant_id = $1 AND status = 'active', compares to 50, then inserts. Two creates arrive 3 ms apart on different instances and the tenant lands at 51. Name the anomaly, say whether PostgreSQL 16 READ COMMITTED or REPEATABLE READ prevents it and why, then give an implementation that holds the cap at READ COMMITTED with the exact statements. Finally, say what changes when the cap is 'at most one running export per tenant' on job_run.

Approach

Name it: write skew. The two transactions read an overlapping set and write disjoint rows, so there is no row-level conflict for the engine to detect and each commit is individually legal.
Rule out the levels precisely. READ COMMITTED takes a fresh snapshot per statement and takes no lock on the counted rows, so both see 49. PostgreSQL's REPEATABLE READ is snapshot isolation: it removes non-repeatable reads and phantoms within the snapshot but still admits write skew, because the anomaly is not a re-read of a changed row, it is a read of a set that a concurrent transaction invalidates. Only SERIALIZABLE closes it, by tracking the read dependency and aborting one transaction with SQLSTATE 40001 — a guarantee that exists only if the application re-runs the whole transaction from the read.
Convert the set predicate into a single-row conflict: keep tenant.active_resource_count and run UPDATE tenant SET active_resource_count = active_resource_count + 1 WHERE tenant_id = $1 AND active_resource_count < 50 in the same transaction as the INSERT. Zero affected rows is the cap, returned as 409. The row lock serialises the decision at any isolation level, and contention is bounded to one tenant's row — which is also the fair-scheduling unit, unlike a global counter that would convoy every tenant behind one row.
State the cost you just took on: a counter is a second source of truth that can drift, so every path that changes status must adjust it inside the same transaction, and a periodic reconciliation has to exist, with resource_revision as the authority for what the count should have been.

Follow-up

A resource moves from archived back to active. Which statements change, and what breaks if the counter update and the status change land in different transactions?
The cap becomes plan-dependent and a plan can change mid-month. Where does the number 50 live, and who reads it?

How would you design an API to handle high-concurrency requests?

Medium · Technical Proficiency and Problem Solvin

Approach

Pin down the load before drawing boxes: peak requests per second, read/write ratio, latency target and which operations must never run twice. Then keep app servers stateless behind a load balancer so they scale horizontally, with all state in the database and cache.
Make writes safe under retries and races. A client-supplied idempotency key goes in a table with a unique constraint and the stored response, so a retried POST returns the first result. Use optimistic concurrency (UPDATE ... WHERE id = ? AND version = ?, or ETag with If-Match returning 412) to catch lost updates without holding locks.
Take load off the read path with cache-aside in Redis plus TTLs, and coalesce requests (a single-flight lock per key) so an expired hot key does not stampede the database. Bound the DB connection pool, because extra app instances cannot push past the database's own connection limit.
Protect the service with per-client token-bucket rate limiting that returns 429 with Retry-After, timeouts on every downstream call, and bounded queues. Move slow work to an async queue and return 202 Accepted with a status URL.
For hot counters such as likes, avoid read-modify-write in application code. Use an atomic UPDATE SET n = n + 1, or shard the counter across N rows and sum them, accepting a slightly stale total in exchange for less lock contention.

Follow-up

Two clients edit the same resource at the same moment: how does your API detect the conflict, and what does the losing client see?
The cache cluster restarts at peak traffic. What protects the database from the miss storm?
How long do you keep idempotency keys, and what happens when a retry arrives after the key has expired?

What are the trade-offs between different database architectures for a social platform?

Medium · Technical Proficiency and Problem Solvin

Approach

Start from access patterns, not products: profile lookups, the follow or membership graph, posts and comments per community, feeds, like counters, chat messages and search. Feeds are read-heavy, while likes and messages are write-heavy.
Relational (PostgreSQL, MySQL) gives ACID transactions, joins, foreign keys and secondary indexes, which suit users, memberships and moderation. Read replicas scale reads but usually replicate asynchronously (the default in PostgreSQL and MySQL), so you need a plan for read-your-writes. Synchronous or semi-synchronous replication is the alternative: fresher replicas in exchange for higher write latency. Scaling writes means sharding by a key such as user or community id, and cross-shard joins then move into application code.
Wide-column and key-value stores (Cassandra, DynamoDB) scale writes horizontally and suit timelines or messages keyed by (conversation_id, time bucket) with clustering by timestamp. The cost: each table is designed around one query, there are no joins, and a very large community or account becomes a hot partition unless you add a bucket or salt to the key.
Add derived stores for the queries the primary store handles badly: a search index (Elasticsearch/OpenSearch) and a Redis cache fed by change data capture, with eventual consistency as the trade-off. For multi-hop graph queries, choose between a graph database and an adjacency table plus precomputation.
For feeds, compare fan-out on write (precomputed inboxes, fast reads, expensive for accounts with huge followings) with fan-out on read (cheap writes, slow reads). Then describe the hybrid that pulls high-follower posts at read time.

Follow-up

How would you partition posts so one very large community does not overload a single shard?
How do you keep the search index consistent with the primary database, and what does a user see during the lag?
When would you add read replicas rather than shard, and when would you pay for synchronous replication?

How do you ensure your code remains maintainable and scalable as a product evolves?

Medium · Technical Proficiency and Problem Solvin

Approach

Draw clear boundaries: keep domain logic in pure functions or services, apart from I/O (HTTP handlers, repositories, external clients), and inject dependencies so the logic can be unit-tested without a network or database.
Back changes with layered tests: fast unit tests on business rules, integration tests against a real database, and contract tests on the API. CI runs them on every pull request, and code review checks naming, error handling and test coverage of edge cases.
Evolve APIs compatibly: additive fields only, never reuse a field with a new meaning, version or deprecate when a break is unavoidable. For schemas, use expand/contract in this order: add a nullable column, deploy dual-writes to both columns, backfill historical rows, verify they match, switch reads, stop writing the old column, then drop it. Backfilling before dual-writes start leaves any row created or updated in the gap stale in the new column, and the read switch would then serve wrong data.
Ship behind feature flags and add observability (structured logs, metrics, traces), so a change can be rolled out gradually and turned off without a redeploy.
Name the trade-off: premature abstraction costs as much as duplication. Wait for the second or third real use case before extracting a shared module, and profile before restructuring code for scale.

Follow-up

Tell me about an abstraction you added that later made the code harder to change. What would you do instead?
How would you rename a database column that a live API reads, without downtime?
How do you decide when to pay down technical debt rather than ship the next feature?

Explain your process for debugging a complex performance bottleneck in a production environment.

Medium · Technical Proficiency and Problem Solvin

Approach

Quantify the symptom before forming theories: which endpoint, p50 versus p99 latency, error rate, and when it started. Line that start time up against deploys, config changes, traffic shifts and dependency incidents.
Locate the bottleneck from the top down. Use RED metrics (rate, errors, duration) per service and USE (utilization, saturation, errors) per resource, then distributed traces to find the span that dominates the slow requests.
Narrow it by type. CPU-bound work gets a low-overhead sampling profiler and flame graph (py-spy, async-profiler or pprof). Database time gets the slow query log, EXPLAIN ANALYZE, N+1 query patterns, missing indexes and lock waits in pg_stat_activity. Also check GC pauses and connection-pool wait time.
Use Little's law (concurrency = throughput x latency) to explain pool exhaustion: if a dependency's latency doubles at the same request rate, in-flight requests double and a fixed-size pool starts queueing.
Mitigate first (roll back, scale out, turn off a feature flag, shed load), then reproduce with production-like data, fix, and check the fix against the same percentile that alerted. Finish with a regression test or alert so the problem cannot come back silently.

Follow-up

Latency is up but CPU and memory look flat. Where do you look next?
How do you profile a live service without making the incident worse?
The slowdown only appears at peak traffic and you cannot reproduce it in staging. What do you do?

Suggested practice checklist

Day 1 — Confirm the format and build a take-home starter kit

Write to your recruiter asking which stages apply, whether a take-home is included, which languages are allowed and what tools the live coding session uses.
Create a reusable starter repository in your strongest backend language with Git history, a test runner, a CI workflow that runs the tests, and a README template with sections for how to run, assumptions and trade-offs.

Deliverable: A sent message to your recruiter with those questions, and a starter repository that passes CI with one sample test.

Day 2 — API design under high concurrency

Answer the high-concurrency API question aloud, covering stateless handlers, rate limiting, pagination, idempotency keys for retried writes, caching hot reads and what the API does when overloaded.

Deliverable: A one-page design for a create-post endpoint that handles retries, limits and overload, plus both drills solved.

Day 3 — Database trade-offs for a social platform

List the access patterns of a social product (publish a post, read a home feed, list followers, count likes, search) and map each to a relational, document, wide-column, graph or cache choice.
Answer the database architecture question aloud, naming the sharding key, the replication mode and lag you accept and where you need strong consistency.

Deliverable: A table mapping each access pattern to a storage choice and its cost, plus a written explanation of the index drill.

Day 4 — Production debugging and the hard-bug story

Write a one-page runbook for a slow production service: confirm the symptom in metrics, check recent changes, narrow by endpoint, host or dependency, profile or inspect query plans, form a hypothesis, then verify the fix and plan the rollback.
Answer the production performance bottleneck question aloud, using the runbook.
Pick one real bug from your history and write it up as symptom, how you narrowed it, root cause, fix and the check that prevents a repeat.

Deliverable: A debugging runbook and a written hard-bug story you can tell aloud.

Day 5 — Maintainable code, serialization and a take-home rehearsal

Answer the maintainability and scalability question aloud with concrete practices: module boundaries, tests, code review habits, documentation, expand/contract schema migrations and feature flags.
Build a small REST service for posts and comments from a written brief in your starter repository, with tests and a README that lists your assumptions.
Define request and response schemas for the posts API with validation, pick a JSON field naming convention and a null-versus-absent policy, and show with a test how adding a new field stays backward compatible for older mobile clients.

Deliverable: A pushed repository with passing CI, a README and validated request/response schemas with a compatibility test, plus the solved drill.

Day 6 — Behavioral stories

Write the three reported prompts as Situation, Task, Action, Result stories: pivoting after product manager feedback, disagreeing with a teammate's technical direction and leading a cross-functional project.
Say each story aloud and cut it until your own decision and the outcome come early.
Prepare two backup stories: a time you asked clarifying questions on an ambiguous requirement, and a time code review feedback changed your design.

Deliverable: Three written stories and two backup stories, each naming the decision you made and the result.

Day 7 — Mixed mock and product review

Run a mixed mock: answer one API design question aloud, write one coding exercise without autocomplete while narrating your choices, then tell one behavioral story.
Use the Amino product, note two technical areas you would want to understand better (for example feeds or notifications), and write two questions for the team about their engineering practices.

Deliverable: A completed mock with notes on what to fix, and your two questions for the team.

Behavioral stories for Amino

The reported behavioral prompts cover changing course after product manager feedback, disagreeing with a teammate over technical direction, and leading cross-functional work. Those match the role as described: engineers work with product managers, designers and other engineers and turn user needs into technical specifications. Prepare real stories where you made a decision, and structure each with Situation, Task, Action, Result.

Tell me about a time you asked clarifying questions on an ambiguous requirement and it changed what you built.
Describe a time feedback in a code review changed your design.

Describe a time you had to pivot your approach based on feedback from a product manager.

Medium · Behavioral and Team Collaboration

Approach

Pick a story where product feedback changed something concrete in your design or plan, such as an API shape, a scope cut, a rollout order or a data model, and say what it was in one sentence.
Lay it out as Situation, Task, Action, Result: the original plan and why you chose it, the feedback and what the product manager knew that you did not (usage data, a deadline, a customer constraint), then your evaluation of it.
Show that you tested the feedback instead of simply giving in or pushing back: you checked it against data, a prototype or a cost estimate, and then made the call yourself.
Describe the change in specifics: what you reworked, what you kept, how you limited wasted effort (a feature flag, a smaller first release, a revised spec), and the outcome with a number or an observable result if you have one.
Avoid the stories that sink this answer: one where the product manager was simply wrong, one where you only followed instructions, or one with no outcome. End with what you now do earlier, such as sharing a design sketch before building.

Follow-up

How did you decide the feedback was right instead of just accommodating the request?
What did the pivot cost in rework, and how did you keep that cost small?
What would you do to get that product input earlier next time?

How do you handle situations where you disagree with a teammate’s technical direction?

Medium · Behavioral and Team Collaboration

Approach

Choose a real technical disagreement with a clear subject, such as a schema design, a queue versus direct calls, a library choice or a testing strategy, and describe both positions fairly. If your account of the other person's view sounds weak, the story will too.
Start with what you did to understand their reasoning: you asked what constraint or past incident drove their preference, and you agreed on the criteria for deciding (latency, operational cost, reversibility, time to ship).
Move the disagreement from opinion to evidence: a small benchmark, a spike, a written comparison in a design doc, or a review with a third engineer who owns the affected area.
State how it was resolved. Either the evidence settled it, or the person who owned the decision made the call and you committed fully. Say what you did afterwards to help the chosen approach succeed.
Avoid stories where you simply won the argument, where you escalated before talking to the person, or where nothing was learned. A story where you turned out to be wrong, and said so, is stronger than a clean win.

Follow-up

What if they were still unconvinced and the decision was not yours to make?
Tell me about a time you were the one who turned out to be wrong.
How do you raise a design concern in a code review without stalling the work?

Tell me about a project you led that required cross-functional collaboration.

Medium · Behavioral and Team Collaboration

Approach

Pick a project where you set direction, not just contributed, and name the functions involved (product management, design, other engineering teams, possibly operations or support). State the goal and what success looked like before you describe the work.
Show your own decisions: how you turned the product brief into a technical plan, what you cut or sequenced, how you split work among engineers, and where you made a trade-off between scope, speed and quality.
Describe how you kept the groups aligned: a shared spec or design doc, a regular status update, an agreed definition of done, and how you explained technical constraints to people outside engineering in plain terms.
Include one point of friction, such as conflicting priorities, a late requirement change or a dependency on another team, and exactly how you handled it.
Close with the result and what you would change: shipped on schedule or not, the measurable effect, and one process improvement you took to the next project. Say what you personally did, not only what the team did.

Follow-up

How did you handle a stakeholder who changed requirements late in the project?
Give an example of explaining a technical limit to a non-engineer and how they responded.
What would you change about how you ran the project if you did it again?