Aaratech Software Engineer Interview Guide

The 60-second brief

Candidates report no specific Aaratech product or domain, so this guide does not guess at one. The posted role description refers to software solutions delivered to clients and mentions working with product, design and operations teams. The languages it lists are Java, Python, C++ and JavaScript, with React and Node.js named as example frameworks.

This guide is for engineers interviewing for the Software Engineer role at Aaratech. It follows the three reported rounds, gives answer guidance for all fifteen reported questions, technical and behavioral, and builds a seven-day plan around them: synchronous versus asynchronous programming, API design, scaling a web application, troubleshooting a system failure, ensuring software quality and the behavioral stories. The role description says candidates typically have a computer science or related background and about 2-5 years of software development experience.

Candidates report three rounds over roughly three to five weeks: an Initial Screening Call, Technical Assessments, and Interviews with Management. The technical stage may include coding challenges and system design discussions, and the final stage covers technical and behavioral ground.

Focus areas

• Past Experience Articulation
• Project Experience Discussion
• Behavioral Interviewing

Overview

The reported questions fall into three groups. Technical and domain questions ask about concepts and your own track record: a hard problem you solved, synchronous versus asynchronous programming, Git, a time you optimized code, and how you ensure software quality. Behavioral questions cover conflict with a teammate, leading a project, juggling deadlines, motivation and handling feedback. Case-study questions ask you to reason about a system failure, design an API, scale a web application, decide with incomplete information and break down complex problems.

Several of the technical-sounding questions are really experience questions. Git, optimizing existing code and a challenging technical problem all ask for something you did, so they are answered with a specific story that contains numbers, a decision and a result. Prepare them the way you prepare behavioral answers, then add the technical detail underneath: the commands, the profiler output, the data structure you changed.

The role description candidates see lists database management and data modeling as must-haves, with cloud platforms (AWS, Azure), front-end technologies and CI/CD as nice-to-haves. That is a reason to be ready to sketch a schema when you design an API, to explain how you would deploy and monitor what you designed, and to have a fluent language among Java, Python and JavaScript for any coding challenge.

Because the final stage is reported to cover both technical and behavioral competencies, nothing you prepare is wasted if it is concrete. The most reusable asset is a short inventory of three or four projects, each with one hard problem, one optimization, one disagreement and one decision made with partial information. Most of the reported questions can be answered from that inventory.

The Aaratech interview process

Candidates describe three stages, in this order, over about three to five weeks. Formats can vary by team, so treat the stages as a map and confirm the details with the recruiter.

Initial Screening Call

Candidates describe this first call as a conversation about your background and whether the role suits you. Nothing technical is reported for it, so the preparation is about telling your history clearly. Be ready to connect your experience to the languages and tools the role lists (Java, Python, C++, JavaScript, databases and data modeling), to name the projects you would want to talk about later, and to ask what the technical assessments will involve and how they are scheduled.

What to demonstrate

• Your background and fit for the role
• How you describe your past experience

How to prepare

• Write a short walk through your last two or three roles, naming the stack, your own contribution and one result for each
• Pick one project to go deep on and be ready to explain what you built, why it was designed that way and what you would change now
• Prepare questions about the format of the technical assessments, such as which language you can use and whether a system design discussion is included

Technical Assessments

Candidates report that this stage may include coding challenges and system design discussions. Reported example scenarios elsewhere in the process include choosing a sorting approach for a large dataset, debugging a performance problem in production, designing an API and scaling a web application. Plan for working code in your strongest language, a spoken design built from requirements, and explanations of core concepts such as synchronous versus asynchronous programming.

What to demonstrate

• Coding challenges and algorithmic knowledge
• System design discussion and problem-solving approach
• Debugging and troubleshooting technique

How to prepare

• Solve coding problems aloud in Java, Python or JavaScript, saying the complexity and edge cases before you finish
• Rehearse the API design question: clients, resources and endpoints, request and response shapes, error handling, pagination, auth and the underlying tables
• Write a one-page answer to scaling a web application: stateless app servers behind a load balancer, caching, database indexing and replicas, queues for slow work, and what you would measure first
• Practise a debugging narrative for a failing system: what changed, what the metrics and logs say, how you narrow it down, how you mitigate before you fix

