Senior Backend Engineer

Evidence sought: Candidate-specific scope, recency, and accountability for live backend services, production Python, and any transaction-heavy domain work.

Assessor: Recruiter / TA · Recruiter trained on backend role terminology, required-versus-preferred distinctions, and structured evidence recording.

Question

Walk me through your most relevant recent production backend role: what did the system do, what did you personally build and operate, and how did you use Python in production?

Probes

• Which production responsibilities remained yours after release?
• What was the most consequential operational issue you personally handled?
• What proportion of the relevant implementation was in Python, and what kinds of Python services or components did you change?
• Did the system process payments, financial events, or another high-volume or high-consequence transaction flow? If so, what concerns were distinctive?

Assessor guidance

Use the same core prompts for every candidate. Distinguish personal ownership from team exposure and record the scale and consequences of the system without treating the preferred domain as mandatory.

Evidence sought: Explicit compatibility or dependencies concerning remote work from Spain, quarterly Barcelona attendance, and scheduled incident-response coverage under the terms confirmed before launch.

Assessor: Recruiter / TA · Recruiter briefed on approved location, travel, employment, and incident-response terms.

Question

Based on the working arrangements we have described, are you able and willing to work remotely from Spain, attend quarterly sessions in Barcelona, and participate in the scheduled incident-response coverage?

Probes

• Are there any location, travel, scheduling, or employment dependencies we should record?
• What questions do you need answered before confirming these arrangements?

Assessor guidance

Present only terms approved through pre-launch clarification. Record each component separately and do not infer legal eligibility or impose unstated availability rules.

Evidence sought: Direct evidence of production-oriented Python implementation, testing, maintainability, and concise written explanation.

Assessor: Domain SME · Senior backend engineer with current production Python experience and training in structured work-sample evaluation.

Candidate task

Extend a small Python backend service that accepts transaction-like requests. Implement one specified endpoint and one asynchronous processing step; handle duplicate requests and a supplied downstream failure mode; add focused tests; and write a short note explaining assumptions, operational risks, and what you would change before production deployment.

Expected artifact

Runnable Python changes, focused automated tests, and a concise written engineering note.

Constraints

Target 90 minutes. Use the supplied local dependencies and interfaces; no cloud account is required. Permitted documentation and coding tools must be declared consistently. The task is not expected to be production-complete.

Assessor guidance

Use a fresh, bounded repository with automated setup. The SME should evaluate engineering reasoning and artifact quality, not stylistic conformity to a single solution. Provide reasonable accessibility adjustments and disclose permitted tools consistently.

Evidence sought: Integrated system reasoning about APIs, asynchronous flows, relational data, cloud deployment, and failure handling at senior hands-on scope.

Assessor: Panel · Two assessors: a senior distributed-backend engineer and an infrastructure or platform engineer, with one member experienced in production relational databases.

Candidate task

Design an evolution of a transaction-heavy backend that receives API requests, persists state in a relational database, invokes an asynchronous external integration, and must tolerate retries and partial failures. Explain service boundaries, contracts, data flow, consistency choices, duplicate handling, database design and migration approach, deployment and rollback, scaling, and operational failure behavior.

Expected artifact

A diagram or structured notes plus an oral walkthrough of assumptions, decisions, alternatives, and unresolved risks.

Constraints

60 minutes total, including questions. The exercise is technology-flexible and requires no exact capacity calculation or vendor-specific syntax. Assessors may introduce one changed requirement during the discussion.

Assessor guidance

Evaluate discovery of assumptions, coherence of trade-offs, and treatment of production failure modes. Do not require a particular vendor, architecture pattern, or authoritative solution. Ask equivalent prompts and disclose scenario information consistently.

Evidence sought: Prioritization of reliability, observability, testing, and maintainability controls; ability to communicate architecture recommendations and connect them to hands-on implementation.

Assessor: Hiring Manager · Engineering manager or technical lead familiar with the role's production scope and senior individual-contributor expectations.

Candidate task

