The reported questions fall into five groups: technical knowledge (XML and its uses, the differences between REST and SOAP, version control, a significant bug you resolved), system design (real-time data processing, the factors in a database schema, a trade-off you balanced), problem-solving (incomplete requirements, debugging a complex issue in a live production environment), coding (reversing a string, the maximum sum of non-adjacent numbers) and behavioral prompts (a challenging project, prioritizing, teamwork). Several of them are written with a bracketed slot for a language or technology, so you need to arrive with a real language and a real project to put in it.
The stack candidates mention is a conventional web-and-data one. The role lists Python, Java or C++, experience with web frameworks and database design, Agile working and version control, with cloud platforms, containers and CI/CD as extras. Candidates also name Django, advanced SQL, SQL query writing, system design and code review as topics, and some mention XML and XML Schema (XSD) and understanding a Django codebase. Know the ORM, joins, window functions, indexes and the shape of a REST API well enough to write them without looking anything up.
Two kinds of answer carry most of the weight. The first is short working code in a language you choose: both reported coding questions have a brute-force version, a clean linear version and a handful of edge cases, so practise stating all three. The second is a spoken narrative: the bug you resolved, the production debugging approach, the design trade-off and the behavioral stories are all the same skill, which is telling a specific story in which you made the decisions. Build a small bank of real stories and reuse each one across several prompts.
Reports put the whole process at about 3-5 weeks. Use the early days of a loop for the broad topics (SQL, Django, APIs, design) and keep the final days for out-loud rehearsal, because most of the reported questions are conceptual and are won by clear explanation, not by recall.
Phone Screen
reportedCandidates report this first stage as a call with a recruiter about your interest in the role and your basic qualifications. No technical exercise is reported for it. Treat it as a short, accurate pitch: why this role, which of the listed languages you work in, what web framework and database work you have done, and how you have worked in Agile teams with Git. A concrete pitch also gives you the language and project you will use later when a question asks about your experience with a specific technology.
What to demonstrate
- Your interest in the role and the company
- Basic qualifications against the requirements candidates describe: a language such as Python, Java or C++, web frameworks, databases, Git, Agile
- How clearly you summarise your background
How to prepare
- Write a short career summary that ends on the work you want next, and check it against the listed requirements: language, web framework, database design, version control, Agile.
- Pick the one language and one project you will lead with, and write two sentences on what you built and what you personally owned.
- Prepare questions about the rest of the loop (the format of the Technical Interview, which languages are allowed, who you will meet) and ask for them in writing.
Technical Interview
reportedCandidates report practical exercises that show coding skill and problem-solving. Reports do not say which questions are asked at this stage, but a practical stage is where you write and explain code. Topics candidates name across the loop are Django, advanced SQL, SQL query writing, system design and code review, and the reported coding questions are reversing a string and the maximum sum of non-adjacent numbers. Approach each exercise by restating the problem, giving the brute force first, then the better version with its complexity and edge cases, speaking as you go.
What to demonstrate
- Working code produced in front of someone, in a language you choose
- Problem-solving: breaking a task into steps and improving a first solution
- How clearly you explain your approach while you work
How to prepare
- Write the reported coding exercises (reversing a string, the maximum sum of non-adjacent numbers) in your strongest language without autocomplete, and state the time and space complexity of each.
- Rehearse two design walk-throughs aloud: a real-time data processing system and the factors behind a database schema, naming the trade-off you chose and what it costs.
- Practise advanced SQL by hand: window functions, CTEs, self-joins and NOT EXISTS, and check the plans with EXPLAIN.
- Build a small Django app with a foreign key and a list view, and be ready to explain select_related, prefetch_related and migrations.
Behavioral Interview
reportedCandidates report this last stage as an assessment of how you fit with the team and the company culture. The evaluation areas candidates describe are collaboration and communication: team dynamics, conflict resolution and giving and receiving feedback. The reported behavioral prompts cover a challenging project, prioritizing across projects and working effectively in a team. Prepare four or five real stories and map each one to several prompts so that you are adapting a story, not inventing one.
What to demonstrate
- Fit within the team and with the company culture
- Collaboration and communication: team dynamics, conflict resolution, feedback
- The decisions you personally made on past projects
How to prepare
- Write one story each for the challenging project, the prioritization question, the teamwork question and the significant bug, with the decision you made and a result you can defend.
- Add a disagreement story and a feedback story (given and received), since conflict resolution and feedback are among the evaluation areas candidates describe.
- Rehearse each story aloud and cut it until the situation takes two sentences and the rest is your reasoning.
PracHub editorial advice for the preparation topics above.
Answering the bracketed language question with a general claim of fluency
Decide before the loop which language and which project you will name. Describe what you built, how you tested and debugged it, and one limit you hit, so each follow-up lands on something you know.
Stopping at the built-in for the reverse-a-string question
Give the one-line idiom, then the in-place two-pointer version on a mutable array, and state the edge cases: empty and single-character input, strings that are immutable in Python, Java and JavaScript, and multi-code-unit characters such as combining marks.
Solving the maximum sum of non-adjacent numbers greedily, or forgetting negative inputs
Define whether an empty selection is allowed, write the take-or-skip recurrence, reduce it to two running values for O(n) time and O(1) space, and test an all-negative list and a two-element list before you say it is done.
Giving design answers (real-time processing, schema design) as a list of components without choosing anything
Name the access patterns first, then the partition key or the index, the delivery guarantee or constraint, and one trade-off you accept, such as staleness for throughput. End on what you would monitor and what breaks first at ten times the load.
Telling behavioral stories in the 'we' voice with no decision, no result and no friction
For the challenging project, prioritization, teamwork and bug stories, write the decision you made, one disagreement, a result you can defend and what you would change. Rehearse them aloud until each starts with two sentences of setup.
Choose a category, try a prompt, then open its approach, worked solution or follow-up when you need it.
Write a function to reverse a string in [specific programming language].
Write a function to reverse a string in [specific programming language].
Approach
- Confirm the language and the input first, since the question leaves the language open: can it be empty or null, and is it ASCII or arbitrary Unicode? Then state the target, O(n) time.
- Give the idiomatic answer per language. Python: s[::-1], O(n) time and O(n) space because strings are immutable. Java: new StringBuilder(s).reverse().toString(), which keeps surrogate pairs intact. C++: std::reverse(s.begin(), s.end()), in place.
- Write the manual version too: convert to a character array, swap with two pointers moving inward until they meet, and join. That is n/2 swaps and O(1) extra space beyond the array. Avoid building the result by repeated concatenation in a loop, which can degrade to O(n^2).
- Raise the Unicode edge cases. JavaScript's s.split('').reverse().join('') splits UTF-16 code units and breaks emoji, while [...s] iterates by code point. Byte reversal breaks UTF-8 in C++. Reversing by code point still separates combining marks and multi-code-point emoji, which need grapheme-cluster segmentation.
- Test empty, single-character, even and odd lengths, and a palindrome.
Follow-up
- Reverse the string in place with O(1) extra space. What does your language allow?
- Now reverse the order of the words in a sentence but keep each word intact.
- How would you reverse correctly when the input contains emoji or accented characters?
Given a list of integers, how would you find the maximum sum of non-adjacent numbers?
Given a list of integers, how would you find the maximum sum of non-adjacent numbers?
Approach
- Clarify the edge cases: what an empty list returns, whether negatives occur, and whether choosing no element at all (sum 0) is allowed. If at least one element is required and all are negative, the answer is the maximum element.
- Name the brute force: try every subset with no two adjacent elements, which is exponential (2^n subsets). Note that greedily taking the largest values fails, e.g. [2, 1, 1, 2], where the best is 2 + 2 = 4.
- Write the DP recurrence: best(i) = max(best(i-1), best(i-2) + a[i]), meaning either skip a[i] or take it with the best answer ending two positions back. Base cases best(-1) = best(-2) = 0.
- Reduce to O(n) time and O(1) space with two rolling values. For each x, new_incl = excl + x and new_excl = max(incl, excl). The answer is max(incl, excl). With a zero base, a negative element is never kept in the final answer.
- Walk through [3, 2, 7, 10], which gives 13 (3 + 10). To return the chosen indices, keep the full dp array and backtrack from the end, checking which branch of the max produced each value.
Follow-up
- Return which elements make up the maximum sum, not just the sum.
- The list is circular, so the first and last elements count as adjacent. How does the solution change?
- The values arrive as a stream. Can you keep the answer updated as each new number comes in?
Identify the heaviest tenants in a five-minute window under memory pressure
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?
What factors do you consider when designing a database schema?
What factors do you consider when designing a database schema?
Approach
- Start from the entities and the access patterns: which queries run most often, read/write ratio, and expected row counts. A schema is designed for its queries, not only for its nouns.
- Normalize to roughly third normal form so each fact lives in one place and updates cannot leave contradictions. Denormalize deliberately (a cached count, a summary table) only where a measured read path needs it, and say how the copy stays consistent.
- Enforce integrity in the database: primary keys (surrogate or natural, and why), foreign keys, NOT NULL, UNIQUE and CHECK constraints, appropriate types (DECIMAL for money, timestamptz for times). Model many-to-many with a junction table that carries its own attributes.
- Index for the predicates you actually filter and sort on. A composite index serves queries that use its leftmost columns, and every index adds write and storage cost. For soft deletes in Postgres, a partial unique index (WHERE deleted_at IS NULL) keeps a deleted row from blocking a new one.
- Plan for change: migrations that are safe on a live table (add a nullable column, backfill in batches, then add the constraint), plus audit columns such as created_at and updated_at. In Django this means models plus reviewed migration files.
Follow-up
- When have you denormalized, and how did you keep the copies in sync?
- How would you change a column's type on a large table that serves live traffic?
- How would you model a user who can belong to many organizations with a different role in each?
Keep soft-deleted accounts from blocking re-registration
app_user holds user_id, tenant_id, email CITEXT, password_hash (NULL for SSO principals), email_verified_at, auth_version, status ('invited','active','suspended','deactivated'), created_at, updated_at, deleted_at. Two live accounts for one address inside a tenant must be impossible, but an address freed by a soft delete must be reusable, and the same tenant may delete and re-register it repeatedly. Write the uniqueness DDL for PostgreSQL 16, then the equivalent for MySQL 8 where partial indexes do not exist, and say what each permits once three deleted rows already hold that address.
Approach
- Start from what is actually unique: not (tenant_id, email), but (tenant_id, email) among live rows. PostgreSQL says that directly — CREATE UNIQUE INDEX app_user_live_email ON app_user (tenant_id, email) WHERE deleted_at IS NULL. A full constraint over the same two columns burns the address permanently the first time someone deletes an account.
- Keep case-insensitivity in the type or the index, never in the application: CITEXT as given, or UNIQUE (tenant_id, lower(email)) as an expression index where the extension is unavailable. A case-sensitive unique column is exactly how two accounts for one human appear.
- For MySQL 8 the predicate has to move inside the key: add a discriminator column that is a constant 0 while the row is live and is set to user_id on delete, with UNIQUE (tenant_id, email, deleted_marker). Live rows share the constant and still collide; deleted rows differ from each other and stop colliding.
- State the NULL variant and its dependency: leaving the marker NULL for deleted rows also works, because a unique index treats NULLs as distinct — true in MySQL, and true in PostgreSQL only under the default NULLS DISTINCT, which PostgreSQL 15 lets you reverse. Check the polarity against the three existing deleted rows: constant-on-live is what preserves the collision you want, and reversing it silently admits duplicate live accounts.
Follow-up
- A deleted account re-registers with the same address the next day. Do the old resource rows follow the new user_id, and how does the API keep the two principals apart?
- How do you honour an erasure request while resource_revision.actor_user_id still references this table?
What is your understanding of XML and its applications in software development?
What is your understanding of XML and its applications in software development?
Approach
- Define XML as a markup format for tree-structured data: elements, attributes, text, namespaces. Separate well-formed (it parses) from valid (it conforms to a DTD or XML Schema/XSD that fixes element order, types and cardinality).
- Name the parsing models and their cost. DOM builds the whole tree in memory, so it allows random access and XPath but memory grows with document size. SAX (push) and StAX (pull) stream events in constant memory, which suits large files.
- Give real applications: SOAP envelopes described by WSDL, build and config files (Maven pom.xml, Android layouts), RSS/Atom feeds, SVG, Office Open XML (.docx/.xlsx), and XSLT for transforming one XML shape into another.
- Compare it with JSON. XML supports schemas, namespaces, comments and mixed content. JSON is less verbose, has native number, boolean and array types, and is what most web APIs and frontends use.
- Cover security: disable DTD and external entity resolution to block XXE and entity-expansion (billion laughs) attacks. In Python I parse untrusted input with defusedxml instead of the standard-library parsers.
Follow-up
- How would you parse a multi-gigabyte XML export without running out of memory?
- When would you still choose XML over JSON for a new integration?
- How would you validate incoming documents against an XSD, and what do you return when validation fails?
Can you explain the differences between REST and SOAP?
Can you explain the differences between REST and SOAP?
Approach
- Frame the difference first: SOAP is a protocol with a fixed XML envelope (Envelope, optional Header, Body, Fault) and a machine-readable WSDL contract. REST is an architectural style built on resources with URIs, HTTP's uniform methods and stateless requests.
- Transport and format: SOAP is usually HTTP POST but can run over other transports such as JMS or SMTP, and it is XML-only. REST is tied to HTTP semantics and can return any representation, most often JSON.
- Caching and idempotency: REST GETs can be cached by browsers, CDNs and proxies. GET, PUT and DELETE are idempotent and POST is not. SOAP calls are generally POSTs to one endpoint, so HTTP caching does not help.
- Errors and contracts: REST signals errors with HTTP status codes plus a body, and documents its contract with OpenAPI. SOAP returns a Fault element (SOAP 1.1 sends it with HTTP 500) and has WS-* extensions such as WS-Security for message-level signing and encryption.
- Close with when to use each: SOAP for enterprise or legacy integrations that need strict typed contracts or message-level security, REST for public, web and mobile APIs where simplicity and caching matter. Give one example from your own work.
Follow-up
- How would you make a REST POST safe to retry after a client timeout?
- How do you version a REST API without breaking existing clients?
- When would you choose gRPC over both?
How do you manage version control in your projects?
How do you manage version control in your projects?
Approach
- Describe your branching model and why: trunk-based development with short-lived feature branches merged through pull requests, or GitFlow with release branches for versioned products. Say what makes you pick one over the other.
- Explain the merge path: a protected main branch, required CI checks and at least one code review before merge, small focused commits with messages that explain why, and squash or rebase for linear history.
- State the rebase rule correctly: rebase rewrites commit hashes, so I rebase only my own unpushed or unshared branches and never a shared one. Merge commits keep history but add noise.
- Undoing mistakes: git revert creates a new commit that undoes a pushed change and is safe on shared branches. git reset moves the branch pointer and suits local work only. git bisect binary-searches history to find the commit that introduced a regression.
- Mention releases and hygiene: tags with semantic versions, feature flags in place of long-lived branches, and a .gitignore for secrets. A secret that was committed must be rotated, because it stays in history even after deletion.
Follow-up
- A bad commit is already on main and deployed. What exactly do you run?
- How do you keep a long-running feature from drifting far from main?
- Walk me through resolving a merge conflict in a file you did not write.
Discuss an instance where you identified and resolved a significant bug in a software project.
Discuss an instance where you identified and resolved a significant bug in a software project.
Approach
- Open with the symptom and its impact in one or two sentences: what users saw, how many, and how you found out (alert, ticket, failing test).
- Spend most of the answer on the narrowing steps: how you reproduced it, which logs, metrics or traces you read, and how you cut the search space (a minimal reproduction, git bisect, toggling a config, comparing a good and a bad request).
- State the root cause in one precise sentence, for example 'a cached queryset was reused across requests, so users saw stale permissions', and separate it from the trigger that exposed it.
- Describe the fix and how you proved it: a regression test that failed before and passes after, and the metric that returned to normal after deploy.
- End with prevention: the test, alert, lint rule or review checklist item you added. A story that ends at 'I restarted it and it went away' shows no root cause and is the usual way this answer fails.
Follow-up
- Why did your existing tests not catch it?
- How did you confirm the fix worked in production and not only locally?
- What would you do differently if the same symptom came back next month?
How would you approach designing a system for real-time data processing?
How would you approach designing a system for real-time data processing?
Approach
- Pin the requirements first: the latency target (sub-second or a few seconds), events per second and peak, whether per-key ordering matters, and whether duplicates are acceptable. These answers decide the architecture.
- Lay out the pipeline: producers write to a durable partitioned log (Kafka or Kinesis), a stream processor (Flink, Kafka Streams or Spark Structured Streaming) transforms and aggregates, and results go to a serving store or cache for dashboards and alerts.
- Handle time correctly: aggregate in tumbling, sliding or session windows on event time rather than processing time, and use watermarks to decide when a window closes and what happens to late events.
- State the delivery semantics: at-least-once delivery plus idempotent writes (upsert keyed by event id) is the common practical choice. Exactly-once needs checkpointing plus transactional or idempotent sinks, and costs throughput.
- Cover scale and operations: parallelism is bounded by the partition count, because within a consumer group each partition goes to one consumer. Watch consumer lag, apply backpressure, split hot keys, and keep log retention long enough to replay after a bug.
Follow-up
- Events arrive after their window has already been emitted. What do you do with them?
- One key produces most of the traffic and its partition lags. How do you fix it?
- A bug corrupted the last six hours of aggregates. How do you reprocess them?
Describe a scenario where you had to balance trade-offs in system design.
Describe a scenario where you had to balance trade-offs in system design.
Approach
- Pick one real decision with at least two options that were both viable, such as a monolith module or a separate service, strong or eventual consistency, a normalized schema or a denormalized read model, building or buying.
- Name the axis of the trade-off and the constraints that set it: latency target, team size, deadline, data volume, operational cost. Say what each option would cost along that axis.
- Explain how you decided: a benchmark, a prototype, load numbers or a written comparison, and who you consulted. Use first person for your own part.
- State what you gave up and how you limited the damage, for example 'I accepted a few seconds of staleness on the dashboard and added a cache-bust on writes for the owner's own view'.
- Close with the measured outcome and the condition that would make you revisit the choice. Picking an option with no real downside, or narrating the team's decision with no personal role, weakens this answer.
Follow-up
- Looking back, would you make the same call with what you know now?
- What signal would tell you it is time to reverse that decision?
- How did you convince the people who preferred the other option?
How would you tackle a situation where you are given incomplete requirements for a project?
How would you tackle a situation where you are given incomplete requirements for a project?
Approach
- List the unknowns and rank them by the cost of guessing wrong. Data model, external contracts and anything user-visible come before internal details you can change cheaply later.
- Take specific questions to the stakeholder, each with options and a recommendation ('Should an expired invite be resendable, or does it require a new invite? I suggest resend'), not an open 'what do you want?'.
- Write the assumptions and acceptance criteria into the ticket or a short design note and get explicit agreement, so a later change shows up as a change rather than a surprise.
- Build a thin end-to-end slice or prototype early so real feedback replaces guesses. Keep the uncertain parts reversible with feature flags, configuration or an interface boundary.
- Re-check scope as answers arrive and raise the schedule impact as soon as a new requirement appears, not at the deadline.
Follow-up
- The stakeholder is unavailable for two weeks. What do you build in the meantime?
- A requirement changes after you have shipped half the work. How do you handle it?
- How do you push back when a late requirement threatens the deadline?
Describe your approach to debugging a complex issue in a live production environment.
Describe your approach to debugging a complex issue in a live production environment.
Approach
- Mitigate before diagnosing: if a recent deploy or flag correlates with the issue, roll it back or turn the flag off, then investigate with the pressure off. Keep a timeline of actions as you go.
- Scope the problem: which endpoints, users, regions or hosts are affected, since when, and what changed around that time (deploys, config, traffic, dependencies, data). Compare an affected request with a healthy one.
- Move from metrics to traces to logs, following one failing request by its correlation id. Check that the dashboards and logs are themselves healthy before trusting what they show.
- Test hypotheses with the least risky observation first: read-only queries, temporary sampled debug logging, a canary. Do not attach a pausing debugger to a production process. Reproduce in staging with production-like data where possible.
- Ship the fix with a regression test, confirm the metric recovers, then write a blameless postmortem covering root cause, trigger, detection gap and follow-up actions.
Follow-up
- The issue is intermittent and you cannot reproduce it locally. What next?
- The logs you need were never written. How do you get the data safely?
- How do you tell whether a deploy caused the problem or merely coincided with it?
The plan follows the three reported rounds and the fifteen reported questions, with the Django, advanced SQL and system design topics candidates name. Each day ends with something you can check, and the last day rehearses the behavioral stories out loud.
Prepare, practise & reflect
One practical outcome each day. Spend longer where you need it.
0 / 7 done01Map the loop and pick your language
- Write the three reported rounds on one page (Phone Screen, Technical Interview, Behavioral Interview) and sort the reported questions into technical, design, problem-solving, coding and behavioral.
- Choose the one language you will use for coding and for the experience question, from the Python, Java, JavaScript and C++ the role lists.
- Write a short phone-screen pitch that matches the listed requirements: language, web framework, database design, Git and Agile.
Deliverable: A one-page loop map with your questions sorted by type, a named language and project, and a written phone-screen pitch.
02Coding: reverse a string, non-adjacent sum
- Write the reverse-a-string solution twice, with the built-in idiom and in place with two pointers on a mutable array, and list the edge cases: empty, single character, immutable strings, multi-code-unit characters.
- Solve the maximum sum of non-adjacent numbers three ways: brute-force recursion, memoized recursion, then two running values in O(n) time and O(1) space.
- Test the sum on empty, one element, all negatives and alternating values, and say each complexity aloud.
Deliverable: Two working solutions per problem with the test cases you ran and the stated time and space complexity of each.
Practice prompt ↗Practice prompt ↗03SQL and schema design
- Design a schema for a domain you pick (orders, users, subscriptions): tables, keys, constraints, and the indexes for two named queries, with a note on where you normalise and where you would not.
- Work PracHub's practice question on keeping soft-deleted accounts from blocking re-registration, and explain the constraint you chose.
- Write four advanced queries: a window function ranking per group, a CTE with an aggregate, a self-join and an anti-join with NOT EXISTS. Check each with EXPLAIN.
Deliverable: A schema with its DDL and indexes, the practice solution, and four working queries with a one-line note on each plan.
Practice prompt ↗Practice prompt ↗04Django, APIs, XML and version control
- Build a small Django app with a foreign key, a list view and a migration, and fix an N+1 query with select_related or prefetch_related.
- Write a one-page comparison of REST and SOAP (message format, contract, error handling, state) and a short note on XML: well-formedness, namespaces, validating against an XSD, and where it still beats JSON.
- Write out your Git workflow: branching, pull request review, merge versus rebase, resolving a conflict and reverting a bad release, and say it aloud.
Deliverable: A running Django app, a one-page REST, SOAP and XML cheat sheet, and a spoken Git workflow answer.
Practice prompt ↗Practice prompt ↗Practice prompt ↗05System design and trade-offs
- Draw a real-time data processing design: ingestion, a log or queue, a stream processor, storage and serving, with the partition key, delivery semantics (at-least-once with idempotent writes), backpressure and late data.
- Work PracHub's practice question on finding the heaviest tenants in a five-minute window under memory pressure, as a streaming exercise.
- Write a trade-off story from a real decision of yours (cache freshness, SQL versus a document store, monolith versus services) as choice, alternatives and cost.
Deliverable: A design diagram with read and write paths, a solved practice question, and a one-page trade-off write-up.
Practice prompt ↗Practice prompt ↗Practice prompt ↗06Debugging, unclear requirements and code review
- Write your production debugging sequence: confirm impact, check recent changes, read logs, metrics and traces, bisect, mitigate by rollback or flag, then find the cause and add a regression test.
- Write the significant-bug story with symptom, hypothesis, evidence, fix and prevention.
- Write the clarifying questions and assumption log you would use for a project with incomplete requirements, and the smallest slice you would build first.
- Review one pull request from an open-source Python project and sort your comments into blocking and optional.
Deliverable: A debugging runbook, a written bug story, a question and assumption list, and a set of sorted review comments.
Practice prompt ↗Practice prompt ↗Practice prompt ↗07Behavioral stories and a full run-through
- Write the stories for the language-experience, challenging-project, prioritization and teamwork prompts, each with your decision, a result you can defend and one flaw.
- Add a disagreement story and a feedback story, then map every story to at least two prompts in a small table.
- Run the whole loop aloud in order: the phone-screen pitch, one coding problem, one design walk-through and three behavioral answers, recording yourself.
Deliverable: A story bank of at least five written stories mapped to prompts, and a recorded run-through with notes on what to tighten.
Practice prompt ↗Practice prompt ↗Practice prompt ↗Practice prompt ↗Expand any day for tasks and deliverables. Your progress is saved on this device.
Candidates report a final stage about fit with the team and company culture, and describe collaboration and communication as the areas covered: team dynamics, conflict resolution and feedback. For a Software Engineer, that means stories about shipping work with other people: how you decide, disagree, prioritize and respond to feedback. Several technical prompts, such as the bug you resolved and the design trade-off, are also stories, so prepare them in the same form.
Describe your experience with [specific programming language or technology].
Describe your experience with [specific programming language or technology].
Approach
- The question has a bracketed slot, so fill it before you arrive. Pick the language or technology you can defend in depth, ideally one the role lists (Python, Java, JavaScript or C++) or the web framework and database work you have actually shipped.
- Answer with one project, not a CV tour. Say what the system did, which parts you wrote, how long you have used the language, and what someone else depended on that you built, such as a service, a Django app, a data pipeline or a query layer.
- Show depth with specifics: how you test it, package it, profile it and debug it, one feature you rely on, and one limit you hit and what you did about it (for example the GIL for CPU-bound Python threads, async error handling in JavaScript, or ownership and lifetimes in C++).
- State plainly where your experience is deep and where it is thin. 'Two years in production on X, only side projects on Y' is more credible than a claim of fluency, and it keeps follow-up questions on ground you know.
- Close by tying it to the work candidates report for this role: building features, troubleshooting live applications and taking part in code review.
Follow-up
- What is a mistake you made in that language that you would not repeat?
- How did you test and debug the code you described?
- How would you become productive in a stack you have not used before?
Describe a challenging project you worked on and how you handled it.
Describe a challenging project you worked on and how you handled it.
Approach
- Choose a project where the difficulty was real and yours, such as a hard technical constraint, vague scope or a failing dependency. A project that was only hard because of a tight deadline gives you little to say about decisions.
- Use situation, task, action, result, but weight the action. Give the situation in two sentences, the part you owned in one, then the options you considered, why you chose one and what you gave up by doing so.
- Back the result with evidence you can defend: a before and after figure such as latency, error rate or deployment time, and how you checked your change was the cause. If you have no number, name the observable change instead.
- Say 'I' for your own decisions and 'we' only for team work, and name the help you asked for and from whom.
- End with what you would do differently and the part of the project that did not work. A story with no flaw sounds rehearsed.
Follow-up
- What was the riskiest decision you made, and what would have happened if it had been wrong?
- Who disagreed with your approach, and how did you resolve it?
- What would you do differently if you ran the project again?
How do you prioritize tasks when managing multiple projects?
How do you prioritize tasks when managing multiple projects?
Approach
- Open with the criteria you actually use: deadline and cost of delay, impact on users or the business, whether the work blocks someone else, and effort. Then apply them to a real set of three or so projects and say what went first, what slipped and what you dropped.
- Show how you made the trade-off visible: a shared list or board, and an agreed order with whoever owns the priority. The role is reported to work with product management, engineering and operations, so name how you would talk to each when two requests collide.
- Cover interruptions. Describe how you triage a production issue that lands mid-plan: judge severity, set a bounded time to look, and tell affected people the new dates instead of letting work slip silently.
- Include a time you said no or renegotiated scope, and how you re-check priorities at a regular point instead of only when you are overloaded.
- The mistake that sinks this answer is a list of virtues ('I stay organised and work hard') with no example of one decision about order.
Follow-up
- Two stakeholders each say their project is the top priority. What do you do?
- A production bug arrives in the middle of a sprint. What moves, and who do you tell?
- Tell me about a time you got the priority order wrong.
Can you share an example of how you have worked effectively as part of a team?
Can you share an example of how you have worked effectively as part of a team?
Approach
- Choose an example with a concrete shared goal and say who was on the team (engineers, product, operations). State your specific role in one sentence so the answer is about your contribution, not the team in general.
- Describe the mechanics that made the collaboration work: code review, a short design document, splitting the work along interfaces, agreeing what done means, pairing on a tricky part, or unblocking a teammate.
- Include one point of friction, such as a disagreement over approach or a missed handoff, and how you resolved it with evidence (a prototype, a benchmark, the data) instead of by seniority or by giving in.
- Finish with the team outcome, not only yours: what shipped, and one thing that stayed better afterwards, such as a test, a runbook or a clearer interface.
- Two failure modes: a hero story in which the team is background, and a harmony story with no friction at all.
Follow-up
- Tell me about a disagreement with a teammate and how it ended.
- How do you give feedback on a pull request you think is wrong?
- How did you help a teammate who was falling behind?
- 01
Describe your experience with [specific programming language or technology].
- 02
Describe a challenging project you worked on and how you handled it.
- 03
How do you prioritize tasks when managing multiple projects?
- 04
Can you share an example of how you have worked effectively as part of a team?
- 05
Discuss an instance where you identified and resolved a significant bug in a software project.
- 06
Describe a scenario where you had to balance trade-offs in system design.
How many rounds does the Arch Systems Software Engineer loop have?
Candidates report three stages: a Phone Screen with a recruiter about your interest and basic qualifications, a Technical Interview built around practical exercises that show coding and problem-solving, and a Behavioral Interview about fit with the team and culture. Candidates put the process at about 3-5 weeks, and timelines can vary by team.
PracHub Software Engineer practice ↗Which technical topics do candidates report?
Django, advanced SQL, SQL query writing, system design and code review are the topics named, along with XML and XML Schema (XSD) and understanding a Django codebase. The reported questions include XML and its uses, REST versus SOAP, managing version control, database schema factors and designing a real-time data processing system. The day 3 to 5 plan blocks cover these.
PracHub Software Engineer practice ↗What coding questions are reported, and which language should I use?
Two are reported: write a function to reverse a string in a language of your choice, and find the maximum sum of non-adjacent numbers in a list of integers. The role lists Python, Java, JavaScript and C++, so use the one you are strongest in. For the string question, know the built-in idiom and an in-place version. For the sum, know the take-or-skip dynamic programming solution with O(1) space.
PracHub Software Engineer practice ↗How should I prepare for the behavioral round?
Write four or five real stories and map each to several prompts: the challenging project, prioritizing across projects, working in a team, the significant bug, and a design trade-off. For each, write the decision you made, a result you can defend and one thing you would change. Add a disagreement story and a feedback story, since conflict resolution and feedback are among the areas candidates describe.
PracHub Software Engineer practice ↗Is there a take-home assignment?
None is reported. Candidates describe practical exercises in the Technical Interview instead. Ask the recruiter in the Phone Screen what format to expect, which languages are allowed and whether you will work in a shared editor, then prepare for that format.
PracHub Software Engineer practice ↗How much cloud and DevOps should I know?
Candidates describe AWS or Azure, Docker, Kubernetes, DevOps practices and CI/CD pipelines as nice-to-have, while Python, Java or C++, web frameworks, database design, Agile and version control are the must-haves. Put your time into Django, SQL and design first. Then be able to say in plain terms how you containerize a service and what a CI pipeline runs before a merge.
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.
- 01Arch Systems 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.
Discord Software Engineer Interview Guide
Database practice for Discord candidates: how an index changes a query plan, and which anomalies survive a given isolation level, since read committed still permits non-repeatable reads.
CoreWeave Software Engineer Interview Guide
Failure-handling practice for CoreWeave 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.
Aerospike Software Engineer Interview Questions & Guide 2026
Aerospike database-engine preparation through an original single-owner Python key-value store with bounded logical index accounting, disk-offset reads, conditional writes, tombstones, process-restart recovery and 3,240 checks. Existing 14 p