Interviews with Management

Candidates describe final interviews with management that cover technical and behavioral competencies. The reported behavioral questions are about conflict with a teammate, taking the lead on a project, prioritizing against several deadlines, motivation and feedback, and the case-study set includes a decision made with incomplete information. Prepare to explain the options you rejected and why for each project you discuss.

What to demonstrate

• Technical and behavioral competencies
• Your past experience and the projects you discuss

How to prepare

• Prepare one story each for conflict with a teammate, leading a project, prioritizing multiple deadlines, receiving feedback and deciding with incomplete information
• Rehearse the quality answer: tests at several levels, code review, CI checks, monitoring and how you respond when a bug reaches production
• Be ready to talk about your Git workflow and one optimization, with the before and after numbers
• Prepare a clear reason for wanting this role that refers to the work you have done, not a generic statement about the company

Where candidates lose points

Defining synchronous versus asynchronous programming in a sentence and stopping

Give an example in a language you use: a blocking call that holds a thread while it waits, against a callback, promise, async/await or thread-pool version that lets other work proceed. Say when each fits, such as I/O-bound work or a UI that must stay responsive, and mention the cost of errors and ordering in the asynchronous version.

Answering the Git question with a list of commands instead of a workflow

Describe your branching model, how reviews and CI gate a merge, your rule for merge versus rebase, and one real recovery or bisect episode. Experience is the point of the question.

Telling an optimization story with no measurements

State the baseline number, how you found the hotspot, what you changed and the same measurement afterwards. Practise one story until the before and after figures come without notes.

Jumping to technologies when asked to design an API or scale a web application

Start with who calls the service and what it must do, then walk through resources and endpoints, the data model, caching, queues and the first thing you would measure. Name tools only after the requirement that justifies them.

Behavioral answers that say "we" throughout or blame a colleague

For the conflict, leadership, feedback and decision stories, state the choice you made, the evidence you used and what you changed afterwards. Describe the other person's reasoning fairly, even when you disagreed.

Questions & practice

Explain the difference between synchronous and asynchronous programming.

Medium · Technical / Domain Questions

Approach

1. Define it by what the caller does. A synchronous call blocks until the result is ready. An asynchronous call starts the operation and returns at once, and the result arrives later through a callback, a promise or future, or an await point.
2. Keep async separate from parallelism. In JavaScript and Python asyncio, one thread runs an event loop, and an await hands control back to the loop while I/O is pending. Concurrency comes from interleaving, not from extra cores.
3. Say where it helps: I/O-bound work like many network or database calls, where one thread can keep thousands of requests in flight. CPU-bound work gains nothing. Move it to worker threads, processes or a job queue, because a long computation blocks every other task on the loop.
4. Name the common bugs. A blocking call inside a coroutine (time.sleep or a synchronous HTTP client in asyncio) stalls the whole loop, so use asyncio.sleep or asyncio.to_thread. A promise nobody awaits loses its error. Promise.all rejects on the first failure, while Promise.allSettled waits for every result.
5. Give a small example. Three independent API calls awaited one after another take the sum of their latencies. Started together and awaited with Promise.all or asyncio.gather, they take about the slowest one.

Follow-up

• What happens to other requests if a Node.js handler runs a CPU-heavy loop, and how would you fix it?
• How would you run ten calls concurrently but limit it to three in flight at a time?
• How do you handle a timeout or a partial failure when several async calls run together?

Archive a resource graph without breaking live references or recursing

Medium · graph traversal · topological order · tenant isolation

Resources reference other resources within a tenant; for the largest tenant the reference table holds up to 2,000,000 nodes and 8,000,000 edges. Archiving a resource must archive everything reachable from it that nothing outside the set still references, refuse when a live external referrer exists, and terminate when references form cycles, which they legitimately do. Produce the archive order and the refusal list, targeting O(V+E). Say what stops the traversal crossing a tenant boundary, and why recursion is the wrong control structure at this size.