Present the three highest-priority steps you would take to make the proposed system safe to launch and sustainable to operate. For each, explain the failure or maintenance risk addressed, the signals and tests needed, the implementation work you would personally expect to perform, and where you would seek review or partnership.

Expected artifact

A 10-minute spoken recommendation followed by a structured 15-minute discussion.

Constraints

Use the system-case artifact; no additional preparation is required. Architecture authority must not be assumed beyond making and influencing recommendations.

Assessor guidance

Treat this as a structured extension of the case rather than a second design test. Record whether recommendations are actionable, proportionate, and connected to code-level or delivery-level work.

Evidence sought: Verified past operational ownership and any optional evidence of improving incident practices or operating orchestrated services.

Assessor: Domain SME · Senior backend, reliability, or platform engineer experienced in incident response and production service operations.

Question

Tell us about a significant production incident or recurring reliability problem in a backend service for which you held meaningful responsibility.

Probes

• What did you personally observe, decide, and change during mitigation?
• How did you verify recovery and protect against recurrence?
• Did this lead to changes in alerts, on-call practice, incident learning, or service objectives?
• Was Kubernetes or another orchestration platform involved, and what did you personally do within it?

Assessor guidance

Separate participation from ownership and distinguish restoration actions from durable follow-up. Lack of Kubernetes, incident-program improvement, or service-level-objective experience affects only the associated preferred dimension.

Evidence sought: Evidence of technical guidance that developed another engineer's judgment or autonomy without relying on line-management authority.

Assessor: Hiring Manager · Engineering leader experienced in supporting senior individual contributors who mentor junior engineers.

Question

Describe a time you helped a less-experienced engineer handle a technically difficult backend task or production responsibility.

Probes

• How did you determine what support they needed?
• What did you do instead of solving the problem for them?
• How did you give feedback or create safe checkpoints?
• What evidence showed a change in their capability or autonomy?

Assessor guidance

Look for sustained guidance, adaptation, feedback, and learner outcomes rather than simply correcting code or taking over difficult work.

Evidence sought: Clear spoken collaboration around an architecture recommendation, including influence, implementation involvement, and any auditability or resilience constraints from regulated work.

Assessor: Cross-functional Partner · Product, infrastructure, security, or engineering partner who regularly evaluates technical proposals with backend engineers in distributed teams.

Question

Tell us about an architecture recommendation you developed with partners and then helped implement in code or delivery work.

Probes

• How did you communicate the recommendation and competing trade-offs?
• Who held final decision authority, and how did you respond to disagreement?
• What hands-on implementation or review work did you retain?
• Were auditability, regulated change, or operational-resilience obligations relevant? If so, how did they shape the work?

Assessor guidance

Assess clarity and collaborative behavior, not accent or presentation polish. Regulated-system experience is preferred only; do not penalize its absence under architecture or communication criteria.

Record system context, candidate actions, duration of ownership, production consequences, and operating responsibilities after release.

Record production recency and scope separately from work-sample observations; note reasoning, tests, error handling, and maintainability.

Record reasoning about contracts, asynchronous behavior, consistency, retries, idempotency, and partial failures.

Record schema, transaction, indexing, query, migration, rollback, and production-data reasoning actually discussed.

Record platform-independent deployment and cloud-operating decisions; do not require a named provider.

Record priorities and their links to failure modes, signals, tests, operability, and long-term ownership.

Record recommendation scope, influence process, decision authority, and direct coding or delivery contribution.

Record learner context, candidate interventions, adaptation, feedback, and evidence of learner progress.

Assess whether technical meaning is clear in writing and speech; do not assess accent, idiom, or presentation style unrelated to distributed collaboration.

Record confirmation or dependencies separately for Spain-based remote work, quarterly Barcelona attendance, and incident-response participation.

Record transaction characteristics and candidate responsibilities; retain this as preferred evidence only.

Record concrete orchestration actions and depth; retain this as preferred evidence only.

Distinguish incident participation from improvement of the surrounding practice; retain this as preferred evidence only.

Record the actual obligation and resulting engineering control; retain this as preferred evidence only.