Arch Systems Software Engineer Interview Guide

The 60-second brief

Candidates describe the Software Engineer role at Arch Systems as designing, building and maintaining software for the company's products, from new features to troubleshooting applications that already exist, in cross-functional work with product management, engineering and operations. The reports do not name the products, the customers or the architecture, so this guide does not guess at them. What candidates do mention is the skill set: Python, Java or C++ with a web framework (Django comes up by name), solid database and SQL design, Git, and Agile working, with AWS or Azure, Docker, Kubernetes and CI/CD listed as extras.

This guide is for candidates interviewing for a Software Engineer role at Arch Systems. It covers the three reported rounds (Phone Screen, Technical Interview, Behavioral Interview), the fifteen questions candidates report across technical knowledge, system design, problem-solving, coding and behavioral topics, and a seven-day plan that turns them into practice. It does not cover other roles or levels, and it makes no claims about pay.

Candidates report three stages, a Phone Screen, a Technical Interview and a Behavioral Interview, over roughly 3-5 weeks. Reports do not say which question belongs to which stage, so this guide prepares you by question type.

Focus areas

• Django
• Advanced SQL
• System Design

Overview

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.

The Arch Systems interview process

Candidates report three stages over roughly 3-5 weeks: a Phone Screen, a Technical Interview and a Behavioral Interview. The reports do not assign individual questions to stages, so prepare each stage by its type of question.

Phone Screen

Candidates 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

Candidates 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

Candidates 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.

Where candidates lose points

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.

Questions & practice

Write a function to reverse a string in [specific programming language].

Medium · Coding / Algorithms

Approach

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

Medium · Coding / Algorithms

Approach

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

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?

What factors do you consider when designing a database schema?

Medium · System Design / Architecture

Approach

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

Easy · soft delete · unique constraints · engine differences

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

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

Medium · Technical / Domain Questions

Approach

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

Medium · Technical / Domain Questions

Approach

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

Medium · Technical / Domain Questions

Approach

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

Medium · Technical / Domain Questions

Approach

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

Medium · System Design / Architecture

Approach

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

Medium · System Design / Architecture

Approach

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

Medium · Problem-Solving / Case Studies

Approach

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

Medium · Problem-Solving / Case Studies

Approach

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

Suggested practice checklist

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.

Day 1 — Map 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.

Day 2 — Coding: 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.

Day 3 — SQL 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.
• 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.

Day 4 — Django, 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.

Day 5 — System 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.
• 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.

Day 6 — Debugging, 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.

Day 7 — Behavioral 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.

Stories for the behavioral round

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.

1. Discuss an instance where you identified and resolved a significant bug in a software project.
2. Describe a scenario where you had to balance trade-offs in system design.

Describe your experience with [specific programming language or technology].

Medium · Technical / Domain Questions

Approach

1. 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.
2. 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.
3. 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++).
4. 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.
5. 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.

Medium · Behavioral / Leadership

Approach

1. 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.
2. 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.
3. 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.
4. Say 'I' for your own decisions and 'we' only for team work, and name the help you asked for and from whom.
5. 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?

Medium · Behavioral / Leadership

Approach

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

Medium · Behavioral / Leadership

Approach

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