Approach

1. Load the subgraph with the tenant predicate on both endpoints of the edge, not only on the side you started from. Scoping the left table alone is the classic cross-tenant leak: one mis-entered edge then pulls another tenant's resources into the traversal and, worse, into the archive.
2. Traverse iteratively with an explicit stack. A 2,000,000-node graph can hold a chain deep enough to exhaust a native stack in the low tens of thousands of frames, and that failure is a process crash rather than an error you can return.
3. Treat cycles as data rather than corruption: compute strongly connected components with Tarjan in O(V+E) using its own explicit stack, then condense. The condensation is a DAG, so a topological order over it gives the archive order, and every member of a component archives in one transaction because no order within a cycle is valid.
4. Decide refusals with reverse edges. A candidate is archivable only if every in-edge originates inside the candidate set, so build the transpose or count in-degrees restricted to the visited set, and emit each blocked resource with the id of the external referrer, which is the only part of the answer an operator can act on.

Follow-up

• The graph is read in one query and the archive writes a minute later. What can change in between, and how do you make the write safe?
• The candidate set is 400,000 resources. Is that one transaction, and if not, what does a half-finished archive look like to a reader?

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

1. 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.
2. 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.
3. 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.
4. 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?

Denormalise tenant onto revisions and backfill it live

Hard · denormalisation · online migration · backfill

resource_revision (revision_id, resource_id, version, actor_user_id, change_kind, patch, request_id, created_at) has 400M rows and no tenant column; tenant_id lives only on resource. Two reads need it: a tenant-scoped audit feed ordered by created_at DESC, and an offboarding purge. Both join back to resource today. Justify adding tenant_id to resource_revision against those two reads, name the anomaly the copy introduces and the constraint that prevents it, then give the ordered migration for a live table taking 1.2k writes/second — the lock each step takes, how the backfill is batched, and where each step stops being reversible. PostgreSQL 16.

Approach

1. Justify from the access path rather than from taste. Without the column, the audit feed either scans resource_revision by created_at and discards other tenants' rows, or resolves the tenant's resource_ids first and probes with them — both proportional to the tenant's whole history rather than to one page. With (tenant_id, created_at DESC, revision_id DESC) it is a seek that stops at 50 rows, and the purge becomes a ranged delete instead of a join.
2. Name the cost exactly: a second copy of a fact can disagree with the first. Make the disagreement unwritable rather than documented — add UNIQUE (resource_id, tenant_id) on resource so it can serve as a foreign-key target, then FOREIGN KEY (resource_id, tenant_id) REFERENCES resource (resource_id, tenant_id) on the revision table. A revision can then only ever carry its parent's tenant.
3. Step one, expand: ALTER TABLE resource_revision ADD COLUMN tenant_id BIGINT NULL, with no default, so it is a catalogue change and no rewrite. It still needs ACCESS EXCLUSIVE for an instant, and that instant queues behind the longest open transaction on the table while every later query queues behind it — set lock_timeout to 2s and retry rather than wait.
4. Step two, dual-write: deploy the writer that populates tenant_id on every new revision while reads still use the join. Reversible by redeploying the previous build, because nothing reads the column yet.

Follow-up

• The backfill is half finished and a rollback is required. What state is the table in, and what does the previous build do with a half-populated column?
• How do you verify the backfill actually finished, given rows are still being inserted while it runs?

Write the update path that detects a concurrent edit

Medium · optimistic concurrency · transactional outbox · audit history

resource carries version INT NOT NULL DEFAULT 1. resource_revision holds revision_id, resource_id, version, actor_user_id, change_kind, patch JSONB, request_id, created_at with UNIQUE (resource_id, version). outbox_event holds aggregate_type, aggregate_id, aggregate_version, event_type, payload, status. A PUT carries the version the client read. Write the exact statements for the single transaction that applies the edit, records the revision and enqueues 'resource.updated', and give the handler's branch on zero affected rows. Then say what PostgreSQL 16 does under READ COMMITTED when two of these updates hit one row at once.

Approach

