The Ais process does not follow the usual multi-round coding loop. Candidates report that it opens with a block of standardized tests: IQ, EQ, general aptitude and, in some cases, an English communication test and a long psychometric questionnaire. They also report that you must pass these tests before you get a panel invitation. Your resume does not count until then, so treat timed puzzle practice as real preparation, not an afterthought.
The panel that follows mixes technical managers, supervisors from other departments and an HR representative. Candidates describe it as more conversation than live coding: you explain how you would run a schema change without downtime, sketch an SMS delivery pipeline that handles millions of messages a day, describe how you test your APIs and walk through a production bug you fixed. Because part of the panel is non-technical, every technical answer needs two layers. Give the mechanism (expand-and-contract migrations, queues with idempotent workers, a test pyramid) and the user impact in one plain sentence.
The behavioral half of the panel is unusually direct about logistics and preferences. Reported questions ask what daily tasks you want, how you choose between requests from supervisors in different departments, how you used feedback, and why you want to move to Ais. Prepare these as seriously as the system design question. Settle your own answers about role preferences, working arrangements and salary before the panel, because the offer discussion with HR picks up the same topics.
For the technical content, use the stack candidates list for the role. Pick one backend language you can talk about fluently (Java, Python, Node.js or Go), know one relational and one non-relational database well enough to explain locking, indexing and consistency, and be able to describe how a containerized service moves through CI/CD to production.
Assessment Phase
reportedCandidates describe this stage as a set of standardized tests: IQ (pattern and sequence reasoning), EQ (situational judgment about colleagues and conflict), general aptitude (arithmetic and data interpretation) and, for some candidates, an English communication test and a psychometric personality questionnaire. Some also mention a short technical knowledge test, and candidates report that it covers the baseline coding checks rather than the panel. The reported questions for this phase are a missing-shape sequence, a request-growth percentage calculation, an empathy judgment item and a technical-passage summary. Candidates report that passing these tests is required before a panel invitation. Approach it as a speed-and-accuracy exercise: have a fixed checklist for pattern items, do percentage arithmetic without a calculator, and answer judgment and personality items the same way throughout, not the way you guess is wanted.
What to demonstrate
- Pattern recognition on shape sequences and matrices under a time limit
- Arithmetic and percentage reasoning, such as compounding growth in request load
- Situational judgment about teammates, deadlines and disagreement (the EQ items)
- Reading a technical passage in English and restating its core problem in your own words
How to prepare
- Do three timed sets of sequence and 3x3 matrix puzzles, using the attribute checklist (count, rotation, reflection, shading, position) from the missing-shape question
- Drill compound-percentage arithmetic: 1.15^3, doubling time with the rule of 72, and the hour at which load crosses a capacity limit
- Work through situational-judgment sets and write down why the best option combines empathy with a concrete recovery plan
- Summarize two architecture blog posts or incident reports in three sentences each, without reusing their phrasing
Panel Interview
reportedCandidates report a single panel of two to three people, usually technical managers plus an HR representative, with cross-departmental supervisors in some panels, lasting 30 to 60 minutes. Candidates say it centres on practical experience, how your background matches the job description, and your career preferences, with little or no live coding. The reported technical questions cover zero-downtime database migrations, designing a backend for millions of daily SMS notifications, API unit and integration testing, and a severe production bug. The reported HR questions cover job preferences, conflicting priorities between departments, constructive feedback, and why you want to join Ais. Because one panel holds both audiences, structure each technical answer as a one-sentence summary, then the mechanism, then the result or risk in business terms, so that the non-engineers can follow it too.
What to demonstrate
- Backend knowledge explained without a compiler: schema migrations, queue-based system design, API testing
- Real production experience, told as a clear diagnosis-and-fix story
- Communicating with a mixed technical and non-technical panel in English
- Fit between your stated preferences and goals and the role's reported duties
How to prepare
- Rehearse a single-diagram SMS notification design: API, durable queue, priority lanes, idempotent workers, gateway rate limits, delivery receipts
- Explain the expand-and-contract migration sequence aloud in under two minutes, including lock timeouts and batched backfills
- Write a STAR outline for one production incident and one feedback story, each with a measurable result
- Write one-paragraph answers on preferred daily tasks, handling competing supervisor requests, and why Ais, and say them aloud
Offer Discussion
reportedCandidates report that HR contacts successful panel candidates to discuss salary expectations, benefits and contract details. Nothing is reported about technical content at this stage. Treat it as a negotiation and a fact-finding call. Arrive with a researched range for your level and location, your priorities among benefits and working arrangements, and the contract questions you need answered before you accept. Your answers should match the preferences you gave the panel, since HR asks about preferences there too.
What to demonstrate
- Clarity and consistency of your salary expectations and priorities
- Understanding of the contract terms and benefits you are offered
How to prepare
- Research a salary range for your level and city from independent sources and decide your floor before the call
- List the benefits and contract points you need answered: contract type, probation, working arrangement, start date
- Reread your panel answers on job preferences and career goals so your offer-stage requests match them
PracHub editorial advice for the preparation topics above.
Treating the IQ, EQ and aptitude tests as a formality and arriving without timed practice
Candidates report that the tests gate the panel. Do timed sets of sequence puzzles and percentage arithmetic beforehand, have a per-item time budget, and arrive rested, because the full battery can run for several hours.
Answering the SMS design or migration question with a list of technologies and no flow
Walk the request path in order: API, idempotency key, queue, priority lanes, workers, gateway, delivery receipts. For migrations: expand, dual-write, backfill, switch reads, contract. Name one failure mode for each step and how you handle it.
Losing the non-technical half of the panel with jargon
Open each technical answer with one plain sentence of user or business impact before the mechanism. Example: 'I needed to change the schema without users seeing errors, so I did it in five reversible steps.' Practise this on someone outside engineering.
A production-bug story that skips mitigation or credits the team with every action
Say what you did to stop the impact first (rollback, flag, failover), then the diagnosis sequence, then the guard you added. Use 'I' for your own actions and give at least one number for impact or recovery.
Vague or inconsistent answers about job preferences, priorities and career goals
Write down your preferred daily work, your flexibility, your three-to-five-year goal and your salary range before the panel. HR asks about preferences in the panel and returns to salary and benefits at the offer stage, so the answers must match.
Choose a category, try a prompt, then open its approach, worked solution or follow-up when you need it.
What are your primary preferences regarding your job description and daily tasks?
What are your primary preferences regarding your job description and daily tasks?
Approach
- Base your answer on the duties candidates report for the role: backend services and APIs, database work, performance monitoring, production troubleshooting, CI/CD and cross-department projects. Say which of these you most want to own and give a recent example of doing it.
- Give a real preference with a reason, for example 'I want most of my week on API and data-layer work, and I am comfortable sharing production support.' Avoid 'anything is fine', which tells the panel nothing.
- State your flexibility explicitly: what you are happy to pick up (QA collaboration, some front-end integration, learning telecom domain knowledge) and what you would want to grow toward.
- Have your logistics answers ready (working arrangement, location, start date), since HR on the panel may ask about them, and keep them consistent with what you will say at the offer stage.
Follow-up
- Which of the role's tasks would you enjoy least?
- How do you feel about handling production issues outside working hours?
- Would you be open to working on front-end integration if the team needed it?
Archive a resource graph without breaking live references or recursing
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
- 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.
- 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.
- 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.
- 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?
Canonicalise a request body into a stable idempotency fingerprint
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?
Denormalise tenant onto revisions and backfill it live
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
- 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.
- 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.
- 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.
- 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?
Hold a per-tenant active cap against concurrent creates
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?
Identify the missing shape in this logical sequence.
Identify the missing shape in this logical sequence.
Approach
- Check one attribute at a time, in a fixed order: number of elements (sides, dots, lines), rotation per step (often 45 or 90 degrees), reflection, shading or colour alternation, and position moving around a grid.
- For 3x3 matrices, test row rules and column rules separately. Common ones: each row holds one of each shape, the third cell is the overlay of the first two, or the third keeps only the lines the first two do not share (XOR).
- Look for two interleaved series: odd positions following one rule and even positions another is a frequent trick in linear sequences.
- Eliminate answer options per attribute instead of hunting for the right one. Once two attributes are fixed, usually one option survives.
- Set a per-item time budget. If no rule emerges after two attributes, mark your best elimination and move on, since the reported tests are timed.
Follow-up
- The row rule and the column rule point to different answers. Which do you trust, and why?
- How would you spot a sequence where two separate rules apply to alternating positions?
- With 20 seconds left, how do you choose between the last two options?
[Math/Logic] If a server processes 500 requests per minute and traffic increases by 15% every hour, what is th
[Math/Logic] If a server processes 500 requests per minute and traffic increases by 15% every hour, what is the load after 3 hours?
Approach
- Read '15% every hour' as compounding: load after n hours = 500 x 1.15^n. Then 1.15^2 = 1.3225 and 1.15^3 = 1.520875, so the load is about 760 requests per minute (760.44).
- Say the linear reading out loud and why you rejected it: adding 75 per hour gives 725, which assumes growth on the original base and not on the current load.
- Convert units if the options are per hour or per second: 760.44 x 60 is about 45,626 requests per hour, or about 12.7 per second.
- Sanity-check: three 15% steps must come to a bit more than 45% total (about 52%), so any option near 1.45x or below 1.5x is a trap.
Follow-up
- Roughly when does the load double? (Rule of 72 gives about 4.8 hours; ln 2 / ln 1.15 gives about 4.96.)
- If the server saturates at 700 requests per minute, during which hour does it overload? (Hour three: 661 after two hours, 760 after three.)
- How would you turn this growth estimate into an autoscaling threshold?
Choose the response that best demonstrates empathy when a colleague misses a critical deadline.
Choose the response that best demonstrates empathy when a colleague misses a critical deadline.
Approach
- Read every option before choosing. Judgment items usually include one response that blames the colleague, one that ignores the miss, one that escalates straight away, and one that balances support with accountability.
- The strongest option usually does three things: talks to the colleague privately, asks what got in the way, and agrees a concrete recovery plan (a new date, split work, or flagging the impact to whoever depends on it).
- Rule out options that are pure sympathy with no plan, since the deadline still has consequences. Also rule out public criticism or going over the colleague's head before talking to them.
- Answer personality and judgment items consistently. Similar scenarios reappear in different wording, and contradictory answers look worse than any single choice.
Follow-up
- What changes if this is the third missed deadline this quarter?
- Your own delivery depends on the late work and a stakeholder is waiting. What do you tell the stakeholder?
- When would escalating to the manager be the right first step?
[English Test] Read this technical passage and summarize the core architectural problem in your own words.
[English Test] Read this technical passage and summarize the core architectural problem in your own words.
Approach
- Read once for the gist, then a second time to sort the sentences into problem, symptoms, causes and suggested fixes. The task asks for the core problem, so the fixes are secondary.
- Write two to four sentences: what the system does, what constraint it violates (for example, a single database taking every write, or synchronous calls chaining failures across services), and the consequence for users or operations.
- Name the root cause, not the symptom: 'requests time out' is a symptom, while 'every request waits on one overloaded service' is the problem.
- Use your own words and plain grammar, keep tense consistent, and stay within any word limit. Copying sentences from the passage defeats the purpose of a summary task.
- Reread once for grammar, articles and subject-verb agreement before submitting.
Follow-up
- What single change would you suggest first, and what would it cost?
- Explain the same problem in one sentence to a non-technical manager.
- What information is missing from the passage that you would need before acting?
Walk me through how you would design a backend system to handle millions of SMS notifications daily.
Walk me through how you would design a backend system to handle millions of SMS notifications daily.
Approach
- Size it first: 10 million messages a day averages about 116 per second, but campaigns and OTP bursts make the peak many times that, so design for the peak. Separate transactional traffic (OTPs, alerts) from bulk marketing.
- Write path: an API validates the request (number format, template, opt-out list, quiet hours), stores it with a client idempotency key, publishes to a durable queue (Kafka, RabbitMQ or SQS) and returns 202 with a message id. Separate queues or priority lanes stop a 5-million-message campaign from delaying OTPs.
- Workers render templates and send through the SMS gateway connections under per-gateway rate limits. Retry transient failures with exponential backoff and jitter, send poison messages to a dead-letter queue, and fail over to a second provider where one exists.
- Delivery is at-least-once, so dedupe by message id before each send. Track status as accepted, queued, sent, delivered or failed, updated from the gateway's delivery-receipt callbacks, in a store partitioned by message id with a secondary index by recipient for support lookups.
- Operate it with queue lag, send rate, delivery rate per gateway and DLQ size as alerts. Scale workers horizontally, since containers fit naturally here.
Follow-up
- The main SMS gateway is down for an hour. What happens to queued OTPs versus marketing messages?
- How do you make sure a user never receives the same OTP twice after a worker crash?
- How do you schedule a campaign for 8 a.m. local time across time zones without a thundering herd?
What is your approach to writing unit and integration tests for your APIs?
What is your approach to writing unit and integration tests for your APIs?
Approach
- Describe the pyramid you actually use. Many fast unit tests cover handlers and services with the repository and external clients faked. Fewer integration tests run against a real database in a container with migrations applied. A handful of end-to-end checks run on the deployed service.
- Unit tests cover validation rules, error branches and business logic. API-level tests assert status codes (400, 401, 403, 404, 409), error body shape, pagination edges and idempotent retries, not only the happy path.
- Integration tests isolate state: a fresh schema, or a transaction rolled back per test. Use stubbed third-party services (a fake SMS provider or WireMock) so tests are deterministic, and add contract tests against an OpenAPI schema or consumer-driven contracts for services other teams call.
- Name the tools in your language: JUnit with Mockito and MockMvc or Testcontainers for Java, pytest for Python, Jest with supertest for Node.js, testing with httptest for Go. All of them run in CI on every pull request.
- Keep tests reliable: no sleeps, inject a fake clock, generate unique test data, and quarantine and fix flaky tests instead of retrying them indefinitely.
Follow-up
- How do you test code that calls an external SMS or payment provider?
- An integration test fails one run in twenty. How do you track it down?
- Is a coverage percentage a useful target for you? Why or why not?
Tell us about a time you encountered a severe bug in production. How did you diagnose and fix it?
Tell us about a time you encountered a severe bug in production. How did you diagnose and fix it?
Approach
- Situation in two sentences with impact: what broke, who was affected and how badly (error rate, failed transactions, affected users), and how it was detected (alert, customer ticket).
- Show that you mitigated before diagnosing: rollback, feature flag off, traffic shift or scaling, and say why that choice was safe.
- Lay out the diagnosis in order: build the timeline, correlate it with deploys and config changes, read logs, metrics and traces, form a hypothesis, reproduce it locally or in staging, and confirm the root cause (for example a missing index, a connection-pool leak or a race condition).
- Describe the fix and the guard: a test that reproduces the bug, the code change, and what you added afterwards, such as an alert, a dashboard, a migration check or a runbook entry.
- Use 'I' for your actions, and give one plain-language sentence on business impact for the non-technical panel members. Blaming another team or skipping the mitigation step sinks this story.
Follow-up
- What alert would have caught it earlier?
- Why did you not roll back straight away, or why did you?
- What changed in the team's process because of this incident?
Every query on one table stalls for forty seconds mid-deploy
During a release on PostgreSQL, every query touching resource times out for about 40 seconds and then recovers with no intervention. The release ran one migration, ALTER TABLE resource ADD COLUMN archived_reason TEXT, and the migration log shows it completing in 6 ms. Unrelated tables showed no change in error rate. Explain how a 6 ms statement caused a 40-second stall, give the ordered checks you would run on a live system to confirm it, and give the migration procedure that prevents a repeat.
Approach
- Separate the statement's duration from the lock's duration. ADD COLUMN with no default is a catalogue-only change and genuinely runs in milliseconds, but it requires ACCESS EXCLUSIVE, and it cannot acquire that until every transaction already touching the table has finished.
- Account for the queueing, which is the part that surprises people. A lock request that is waiting blocks later requests for conflicting modes behind it rather than letting them overtake, so one long-open transaction holds the DDL and the DDL holds all the traffic. The stall length is set by the longest open transaction, not by the size of the change.
- Confirm on a live system in this order: pg_stat_activity for that table ordered by xact_start, looking for the oldest transaction and specifically for state = idle in transaction; then pg_locks where granted = false to find the waiter; then join them on pid to name blocker and blocked. pg_blocking_pids() does that join for you and is the fastest single call.
- Prevent rather than merely time it better. Set lock_timeout to a second or two on the migration session so the DDL abandons the queue after a bounded wait and is retried, instead of holding it for as long as the oldest transaction lives. Be exact about what that buys: queries arriving during the wait still queue behind the pending ACCESS EXCLUSIVE request, so each attempt costs them up to one lock_timeout of added latency. The outage goes from 40 seconds to about one second per attempt, not to zero. Also run migrations away from deploy-time peaks, and put a statement timeout and an idle-in-transaction timeout on the analytics role that opens the long transactions.
Follow-up
- The same release also wants NOT NULL on that column. What is the sequence that gets there without a long lock?
- Your lock_timeout retry fails ten times in a row because the analytics transaction is always open. What do you change?
Days 1-2 cover the reported testing phase, days 3-5 the reported technical panel questions with the related practice problems, day 6 the HR questions, and day 7 a full mock panel plus offer preparation.
Prepare, practise & reflect
One practical outcome each day. Spend longer where you need it.
0 / 7 done01Logic sequences and percentage arithmetic
- Do two timed sets of shape-sequence and 3x3 matrix puzzles, writing which attribute rule solved each item
- Solve the request-growth question both ways (compound and linear) and write why compound is the right reading
- Drill ten compound-growth and doubling-time problems without a calculator, using the rule of 72
Deliverable: An attribute checklist for pattern items, a worked solution to the request-growth question, and a scored drill sheet
Practice prompt ↗Practice prompt ↗02Situational judgment and the English summary
- Work through a situational-judgment set, including the missed-deadline empathy item, and justify each best answer in one line
- Summarize two technical articles or incident reports in three sentences each: system, root problem, consequence
- Proofread both summaries for grammar and tense, then rewrite the weaker one
Deliverable: Annotated judgment-item answers and two edited three-sentence technical summaries
Practice prompt ↗Practice prompt ↗03Zero-downtime migrations and live backfills
- Write the expand-and-contract sequence for renaming a column on a large table, with the lock and rollback notes for each step
- Work the practice problem on denormalising tenant onto revisions and backfilling it live
- Work the practice problems on a table that stalls mid-deploy and on holding a per-tenant cap under concurrent creates
Deliverable: A one-page migration runbook plus written solutions to the three practice problems
Practice prompt ↗Practice prompt ↗Practice prompt ↗Practice prompt ↗04SMS notification system design
- Draw the SMS design: API, idempotency store, queues with priority lanes, workers, gateway rate limits, delivery receipts, status store
- Do the sizing math for 10 million messages a day and write your peak assumption
- Work the practice problem on canonicalising a request body into an idempotency fingerprint, and connect it to OTP dedupe
Deliverable: An annotated design diagram, a sizing note and a written idempotency-fingerprint solution
Practice prompt ↗Practice prompt ↗05API testing and the production incident story
- Write your API test strategy in your main language: unit, integration with a containerized database, contract tests, tools
- List the status-code and error cases you would test for one of your past endpoints
- Write the STAR outline of your production-bug story: impact, mitigation, diagnosis sequence, fix, guard
Deliverable: A test-strategy page, an endpoint test-case list and a production-incident STAR outline
Practice prompt ↗Practice prompt ↗06HR and cross-department questions
- Write answers on preferred daily tasks and on why you want to move to Ais, with career goals
- Write STAR stories for conflicting supervisor requests and for constructive feedback, each with a measured result
- Record yourself giving all four answers in plain English and cut any filler
Deliverable: Four written answers and a recording of them
Practice prompt ↗Practice prompt ↗Practice prompt ↗Practice prompt ↗07Mock panel and offer preparation
- Run a mock panel with one technical and one non-technical listener: the SMS design, the migration question, the incident story and two HR questions
- After each answer, ask the non-technical listener to repeat its impact back to you, and fix anything they could not
- Write your salary range, benefit priorities and contract questions for the HR offer discussion
Deliverable: Mock-panel notes with fixes, plus a one-page offer-discussion checklist
Practice prompt ↗Practice prompt ↗Practice prompt ↗Practice prompt ↗Practice prompt ↗Expand any day for tasks and deliverables. Your progress is saved on this device.
Candidates report that the panel includes an HR representative and, in some cases, supervisors from other departments, and that its non-technical questions cover job preferences, competing requests between departments, feedback and motivation for joining. Prepare short STAR stories with measured results, and answers about preferences that stay consistent through to the offer discussion.
How do you handle database migrations with zero downtime?
How do you handle database migrations with zero downtime?
Approach
- Use expand and contract. Add the new column or table in a backward-compatible way, deploy code that writes to both old and new, backfill existing rows, switch reads to the new structure, stop writing the old one, and drop it in a later release.
- Each step must work with both the old and the new application versions, because during a rolling deploy both run at the same time. Never rename or drop a column in the same release that stops using it.
- Account for locks. In PostgreSQL most ALTER TABLE forms take an ACCESS EXCLUSIVE lock, so set a short lock_timeout to make the DDL fail fast instead of queueing behind a long transaction and blocking every query. Use CREATE INDEX CONCURRENTLY, and add NOT NULL via a CHECK constraint marked NOT VALID, then VALIDATE it. In MySQL, use online DDL or a tool such as gh-ost.
- Backfill in small batches keyed by primary key, with throttling, while watching replication lag and lock waits. Make the backfill idempotent so it can be restarted.
- Keep migrations versioned in a tool (Flyway, Liquibase, Alembic or similar), run them in CI against a production-like copy, and know the rollback for each step before running it.
Follow-up
- How would you rename a column on a large, heavily written table?
- Your backfill is causing replica lag. What do you change?
- What is your rollback if a problem appears after the contract step has dropped the old column?
How do you prioritize tasks when receiving conflicting requests from different department supervisors?
How do you prioritize tasks when receiving conflicting requests from different department supervisors?
Approach
- Give the framework, then a real story. Make the conflict visible early instead of quietly choosing. For each request, find out the deadline, the business impact and who depends on it.
- Rank by impact and urgency, and by dependencies (what blocks other teams or customers). Bring the trade-off to both supervisors, or to your own manager, with a recommendation, so the people who own the priorities make the call.
- Confirm the agreed order in writing, give each requester a date, and look for partial delivery that unblocks the lower-priority request early.
- Avoid the two answers that sink this question: 'I just work overtime to do both' (it does not scale and hides the conflict) and siding with whoever is more senior or louder.
Follow-up
- What if your own manager is unavailable and both deadlines are tomorrow?
- What if both supervisors insist their request is top priority?
- How did the supervisor whose request went second react, and what did you do about it?
Describe a time you received constructive feedback. How did you apply it?
Describe a time you received constructive feedback. How did you apply it?
Approach
- Choose feedback that was specific and uncomfortable but fair, such as code reviews that were too large to review, status updates that came too late, or explanations too technical for stakeholders. Avoid disguised strengths like 'I care too much'.
- Show your first reaction honestly, then how you checked your understanding: you asked for examples, or asked what good would look like.
- Describe the concrete change you made (smaller pull requests, a written weekly update, a summary-first format) and keep it as a habit.
- End with evidence that it worked: faster review turnaround, fewer escalations, or the same person noting the change. Without a result, the story only shows that you listened.
Follow-up
- Tell me about feedback you disagreed with. What did you do?
- How do you give constructive feedback to a peer?
- What feedback are you working on right now?
Why do you want to transition to Ais, and what are your long-term career goals?
Why do you want to transition to Ais, and what are your long-term career goals?
Approach
- Give two or three reasons that are true for you and tied to what the role involves: backend systems serving a large telecom and digital-services user base, consumer and enterprise products, and cross-department projects. Avoid repeating company slogans.
- Connect your background to the move: the systems you have built (APIs, high-volume messaging, data pipelines) and what you want more of, such as larger scale, uptime responsibility or telecom domain depth.
- Set out goals over three to five years that fit a backend path, for example owning a service end to end, then leading the design of larger systems or mentoring. Keep them consistent with the preferences you gave earlier.
- Avoid answers that are only about salary or title, and avoid goals the role clearly does not offer, since HR on the panel weighs fit.
Follow-up
- Why telecom specifically, rather than another industry?
- Where do you see yourself if a management track is not available?
- What would make you leave within the first year?
- 01
How do you prioritize tasks when receiving conflicting requests from different department supervisors?
- 02
Describe a time you received constructive feedback. How did you apply it?
- 03
Why do you want to transition to Ais, and what are your long-term career goals?
- 04
What are your primary preferences regarding your job description and daily tasks?
- 05
Describe a time you had to explain a complex technical limitation to a non-technical manager.
- 06
Tell us about a time you encountered a severe bug in production. How did you diagnose and fix it?
How much do the IQ and EQ tests matter?
Candidates report that you must pass the IQ, EQ and aptitude tests to be invited to the panel, so they decide whether you are interviewed at all. Practise timed shape sequences, percentage arithmetic and situational-judgment items, and answer personality questions consistently.
Ais Software Engineer candidate reports ↗What is the panel interview like?
Candidates describe one panel of two to three people, usually technical managers and an HR representative, sometimes with supervisors from other departments, lasting 30 to 60 minutes. Reported questions mix backend topics (migrations, SMS system design, API testing, a production bug) with HR questions on preferences, priorities, feedback and motivation.
Ais Software Engineer candidate reports ↗Will I have to write code live?
Candidates report that the panel leans toward technical discussion, past experience and fit rather than live coding, and that baseline coding is covered by the technical assessment in the testing phase. Prepare to explain code and design decisions clearly without an editor, and keep your core language fluent for the assessment.
Ais Software Engineer candidate reports ↗How long does the process take?
Candidates report about 3-5 weeks across three stages. The testing phase is the longest single block and can take several hours across the aptitude, English and psychometric parts. The panel is under an hour, and HR then contacts successful candidates about the offer.
Ais Software Engineer candidate reports ↗Which technologies should I prepare?
The requirements candidates describe list a backend language (Java, Python, Node.js or Go), relational and non-relational databases, and RESTful API design. Cloud platforms (AWS, Azure or GCP), Docker and Kubernetes, and telecom or ISP experience are listed as nice to have. Go deep on one language and one SQL database: locking, indexing, migrations and testing.
PracHub Software Engineer practice ↗Do I need telecom experience?
Candidates list telecom or ISP experience as a nice-to-have, not a requirement. If you lack it, prepare a few telecom-shaped examples, such as the SMS notification design with delivery receipts and rate-limited gateways, so you can show you can reason about that domain.
Ais Software Engineer candidate reports ↗What happens at the offer stage?
Candidates report that HR discusses salary expectations, benefits and contract details after a successful panel. Research a range for your level and location independently, decide your floor, and list the contract and benefit questions you need answered before the call.
PracHub Software Engineer practice ↗Sources & methodology 3 sources ↗
No official company page is cited. Rounds and questions come from candidate reports and PracHub editorial material; each source shows the date it was read.
- 01Ais Software Engineer candidate reports ↗
Company-reported rounds, questions and FAQ.
Candidate reports · Accessed 2026-09-22 - 02PracHub Software Engineer practice ↗
PracHub practice material, not company-reported.
PracHub page · Accessed 2026-09-22 - 03PracHub preparation framework ↗
PracHub preparation guidance.
PracHub page · Accessed 2026-09-22
Explore related engineering environments and compare the preparation focus.
Cognition Software Engineer Interview Guide
What Cognition asks Software Engineer candidates, from reported rounds and questions.
Vercel Software Engineer Interview Guide
Debugging practice for Vercel software engineer prep built on a reproduction you trust, narrowing to the smallest failing input, and changing one variable per run so the result stays attributable.
Together Ai Software Engineer Interview Guide
Failure-handling practice for Together Ai software engineer candidates: requests whose outcome a timeout leaves unknown, where a retry is safe, and deduplicating at the receiver instead of assuming exactly-once delivery.
Spotify Software Engineer Interview Guide
Timed practice for Spotify software engineer candidates who lose time to the clock: short problems taken end to end, then reviewed against a written rubric rather than a passing test run.