1. One transaction, three writes, no network call inside it: UPDATE resource SET title = $3, version = version + 1, updated_at = now() WHERE resource_id = $1 AND tenant_id = $4 AND version = $2; then INSERT the resource_revision row at version $2 + 1; then INSERT the outbox_event row at the same aggregate_version. The event goes to a table rather than a broker because no transaction spans both.
2. Branch on the affected-row count before doing anything else. Zero has three causes — stale version, wrong tenant, row gone — so re-read once and map to 409 carrying the current version, or 404 for an id outside the caller's tenant, which also stops the endpoint confirming that another tenant's id exists.
3. State the engine behaviour instead of assuming it. Under READ COMMITTED the second UPDATE blocks on the row lock, and when the first commits PostgreSQL re-evaluates the WHERE clause against the newly committed row, so the version predicate now fails and the statement reports zero rows. Under REPEATABLE READ the identical collision raises SQLSTATE 40001 instead, so the handler must fold both shapes into one conflict response.
4. Keep UNIQUE (resource_id, version) even though the predicate already serialises writers. It is what makes a lost update unwritable if any other path ever reaches the revision table, and it converts a logic bug into 23505 rather than into a silently missing history row.

Follow-up

• A client sends the version it read ten minutes ago and the resource has moved three versions. What is in your 409 so it can resolve the conflict without a full re-fetch?
• Two editors, two disjoint fields, no overlap. Does your answer still refuse the second write, and should it?

Describe a challenging technical problem you solved in your last role.

Medium · Technical / Domain Questions

Approach

1. Pick one problem with a measurable symptom (a p99 latency spike, a race that corrupted records, a memory leak) where you owned the diagnosis, and open with the impact in one sentence: who was affected and how badly.
2. Name the real constraint that made it hard: it only reproduced under production load, the code was unfamiliar, or a fix could not take downtime. Without one, the story sounds routine.
3. Walk through the hypotheses in order, including the ones you ruled out and the evidence that ruled them out (a profiler trace, a log correlation, a failing test that reproduced it). That sequence is the technical content of the answer.
4. State the fix and the trade-off it carried (a lock that cost throughput, a cache that added staleness, a schema change that needed a backfill), then the before-and-after number and the regression test or alert you added.

Follow-up

• What would you have done if your first fix had not changed the metric?
• How did you confirm the root cause and not just a correlated change?
• What would you design differently now so the problem could not recur?

How do you ensure the quality of your software?

Medium · Technical / Domain Questions

Approach

1. Answer in layers, each with a concrete practice: unit tests for pure logic, integration tests against a real database or service container for the boundaries, and a few end-to-end tests for the main user flows. More of the cheap tests, fewer of the slow ones.
2. Put the gates in CI so they run on every pull request: tests, linting, type checks or static analysis, and a build. Then add code review with a clear purpose (correctness, readability, missing tests), not style debates a formatter can settle.
3. Treat every bug fix as a test: write the failing test that reproduces it first, then the fix, so the same regression cannot ship twice. Coverage is a signal for finding untested code, not a target to hit.
4. Cover what happens after merge: feature flags or staged rollouts so a bad change reaches few users, error tracking and dashboards on error rate and latency, and a rollback path you have actually tested.
5. Back it with one real example: a defect your tests or review caught, or one that escaped, and the check you added so it would not escape again.

Follow-up

• How do you deal with a flaky test that fails one run in twenty?
• What would you test at the unit level versus the integration level for a payment or order endpoint?
• How would you ship a risky database migration safely?

How would you design an API for a specific service?

Medium · Problem-Solving / Case Studies

Approach

1. Since the service is left open, pick one concrete example (an orders or bookings service, say) and clarify who calls it, the core operations, read and write volumes, and the consistency each operation needs before naming any endpoint.
2. Model resources as nouns and use HTTP semantics correctly. GET is safe and idempotent, PUT and DELETE are idempotent, and POST is not. Return precise status codes: 201 with a Location header on create, 400 for malformed input, 404, 409 for a state conflict, 429 when rate limited.
3. Handle the hard cases explicitly. Offset pagination slows down on deep pages and can skip or repeat rows when data changes, so use cursor pagination for long lists. Accept an idempotency key on POST so a retried create does not duplicate. Use an ETag with If-Match to reject concurrent overwrites with 412.
4. Cover the cross-cutting pieces: authentication (OAuth 2.0 tokens or API keys) and per-resource authorisation, rate limits per client, a consistent error body with a machine-readable code, and versioning (a URL prefix or header). Additive changes stay backward compatible, and removals need a new version.
5. State the trade-off you chose, for example REST for broad client compatibility against gRPC for typed, low-latency service-to-service calls, and say how you would document the contract (an OpenAPI spec) and test it.

Follow-up

• A client's POST times out and it retries. How does your API avoid creating the record twice?
• How would you roll out a breaking change to a field that existing clients depend on?
• When would you choose GraphQL or gRPC over REST for this service?

If you had to scale a web application, what considerations would you take into account?

Medium · Problem-Solving / Case Studies

Approach

1. Start by measuring. Load-test or profile to find the actual bottleneck (app CPU, database queries, a downstream call) and set a target such as requests per second at a given p99 latency, so each change is judged against it.
2. Make the app tier stateless so it can scale horizontally behind a load balancer. Move sessions to a shared store like Redis or to signed tokens, add health checks, and autoscale on a metric that tracks load.
3. Cut work before adding hardware. Serve static assets from a CDN, cache hot reads with cache-aside and a TTL, and be clear about invalidation and stampedes on hot keys (request coalescing, or jittered expiry).
4. Scale the database in steps: fix slow queries and N+1 patterns, add indexes, pool connections, then add read replicas, whose replication lag can break read-your-writes. Shard or partition only when writes outgrow one primary, and name the partition key and the cross-shard queries it makes expensive.
5. Move slow or bursty work (emails, image processing, reports) onto a message queue with background workers. Add rate limiting and graceful degradation so a traffic spike slows the app down instead of taking it offline.

Follow-up

• A popular cache key expires and hundreds of requests hit the database at once. What do you do?
• A user updates their profile and the next page shows old data. What could cause it, and how do you fix it?
• The database primary is write-bound and read replicas no longer help. What are your options?

What techniques do you use to approach complex problems?

Medium · Problem-Solving / Case Studies

Approach

1. Restate the problem and define done: inputs, outputs, constraints, and what success is measured by. Many complex problems shrink once the actual requirement is written down.
2. Decompose it into parts you can solve and test on their own, and order them by risk, tackling the part most likely to invalidate the plan first. Work small concrete examples and edge cases (empty input, duplicates, very large inputs) by hand before writing code.
3. Get a simple correct version working first, then optimise against a measurement, saying the complexity of each version. For bugs, reproduce reliably, then bisect: comparing a working and a failing state, or git bisect across commits, halves the search each step.
4. Write down assumptions and check each one cheaply (read the code or docs, add a log line, run a quick experiment) instead of reasoning on top of an unverified guess. Timebox dead ends, and bring a specific question when you ask for help.
5. Tie it to one real case: the problem, how you broke it down, where your first decomposition was wrong, and what result the approach produced.

Follow-up

• Tell me about a time your first breakdown of a problem turned out to be wrong. How did you notice?
• How do you decide when to keep digging and when to ask someone for help?
• How do you explain the approach to a teammate who has to pick up half of the work?

Given a hypothetical scenario of system failure, how would you approach troubleshooting?

Medium · Problem-Solving / Case Studies

Approach

1. Scope the impact first: which users, endpoints or regions, since when, and whether it is total failure or degradation. Then mitigate before hunting the root cause. Roll back the latest deploy, turn off the feature flag, fail over or shed load.
2. Ask what changed around the start time: deploys, config or infrastructure changes, traffic shape, a dependency's status, certificate or credential expiry. A change at the onset time is the strongest early lead.
3. Read the signals in a fixed order. For services, check request rate, error rate and latency. For resources, check CPU, memory, disk, connection pools and queue depth for utilisation and saturation. Then follow one failing request through logs or traces by its request id to find the first component that errs.
4. Test one hypothesis at a time, and pick checks that rule out half the candidates either way (does it fail on one host or all of them, on one dependency or every one). Watch for cascades such as retry storms, which exponential backoff with jitter, timeouts and circuit breakers contain.
5. Close the loop: confirm the fix with the same metric that showed the failure, then write a blameless postmortem with the timeline and root cause, plus the alert, test or limit that would catch it earlier next time.

Follow-up

• Latency has doubled but the error rate is flat. Where do you look first?
• The logs show database connection-pool timeouts. What are the possible causes, and how would you tell them apart?
• How would you tell a real cause from something that only changed at the same time?

Suggested practice checklist

The plan follows the three reported rounds: one day to map the loop and your project inventory, four days of technical preparation (concepts, coding, databases and API design, scaling and troubleshooting), and two days of behavioral stories and a full mock across all three stages.

Day 1 — Map the loop and inventory your projects

• Write the three reported stages (Initial Screening Call, Technical Assessments, Interviews with Management) and next to each one list the question types from this guide you expect to prepare for it
• List three or four projects with stack, your role, one hard problem, one optimization, one disagreement and one decision made with partial information
• Write the answer to why this role, based on work you have done, and a list of questions to ask about the technical assessments

Deliverable: A one-page loop map plus a project inventory with the four story slots (hard problem, optimization, disagreement, decision with partial information) filled for each project.

Day 2 — Core concepts: async, Git, quality and team practice

• Write an explanation of synchronous versus asynchronous programming with a short code example in Java, Python or JavaScript, covering blocking, concurrency, error handling and when each fits
• Write your Git answer: branching model, merge versus rebase rule, how you recover from a bad reset, and how you use bisect
• Outline how you ensure software quality: unit and integration tests, code review, CI checks, monitoring and your response to a production bug
• Write short answers on managing dependencies (lockfiles, version pinning, upgrade cadence) and on communicating clearly in a remote team, since the role lists Agile and DevOps practice

Deliverable: Four spoken-ready answers on paper: sync versus async with code, a Git workflow with one real episode, a quality checklist, and dependency management plus remote communication.

Day 3 — Coding and algorithms

• Write a short answer on choosing a sorting approach for a large dataset: in-memory sort versus external merge sort, stability, and nearly-sorted input

Deliverable: Two solved practice problems with spoken complexity notes, plus a half-page comparison of sorting approaches.

Day 4 — Databases, data modeling and API design

• Design an API for a service of your choice: resources, endpoints, request and response shapes, pagination, errors, auth and the tables behind it
• Write the schema with keys and indexes and say which query each index serves

Deliverable: A written API specification with a schema and index list, and two worked SQL practice problems.

Day 5 — System design and troubleshooting

• Write the scaling answer for a web application: stateless servers, load balancing, caching layers, database indexes and replicas, queues and what you would measure first
• Map that scaling design onto managed cloud services (load balancer, managed database with replicas, queue, CDN) and a CI/CD deploy pipeline, since the role lists AWS or Azure and CI/CD as nice-to-haves
• Rehearse a failure walkthrough aloud: what changed, what the logs and metrics show, how you narrow down the cause, how you mitigate and how you confirm the fix
• Write your own method for breaking down a complex problem, using a past project as the example

Deliverable: A one-page scaling checklist with its cloud and CI/CD mapping, a troubleshooting runbook you can recite, and a problem-decomposition example from your own work.

Day 6 — Behavioral stories

• Write and say aloud the stories for a conflict with a teammate and for leading a project, each with your own decisions, the evidence you used and the outcome
• Write the answers on prioritizing several deadlines and on handling feedback, including the example of feedback that changed how you work
• Cut each story to a version that fits a short spoken answer, keeping the decision and the result

Deliverable: Four stories with a one-line summary each, rehearsed aloud until they run without notes.

Day 7 — Full mock across the three stages

• Run a mock of the screening call, then a technical block, then a management-style block, speaking every answer aloud
• In that mock include the challenging-problem, optimization, motivation and incomplete-information questions, using the project inventory
• Review the weakest answer, rewrite it and say it again

Deliverable: A recorded or written mock covering all three stages, with a list of the answers you rewrote.

Stories to prepare for the management round

Candidates report that the final stage is with management and covers both technical and behavioral competencies. The reported behavioral questions ask about conflict, leading a project, prioritizing deadlines, feedback and decisions under uncertainty, so each needs a story with your own decision, the evidence behind it and the result. Prepare them from your project inventory so the same projects support several answers.

What is your experience with version control systems like Git?

Medium · Technical / Domain Questions

Approach

1. Answer with how you actually work, not a list of commands: your branching model (short-lived feature branches off main, or trunk-based with feature flags), how pull requests and reviews fit in, and how your history is kept readable.
2. Explain merge versus rebase with a rule you follow: rebase local work to keep history linear, merge shared branches, and never rewrite history others have pulled. Mention squash merges and when you prefer them.
3. Show you can recover from trouble: resolving a conflict by reading both sides and re-running tests, git reflog after a bad reset, revert for a bad commit already on a shared branch, cherry-pick for a hotfix.
4. Add one debugging use, such as git bisect to find the commit that introduced a regression, and tie Git to CI so each pull request is built and tested before merging.
5. Close with one real episode, for example a messy merge you untangled or a release you cut from a tag, so the answer is experience rather than a tutorial.

Follow-up

• When would you rebase instead of merge, and when is rebasing a bad idea?
• Someone force-pushed over a shared branch. How do you recover the lost commits?
• How would you find which commit introduced a bug when you have hundreds of commits to search?

Can you discuss a time when you optimized an existing piece of code?

Medium · Technical / Domain Questions

Approach

1. Open with the symptom and the baseline: the slow endpoint, job or function, and the measured number (latency, memory, query time) before you touched anything. Without a baseline the story has no result.
2. Say how you found the hotspot: a profiler, flame graph, query plan or logging, not intuition. Typical real causes are a nested loop over a list that should be a set or map, repeated queries inside a loop, a missing index, repeated work that could be cached, or loading far more data than needed.
3. Describe the change in terms of complexity or resource use, for example turning an O(n^2) lookup into a hash-based one or batching many queries into one, and what you did to keep behavior identical, such as running existing tests and comparing outputs on real inputs.
4. Report the after number using the same benchmark, then the cost: added memory, cache invalidation risk or less readable code, and why you accepted it.
5. Mention how you stopped the regression returning, such as a benchmark in CI or a dashboard alert.

Follow-up

• How did you know that part of the code was the bottleneck and not something else?
• What did the optimization cost in readability or memory, and was it worth it?
• How would you check that the faster version returns exactly the same results?

Tell us about a time when you had a conflict with a teammate. How did you resolve it?

Medium · Behavioral / Leadership

Approach

1. Choose a real disagreement about something that mattered, such as a design approach, a review comment or how to split work, not a personality clash with no substance. Keep the situation to two or three sentences.
2. Show your first move was to understand their position: you asked questions, restated their reasoning and found the goal you both shared, such as shipping safely or keeping the code maintainable.
3. Describe how you moved from opinion to evidence: a small prototype, a benchmark, a written comparison of the options, or bringing in a third person for input. Say what you personally did, not what the team did.
4. State the outcome plainly, including when you were the one who changed your mind, and what the working relationship looked like afterwards.
5. Avoid the stories that sink this answer: blaming the other person, a conflict you never resolved, or a resolution that was only that you went along with them.

Follow-up

• What if the teammate still disagreed after you showed the evidence?
• When would you escalate to a manager, and how would you do it?
• What would you do differently if the same disagreement came up today?

Describe a project where you took the lead. What challenges did you face?

Medium · Behavioral / Leadership

Approach

1. Pick a project where you owned outcomes, even without a title: you set the plan, made calls and answered for the result. State the goal, the people involved and your role in two or three sentences.
2. Show the mechanics of leading: how you broke the work into pieces, who took which part, how you kept everyone aligned with product managers and designers, and how you tracked progress and risk.
3. Name two or three real challenges and what you did about each, such as unclear requirements, a teammate who fell behind, a technical risk you de-risked with a spike, or scope growing mid-project.
4. Use "I" for your decisions and "the team" only for team results, so it is clear what you contributed.
5. End with the result and one lesson, for example how you would scope or communicate differently next time.

Follow-up

• How did you handle a teammate who was struggling or falling behind?
• What did you decide to cut when scope grew, and who agreed to that?
• How did you keep stakeholders informed without overloading them?

How do you prioritize tasks when you have multiple deadlines?

Medium · Behavioral / Leadership

Approach

1. Give your method first: list everything with its deadline, then rank by impact, urgency, dependencies and the cost of delay if it slips. Say you re-check the ranking when something new arrives.
2. Back it with a real example of two or three competing deadlines: what they were, what you did first and why, and what you deferred or cut.
3. Show that prioritizing includes communication: you told product managers or other stakeholders what would slip, offered options such as a smaller scope, and got agreement rather than quietly missing a date.
4. Cover practical handling: protecting time for the highest-impact task, asking for help early when a deadline looks unreachable, and splitting work into shippable increments.
5. Avoid answers that amount to working longer hours or saying yes to everything; those suggest no prioritization happened.

Follow-up

• Two deadlines are equally important and belong to two different managers. What do you do?
• How do you tell a stakeholder that something will be late?
• How do you decide whether to cut scope or ask for more time?

What motivates you to perform at your best?

Medium · Behavioral / Leadership

Approach

1. Answer honestly and specifically: name two or three things that actually drive your best work, such as solving a problem users feel, mastering something difficult, owning a feature end to end or working with people you learn from.
2. Support each with a concrete moment, for example a bug that took days to isolate and what keeping at it felt like, or a feature you saw used by real users.
3. Connect it to the work the role description lists: building features, improving existing systems, reviewing code and fixing issues that affect users. Make the link through your experience rather than praise of the company.
4. Show it is sustainable by saying what you do when motivation dips, such as breaking the work into smaller wins or asking for feedback.
5. Avoid vague answers such as passion for technology, and avoid answers that are only about money or title.

Follow-up

• Tell me about a time your motivation dropped. What did you do?
• What kind of work drains you, and how do you handle it when it is part of the job?
• How do you stay motivated on maintenance or bug-fix work?

How do you handle feedback and criticism?

Medium · Behavioral / Leadership

Approach

1. Describe one specific piece of critical feedback you received, such as review comments that your code was hard to test or a manager saying your updates were unclear, and who gave it.
2. Explain your first reaction honestly and what you did next: you asked clarifying questions, separated the substance from the delivery and decided what to change.
3. Show action and follow-through: the concrete change in how you work (smaller pull requests, a test-first habit, a written status note) and how you checked with the person that it helped.
4. Add how you give feedback, for instance in code review: specific, about the code, with a suggested alternative.
5. Do not claim you have never received criticism, give a fake weakness like working too hard, or tell a story where the feedback was simply wrong.

Follow-up

• Tell me about feedback you disagreed with. What did you do?
• How do you give critical feedback to a colleague in a code review?
• What is the most useful piece of feedback you have received, and what changed afterwards?

Describe a time you had to make a critical decision with incomplete information.

Medium · Problem-Solving / Case Studies

Approach

1. Set the stakes and the gaps: what had to be decided, by when, and which facts you did not have. Make the decision a real one with a cost to getting it wrong, such as a release call, an architecture choice or an incident mitigation.
2. Explain how you reduced the uncertainty cheaply: a quick spike or measurement, asking the person who knew most, or finding the one fact that would change the decision.
3. Say how you limited risk: choosing the reversible option, using a feature flag or staged rollout, setting a checkpoint to revisit, and writing down your assumptions so they could be checked.
4. State the decision, who you informed, and the outcome, including what you learned if the assumption turned out wrong.
5. The mistake to avoid is a story where you waited for certainty, or where luck rather than reasoning made it work.

Follow-up

• What was the one piece of missing information that worried you most?
• How did you make the decision easy to reverse?
• If you had waited another day, what would have changed?