Senior Full-Stack Engineer (Long-Term, Startup)

Senior Full-Stack Engineer — Backend Stability, Database Concurrency, Web & Mobile Long-Term Startup Engagement: Pre-Beta → Beta → Official Launch ============================================================ READ THIS FIRST — SERIOUS APPLICANTS ONLY You must answer every one of the 25 screening questions in the Mandatory Screening Questions section below to be considered. If you are not prepared to answer all of them in your own words and in technical detail, do not apply. Applications without complete answers will not be read. Answers that are generic, copied or AI-generated without your own reasoning will be rejected. This is the first of several waves. Applicants who pass Wave 1 will receive further waves of written technical questions based on their answers. Each wave is harder than the last. This is not a quick-fix job. We are looking for a long-term senior full-stack engineer who has worked at startups, has personally launched mobile apps to production, is available on weekends when launch work requires it, and wants to grow with the product. This is not an immediate money opportunity. We are a startup and funds are limited right now. Compensation during pre-beta and beta may not match the work required. We are looking for someone who sees the vision and is willing to do what it takes to get us to official launch, with a deeper compensation discussion once revenue is coming in. Delayed gratification will be heavily considered. Read Section 3 before applying. This is a fixed budget of two milestones of $900 each (Section 4). The work will take more hours than the budget covers, including weekends. Unforeseen bugs, engineering changes, and optimization are in scope. This position is extremely key. You will provide and execute the plans for pre-beta, beta, and official launch, lead the team through them, and work with the Lead Developer. Execution ability, leadership ability, and full launch experience are required. We are looking for a game changer. Make no mistake about it: the person we choose must be extremely skilled, thorough, efficient, used to launching apps, and able to move us through pre-beta, beta, and official launch. Please do not apply if you are not serious or not strong technically. Please do not waste your time or ours. To show you read this whole document, begin your proposal with the words “Root cause first.” Proposals that do not begin this way will not be read. ============================================================ 1. ROLE PURPOSE We are seeking a highly capable Senior Full-Stack Engineer to work alongside the existing Lead Engineer on complex backend, web frontend, and mobile engineering work, including backend stabilization, database remediation, concurrency correctness, performance under load, security-sensitive workflows, CI/CD reliability, and regression prevention as the product moves from testing to public launch of its mobile apps. This is not a replacement Lead Engineer position. It is a launch leadership and execution role: you will produce the execution plans for pre-beta, beta, and official launch, lead the team through them alongside the Lead Engineer, and do hands-on engineering to get each phase done. The selected engineer must operate as a senior technical partner who can independently investigate difficult defects, work collaboratively with the Lead Engineer, review and challenge technical assumptions, take ownership of assigned remediation workstreams, identify issues beyond the initially reported line of code, produce production-quality fixes and tests, explain technical findings clearly, work within the existing architecture rather than unnecessarily redesigning it, escalate genuine architectural risks, and help the team close difficult findings faster without introducing new regressions. The ideal candidate is someone the Lead Engineer can assign a difficult backend, frontend, or mobile problem to and reasonably expect: root-cause analysis → technically sound solution → regression protection → clean PR → validation evidence → handoff. 2. WHO WE ARE LOOKING FOR Technical strength alone is not enough. We are looking for a specific kind of engineer: - Full-stack depth. You can take on complex backend and frontend work: NestJS/PostgreSQL services, Next.js web apps, and React Native/Expo mobile apps. You are extremely experienced across a broad range of areas, because the scope here is broad and the team is small. - Startup experience. You have worked at early-stage companies where the team is small, priorities shift, there is no separate SRE, QA or DBA team, and you own problems end to end. - Mobile launch experience. You have personally helped launch at least one mobile app to the Apple App Store and/or Google Play and supported it through its first weeks in production. You understand that old app versions stay in the field and the backend must keep serving them. - Launch-ready availability. Weekend work is required during launch windows, release-blocking defects, critical regressions, load-test reruns, and milestone closeout. - Long-term commitment. This is an ongoing engagement, not a single ticket. We want someone who will learn the system deeply, stay through public launch and beyond, and grow with the product. - Belief in the product. This is a personal safety app. Defects here are not cosmetic: a race condition can mean a contact sees stale location, a recording does not restart, or an alert is sent twice. You must care about getting it right. - Execution and leadership. You can see what needs to happen, turn it into a plan, lead the team through it, and execute it yourself. You have full experience launching, from first testers to a public release, and you work well with a Lead Developer without stepping on their role. - A game changer. You raise the level of the whole team. You are thorough and efficient, you find what others miss, and you move the product measurably closer to launch every week, not just close tickets. - Payments, finance, and security. You can handle Stripe, Avalara, and QuickBooks, the platform’s internal financial management, and application security, and you understand the financial, technical, and security nuances between them. - Ownership without ego. You can disagree with evidence, accept review, and leave the code easier for the rest of the team to maintain. 3. THE VISION, THE PATH TO LAUNCH, AND COMPENSATION This is not a one-time opportunity, and it is not an immediate money grab. We are looking for someone who sees the vision, is willing to stick with it, and is willing to do what it takes to get us to pre-beta, beta, and official launch. Our path to launch: - Pre-beta — internal testing. A set of internal testers uses the product. The environment must be ready for them, and the bugs they find must be fixed and resolved before beta. - Beta — public launch, free service. We launch to the public, and people use the service free for a few months while we build our user base. The platform must be operationally ready end to end. - Official launch — paid service. This is when we begin charging for the service. - After official launch — growth. We build revenue and a strong base so that we can offer a decent salary long term. Compensation. As a startup, our funds are limited right now. Compensation during pre-beta and beta may not match the work you will do. A deeper and more reasonable compensation discussion will happen once revenue is coming in and we have built a strong base. You must be willing to work toward the vision of what we are building rather than immediate financial reward. The current budget is two fixed milestones of $900 each (Section 4). We are being direct: the work required to get us through official launch will take more hours than this budget covers, including weekends. Only apply if you accept that. Delayed gratification is required. We will weigh it heavily when reviewing every application, and Question 24 asks you to respond to it directly. If you are looking for immediate financial reward, this is not the right fit. Please do not apply. This document does not promise any specific future compensation, salary, or equity. Any future arrangement will be agreed separately in writing. 4. MILESTONES AND DELIVERABLES This engagement is structured as two fixed-price milestones. Each milestone is released when its deliverables are complete and meet the Definition of Done, with evidence. Milestone 1 — Pre-Beta and Beta Readiness ($900): Get the platform ready for pre-beta, then move it through pre-beta and into beta. First deliverable: the Pre-Beta Execution Plan and the Beta Execution Plan (see the Launch Execution Plans section), reviewed with the Lead Engineer and approved before execution begins. The engineer then leads and executes both plans. - Onboarding. Access set up within the Scan Authorization Matrix, local environment running, review of the Findings Register, architecture, CI, and open PRs. Within the first week, a written assessment of the top technical, financial, and security risks to launch. - Checks and balances. Required CI gates confirmed to actually run; regression tests added for every fix; evidence package on every PR. - Load stability. CPU and database statements per request reduced, transaction scope shortened, the 50-user load test passed on rerun, and support for the higher load tiers, with hosting recommendations backed by measurements. - Compliance and consent flows. Age, consent, and guardian-consent flows behave exactly as approved, including the payment verification hold being placed and released correctly. - Mobile readiness. Session state stays in sync with the server, background recording uploads are reliable, and closed-testing builds are ready for invited testers. - Payments (test mode). Stripe flows verified end to end: holds, captures, cancellations, refunds, and idempotent webhook handling. - Security review. Review of the pre-beta and beta surface: authentication, authorization, secrets handling, access control, and dependency risk, with findings fixed or formally dispositioned. - Audit support. Support for the frozen build and isolated environment used by the external audit, and fixes for its findings. - Pre-beta execution. Environment ready for internal testers; every bug found in pre-beta triaged, fixed, and resolved before beta, with evidence. - Beta execution. Public beta launched with onboarding, core functionality, and support processes operationally ready end to end. - Beta readiness sign-off. A readiness checklist with evidence, and handoff notes. Milestone 2 — Official Launch Readiness ($900): Carry the platform from beta through official launch, when we begin charging for the service. First deliverable: the Official Launch Execution Plan, reviewed with the Lead Engineer and approved before execution begins. The engineer then leads and executes it. - Carryover. All open bugs and engineering work from Milestone 1 and from beta feedback closed with evidence. - Live payments. Stripe in live mode: charges or subscriptions, refunds, disputes, payouts, and multi-entity handling, with webhooks that are idempotent and reconciled. - Tax and accounting. Avalara tax calculation integrated and verified; QuickBooks sync working and reconciled against Stripe; the platform’s internal financial records and reports accurate. - Production readiness. Load tested at the launch target, hosting sized from evidence, monitoring, tracing, and alerting in place, and a rollback plan. - Pre-launch security review. Findings fixed, secrets and keys rotated where needed, and basic incident-response steps documented. - Store release. Production App Store and Google Play releases, an OTA update policy, and backward compatibility with older app versions. - Launch sign-off. Launch readiness checklist with evidence, updated Findings Register, and handoff documentation. Unforeseen Work: There will be bugs. There will be software engineering changes, modifications, optimization, and other unseen work that is not listed in a specific deliverable. That work is part of this engagement, and the engineer must be able to handle it. Anything open at the end of Milestone 1 carries over into Milestone 2. 5. LAUNCH EXECUTION PLANS This position is extremely key. The engineer must provide three execution plans, lead the team through each one with the Lead Engineer, and execute on them. A plan without execution, or execution without a plan, does not meet this requirement. Pre-Beta Execution Plan (internal testers): Goal: the environment is ready for a set of internal testers, and the bugs they find are fixed before beta. Beta Execution Plan (public launch, free service): Goal: the platform is operationally ready end to end for the public. Onboarding works, the app's functionality works, and the platform is optimized so it runs without bugs or other issues and has the capacity to handle a large number of users as it grows. Official Launch Execution Plan (paid service): Goal: the platform is ready to charge customers, with payments, tax, accounting, security, and capacity ready for growth. Each plan must include: - Readiness criteria. What “ready” means for that phase, and the evidence that proves it. - Environment readiness. Servers, database, configuration, secrets, builds, and access ready for that phase. - Onboarding and core flows. End-to-end checks of sign-up, onboarding, consent, and the main safety features on real devices. - Bug triage and resolution. How bugs are reported, ranked by severity, assigned, fixed, verified, and closed, with target times per severity. - Capacity and optimization. Load targets for that phase, test results, optimization work, and hosting sizing for growth. - Monitoring and incident response. What is watched, who is alerted, and what happens when something breaks. - Go / no-go criteria. The conditions that must be met before moving to the next phase. - Rollback plan. How to back out a bad release or update safely. - Team assignments. Who does what, coordinated with the Lead Engineer. - Timeline and risks. The schedule, dependencies, top risks, and how each risk is handled. 6. ENGAGEMENT OBJECTIVE The objective is to strengthen and stabilize the platform (backend, web, and mobile) for launch while reducing the engineering time spent repeatedly diagnosing regressions, revisiting previously fixed defects, correcting weak pull requests, and troubleshooting failures that should have been identified before merge. The engineer will work on identified defects involving PostgreSQL, Prisma, NestJS, Redis, database transactions, connection pooling, concurrency, locking, retries, idempotency, background jobs, maintenance workers, the outbox pattern, compliance workflows, authentication, authorization, session state, evidence-write integrity, Stripe and webhook processing, Avalara tax calculation, QuickBooks integration, internal financial management and reconciliation, application security, Next.js web applications, React Native/Expo mobile client behavior and API contracts, load-test remediation, observability, CI/CD, GitHub Actions, and automated regression testing. The objective is not merely to make the reported error disappear. The engineer must determine whether the underlying technical, security, safety, compliance, concurrency, or integrity rule is correctly enforced across all materially equivalent execution paths. 7. RELATIONSHIP WITH THE LEAD ENGINEER The selected engineer will work under the overall technical direction of the Lead Engineer and is expected to complement the Lead Engineer, not compete with or unnecessarily duplicate the Lead Engineer's responsibilities. The engineer must respect existing architectural ownership, coordinate before making material cross-cutting changes, raise concerns with technical evidence, propose alternatives when appropriate, accept technical review, clearly document material technical disagreements, avoid unnecessary rewrites, and leave the codebase easier for the existing team to maintain. At the same time, the engineer must demonstrate independent technical judgment. If the engineer identifies a race condition, security weakness, unsafe retry, hidden regression, incorrect assumption, unreliable test, architectural inconsistency, or another material risk, the engineer is expected to raise it promptly and explain the technical basis. The engineer should not simply implement instructions without evaluating whether they are technically correct. 8. REQUIRED EXPERIENCE AND TECHNICAL CAPABILITY Minimum Experience: - 10+ years of professional software engineering across backend, web frontend, and mobile, with at least 3 years at startups or early-stage product teams. - Hands-on involvement in launching at least one mobile app to production (App Store and/or Google Play), including the backend that serves it. - Production ownership of PostgreSQL-backed systems under real concurrent load: you have diagnosed lock contention, pool exhaustion, or deadlocks in production yourself. - Demonstrable work you can discuss in detail: PRs, incidents, postmortems, or architecture you personally owned. Backend Engineering: - Node.js and TypeScript at a senior level - NestJS or a comparable enterprise backend framework - REST APIs, versioning, and backward compatibility with older mobile clients - asynchronous processing, background workers, schedulers - webhooks and external provider integration - distributed backend services and partial-failure handling - stateful workflow and state-machine design Database Engineering: - PostgreSQL internals relevant to locking: row-lock modes (FOR UPDATE, FOR NO KEY UPDATE, FOR SHARE, FOR KEY SHARE), MVCC, snapshots - Prisma or a comparable ORM, including interactive transactions and their limits - transaction boundaries, isolation levels, serialization failures, deadlocks - unique and partial unique indexes, constraints, ON CONFLICT - lock_timeout, statement_timeout, idle_in_transaction_session_timeout - pg_stat_activity, pg_locks, pg_stat_statements, EXPLAIN (ANALYZE, BUFFERS) - connection pooling (application pools and PgBouncer modes) - zero-downtime migrations on large, hot tables Reliability and Performance Engineering: - idempotency, retries, duplicate-request and duplicate-job prevention - race-condition prevention and final-decision revalidation - outbox pattern and at-least-once delivery - timeout handling, failure recovery, partial-failure analysis - load testing, CPU-per-request analysis, and capacity planning - distinguishing code inefficiency from host or infrastructure contention Frontend and Web Engineering: - React and Next.js at a senior level (App Router, server components, SSR/SSG, middleware, caching) - TypeScript state management, data fetching, and cache invalidation - forms, validation, error states, and accessibility - web authentication flows: cookies, sessions, CSRF, token refresh - security headers, CSP, and dependency upgrades of major frameworks - web performance (Core Web Vitals, bundle size, rendering cost) Mobile Engineering and Client Contract: - React Native / Expo app development, not only backend integration - native modules, permissions, location, audio/video capture, background tasks - EAS builds, App Store and Google Play submission and review - OTA updates, runtime versions, and API compatibility across app versions - offline-first clients, background execution limits on iOS and Android, chunked and resumable uploads Payments, Tax, Accounting and Platform Financial Management: - Stripe: PaymentIntents, manual capture and authorization holds, subscriptions, refunds, disputes, payouts, Connect and multi-entity setups - Stripe webhooks: signature verification, event deduplication, out-of-order events, reconciliation - Avalara (or comparable) tax calculation, tax-on-refund handling, and nexus considerations at a technical level - QuickBooks Online integration: syncing invoices, payments, refunds and fees; avoiding duplicate entries; reconciliation - internal financial records: ledgers, balances, audit trails, and reports that match the payment provider - keeping card data out of scope (PCI) and protecting financial keys and credentials Security: - application security: OWASP Top 10, authentication, authorization, session management - secrets management and key rotation - access control for environments, databases, and third-party consoles - dependency and supply-chain risk - security review of new features before release, and incident response basics Infrastructure: - Docker, nginx, Linux servers, DNS, and TLS - Redis - cloud hosting and sizing (shared vs dedicated CPU, managed databases, load balancers) CI/CD, DevSecOps, Observability and Testing: - GitHub Actions, required checks, merge gating, workflow debugging, actionlint - static analysis (Semgrep), dependency and secret scanning (npm audit, Gitleaks) - automated review tooling (CodeRabbit, Greptile) and judging its findings - Sentry / OpenTelemetry tracing and span structure - Jest, PostgreSQL integration testing, deterministic concurrency testing, failure injection, regression and negative testing 9. EXPECTED ENGINEERING LEVEL This role is intended for a senior-level engineer. A candidate whose experience is primarily CRUD development, experience limited to one layer of the stack, simple API integration, or ordinary bug fixing is unlikely to be appropriate. The selected engineer should be comfortable investigating situations where a defect only appears under concurrency; the problem occurs between multiple database transactions; a retry happens after an earlier side effect; cached state becomes stale during an asynchronous operation; two workers process the same record; a session terminates while another request is still executing; a CI workflow silently stops running an important test; a database timeout occurs after partial work; lock ordering creates deadlocks; a load test fails because of host CPU contention rather than slow queries; an older mobile build sends a request shape the backend no longer expects; a mobile screen shows a session as active after the server ended it; a web page serves one user’s cached data to another; or the visible error is only a symptom of a deeper architectural problem. 10. CORE WORKSTREAMS 1. Connection-pool exhaustion and idle-in-transaction sessions. 2. Long-running Prisma transactions and transaction-scope reduction. 3. Database timeout behavior, lock timeouts, and statement timeouts. 4. Deadlocks, serialization failures, and lock ordering. 5. Load-test remediation: CPU per request, statements per request, and host-contention analysis. 6. Background-job collisions and maintenance-worker concurrency. 7. Session integrity and recording-session integrity. 8. Authorization race conditions and revocation handling. 9. Cache/state reconciliation. 10. Compliance acknowledgement and consent concurrency. 11. Evidence-write integrity: durable record before any irreversible action. 12. Outbox side writes and post-response work. 13. Stripe payment-hold and webhook reliability. 14. Duplicate processing, retry, and idempotency correctness. 15. Database index and migration remediation. 16. Mobile client/API compatibility across app versions. 17. Observability: trace structure, worker visibility, alert quality. 18. CI failures, GitHub Actions reliability, and pre-merge defect prevention. 19. PostgreSQL regression testing. 20. Web frontend defects: auth/session handling, caching, framework upgrades. 21. Mobile client defects: state reconciliation, background behavior, permissions, offline handling. 22. Equivalent-path review. 23. Failure, timeout, and database recovery behavior. 24. Deployment-sensitive backend defects. 25. Stripe, Avalara, and QuickBooks integration and reconciliation. 26. Internal financial management on the platform. 27. Security review and hardening before beta and before official launch. 28. Pre-beta, beta, and official launch execution planning and leadership. 11. ENGINEERING STANDARDS (FULL DETAIL IN THE ATTACHED SOW PDF) The attached SOW PDF contains the full engineering standards that apply to all work: root-cause requirement, concurrency standard, performance and capacity standard, PostgreSQL testing standard, retry and idempotency standard, pull request requirements, regression-test and CI requirements, required pre-merge checks, review finding disposition, AI-assisted engineering rules, branch drift and merge safety, communication standard, required evidence package per PR, handoff requirements, turnaround and weekend availability, security and access boundaries, and the definition of done. In short: every fix needs a root cause, equivalent paths reviewed, a regression test that fails before and passes after, real PostgreSQL tests where the database is involved, green CI where every required check actually ran, and evidence. A code change is not acceptance. Weekend availability is required during launch windows and release-blocking issues. 12. MANDATORY SCREENING QUESTIONS — WAVE 1 Applicants must answer all 25 questions. An application with any question unanswered will not be read. These are intentionally difficult. For each question, explain the actual implementation, the exact sequence of events, the SQL or database behavior, the failure conditions, the testing approach, and the evidence you would use to prove the correction. Generic explanations of concepts are not sufficient. Where a question asks for SQL or pseudocode, provide it. Number your answers to match the questions. Short, precise answers are better than long, vague ones. Question 1 — Stale Authorization Across an Async Gap A request reads an active session and confirms Contact A is authorized (statement 1). It then performs a Redis lookup that takes 300 ms. During those 300 ms, another request revokes Contact A, terminates the session, and commits; the Redis cache is invalidated a moment later by a separate step. Redis returns an empty result, and the original request returns authorized: true, terminal: false, and no coordinates. A developer’s fix re-checks authorization only when Redis returns a live result. Your answer must cover: the exact race window; why the developer’s fix is wrong; the SQL for a final committed-state check, and whether it must be the same statement that reads the protected data or can be a separate one; what READ COMMITTED guarantees per statement versus REPEATABLE READ here; and what the response must be when the final check finds the session terminated. Question 2 — Read-Then-Insert Race With a Partial Unique Index A service SELECTs a Live Location session by (user_id, session_type, device_session_id); if none exists it INSERTs. Two requests arrive simultaneously and both INSERT. Only one active session may exist, and only when location_sharing_enabled = true and device_session_id IS NOT NULL. The code uses Prisma and runs inside an interactive transaction. Your answer must cover: the partial unique index DDL; why wrapping SELECT + INSERT in a READ COMMITTED transaction does not fix it; the INSERT … ON CONFLICT form that works with a partial index (including the conflict-target predicate); why Prisma upsert cannot express it; what happens to the surrounding transaction after a unique violation (SQLSTATE 25P02) and how a savepoint or separate statement avoids it; and how the losing request returns the canonical existing session instead of HTTP 500. Question 3 — Load Test Fails: Pool Exhaustion or Host Contention? A 50-user load test on a NestJS/Prisma API (2 shared vCPUs, pool of 20) served most requests but had repeated 20–30 second stalls. During stalls: pool at 20/20; several sessions idle in transaction holding session row locks; others failing with lock timeout (55P03); clients timing out at 18 s. PostgreSQL used about 14% of one core. Host metrics show CPU steal of 21–33% during each stall. Steady state is about 0.075 CPU-seconds per request. Your answer must cover: the causal chain from steal to idle-in-transaction to lock timeouts; why raising the pool to 40 would likely worsen it; what you would measure to prove steal is the trigger rather than slow queries; what code changes reduce exposure (statements per request, transaction scope, work after response); what idle_in_transaction_session_timeout and lock_timeout settings you would use and their risks; and when changing to dedicated CPU is the correct fix versus covering poor code. Question 4 — External Provider Call Inside a Transaction, With Unknown Outcome A worker begins a transaction, selects an evidence record FOR UPDATE, marks it processing, calls an external storage provider (up to 10 s), marks it complete, and commits. Sometimes the provider succeeds but the HTTP connection drops before the response arrives. Your answer must cover: what is wrong with this design under load; a redesign where no transaction is held across the provider call while still preventing two workers processing the same object (claim/lease with expiry); the state machine including an UNKNOWN state; the idempotency key and local operation record; how reconciliation queries the provider; and what you do when the provider offers no idempotency or lookup API. Question 5 — Unsafe Automatic Retry An endpoint inserts and commits an audit record, sends an SMS through an external provider, then runs a second database operation that fails with a serialization failure. A global Prisma extension classifies 40001, 40P01, P2024 (pool timeout) and P1001 (cannot reach database) as retryable and re-runs the entire interactive-transaction callback, which contains the SMS call. Separately, a connection drops after COMMIT was sent but before the acknowledgement arrived. Your answer must cover: exactly what each retry can duplicate; which of those four errors are safe to retry at the statement, transaction, or request level and why; how to handle the commit-acknowledgement-lost case; and a safe retry and idempotency design that separates database retries from externally visible side effects. Question 6 — Job Claiming, Crash Recovery, and Zombie Workers Ten workers claim jobs from a jobs table. A worker can crash after claiming, or be paused by the hypervisor for 30 seconds and then resume after its lease has expired and another worker has re-claimed the job. Your answer must cover: the claim query (FOR UPDATE SKIP LOCKED vs advisory locks vs a state-transition UPDATE … RETURNING) and why; lease expiry and recovery; how a fencing token or attempt counter stops the resumed zombie worker from overwriting the new owner’s result; and how you would test the paused-worker case deterministically. Question 7 — Reproduce a Race Deterministically Transaction A reads an authorization record, pauses, Transaction B revokes it and commits, then A returns protected data based on its earlier read. Your answer must cover: how you build a PostgreSQL integration test that hits this interleaving every time without sleep calls: separate connections or clients, the barrier or hook mechanism (for example advisory locks or injected test hooks), commit order, the assertion that proves the fix, and how you show the same test failing against the previous commit. Question 8 — Deadlocks, Including the Hidden Foreign-Key Lock Transaction A updates users then safety_sessions; Transaction B updates safety_sessions then users. After lock ordering is fixed, deadlocks still occur occasionally. Investigation shows concurrent INSERTs into recording_events, which has a foreign key to safety_sessions, while another transaction updates the parent safety_sessions row. Your answer must cover: the original deadlock cycle; which row-lock mode a child INSERT takes on the parent row; which parent UPDATEs conflict with it and which do not (FOR UPDATE vs FOR NO KEY UPDATE); how you confirm the cycle from PostgreSQL logs and pg_locks; how you reproduce it in a test; and whether automatic deadlock retries are an acceptable remediation. Question 9 — Authorization Bound to Mutable Identity Contact access is granted when contact_email matches the authenticated user’s email. The service captures the email, performs a cache lookup, and later compares against the captured value. Meanwhile the user changes their account email, and separately an access token issued before a password reset is still being accepted. Your answer must cover: both vulnerabilities; how the final authorization decision uses current committed identity (stable ID rather than email); and how you would invalidate older tokens (for example a session epoch or token version checked at decision time) without a database hit storm. Question 10 — Optimistic Version Guard A compliance acknowledgement row has version = 7. Two requests try to modify it based on version 7. Only one may succeed. Your answer must cover: the SQL and Prisma mutation that puts the expected version in the update predicate; why UPDATE-then-reread has a larger race window; how you tell “not found” from “stale” when updateMany returns count 0; and what HTTP response and client behavior should follow. Question 11 — CI Says Green but the PostgreSQL Tests Did Not Run During a merge-conflict resolution, a workflow’s YAML is damaged so that one step has no run: or uses:, and another step’s commands are attached to the wrong step. In a separate PR a test file is renamed and no longer matches the Jest test pattern. In a third, a path filter causes a required job to be skipped, and the branch protection treats skipped as passing. Your answer must cover: what controls catch each case before merge (actionlint, required check names, test-count assertions, JUnit reports); how you prove that each named PostgreSQL test actually executed; and how you configure required checks so a skipped job cannot satisfy a gate. Question 12 — PostgreSQL Test Isolation in Parallel CI Three integration suites modify users, safety_sessions, and compliance tables. Each passes alone but fails intermittently when run in parallel. Your answer must cover: how you decide whether this is a real application concurrency defect or test contamination; a disposable-database or schema-per-worker design; and how migrations, seeds, cleanup, connection strings, Jest workers, and parallel jobs are managed. Question 13 — Zero-Downtime Migration on a Large, Hot Table You must add a NOT NULL column with a foreign key and a unique index to a 20-million-row table that receives constant writes. Older mobile app versions that do not send the new field will remain in use for months. The migration tool wraps migrations in a transaction by default. Your answer must cover: the expand/contract sequence; why CREATE INDEX CONCURRENTLY cannot run in a transaction and how you handle that with the migration tool; what you do with an INVALID index after a failed concurrent build; NOT VALID plus VALIDATE CONSTRAINT; setting lock_timeout on DDL; backfill batching; and how old clients keep working. Question 14 — Durable Record Before Any Irreversible Action When a user triggers an emergency action, the system must notify contacts, may call an external dispatch provider, and may start a recording. The rule is that no irreversible external action may occur before a durable record of the triggering event is committed. Your answer must cover: the ordering across mobile client → API → database → providers; what happens if the record write fails or times out; how you guarantee the notification is still sent exactly once (outbox, idempotency); what happens if the phone is offline; and the test that proves no provider call can occur before the commit. Question 15 — Background Recording Uploads From a Mobile App A React Native/Expo app records in the background and uploads chunks. The OS kills the app, the network drops repeatedly, and chunks arrive late, duplicated, and out of order. Some chunks never arrive. Your answer must cover: the server-side design (sequence numbers, idempotent chunk writes, finalize step, gap detection, retention of partial recordings); what iOS and Android background limits mean for the client; how the backend tells “still uploading” from “abandoned”; and how you test it. Question 16 — OTA Updates and the Backend Contract An over-the-air update changes the request body for a compliance endpoint. Some devices are still on the old binary and runtime version and cannot receive the update. A backend deploy is scheduled the same day. One week later the OTA must be rolled back. Your answer must cover: deploy ordering; how the backend serves both request shapes safely; how runtime versions limit which clients receive which update; how you roll back without breaking clients that already sent the new shape; and what must never be changed by OTA alone. Question 17 — Consent Flow With a Payment Hold A guardian-consent flow places a small Stripe authorization hold (manual capture) for verification. In testing, the completion endpoint returned 400, consent was not recorded, and the hold was never released. Webhooks can arrive late, twice, or out of order. Your answer must cover: the state machine across consent, PaymentIntent, and webhooks; how you ensure consent is never recorded without successful verification and no hold is ever left orphaned (cancel/release, a sweeper, reconciliation); webhook event deduplication; and how you would debug the 400 from logs and Stripe test-mode data. Question 18 — Tracing: Late Child Spans and Invisible Worker Jobs In Sentry, each write request produces one HTTP transaction plus about 35 extra “Backend transaction” events. They share the request’s trace ID and start 20–100 ms after the response was sent. The maintenance worker produces no transactions at all; its only output is a client report of spans discarded with reason no_parent_span. Your answer must cover: why post-response work becomes separate transactions when its parent was already exported; why job database work produces no spans when no span is active; the fix for each (for example, a root span around post-response work and around each job run, with fixed, allowlisted names); and the cost and sampling effect of leaving it as is. Question 19 — Live Debugging Exercise Production symptom: a safety walk session remains active after a phone-call interruption, but the required recording generation does not restart. The UI still reports an active session. You have backend logs, mobile logs, PostgreSQL state, Sentry, and PR history. Your answer must cover: the actual investigation procedure: which session and recording-generation identifiers you trace; which state transitions you compare before and after the interruption; how you decide whether the failure is in the mobile client, backend, database, lifecycle recovery, or state sync; what evidence you collect before changing code; and what automated regression test you require before closing it. “Check the logs” is not an answer. Question 20 — Mobile Client State Out of Sync With the Server A React Native/Expo app shows an active safety session. The app is backgrounded, the server ends the session (timeout or another device), and the phone loses network for several minutes. When the app returns to the foreground it still shows the session as active, keeps sending location, and a queued offline action later tries to restart the ended session. Your answer must cover: where the client’s source of truth should live; how the app reconciles on foreground and reconnect (server state version, AppState handling, push or polling); how queued offline actions are validated against current server state so an ended session cannot be revived; what the backend must reject; and how you would test this on real iOS and Android devices, not only a simulator. Question 21 — Next.js: One User’s Data Served to Another After a Next.js upgrade, a signed-in dashboard page occasionally shows another user’s name and contacts. The page fetches user data in a server component using a session cookie. A CDN/nginx layer sits in front of the app. Your answer must cover: every layer that could cache the response (framework data cache, full-route cache, fetch caching defaults, CDN/nginx); how you would prove which layer leaked the data; the correct fix (dynamic rendering, no-store, cache headers, Vary/Cache-Control on authenticated routes); how middleware and cookies interact with static rendering; and the test or check that prevents this after the next upgrade. Question 22 — Startup, Launch, and Commitment This question is weighted as heavily as the technical ones. Your answer must cover: (a) a mobile app you personally helped launch to production: the app or store link if public, your exact role, the backend stack, and the worst production incident in the first 30 days and how you resolved it; (b) a startup you worked at: team size, what you owned, and one decision you made under time pressure that you would make differently now; (c) how you would prioritize if the launch date, a failing load test, and a Lead Engineer request all conflict in the same weekend; (d) confirmation that you can work weekends during launch windows and that you are seeking a long-term engagement. Question 23 — Payments, Tax, and Accounting Stay in Sync A customer is charged through Stripe with tax calculated by Avalara, and the payment is synced to QuickBooks. Later the customer gets a partial refund. The refund webhook is delivered twice and out of order with a dispute event, the QuickBooks sync job times out after QuickBooks accepted the entry, and the internal ledger now disagrees with Stripe. Your answer must cover: the source of truth for each record; how the refund and dispute are applied exactly once (event IDs, idempotency keys, state machine); how the tax on the refund is handled in Avalara; how you prevent a duplicate QuickBooks entry after the timeout; a daily reconciliation design that detects and repairs drift between Stripe, Avalara, QuickBooks, and the ledger; and how you protect the API keys and credentials for all three services. Question 24 — Vision and Delayed Compensation We are a startup with limited funds. Are you willing to do what it takes to get us through pre-beta, beta, and official launch, even though the budget is two milestones of $900 each, the work will take more hours than that, weekends are required, and compensation during that period may not match the work you will do, knowing the long-term benefit comes once we begin charging for the service at official launch and build revenue after it? Your answer must cover: (a) a direct yes or no; (b) why this vision matters to you; (c) a real example where you invested time and effort in something before it paid off; (d) why you would be a game changer for us, not just another contractor; (e) what you need at minimum to stay committed through official launch; and (f) what would cause you to leave, and how much notice you would give. Question 25 — Your Launch Execution Approach You join with the platform close to pre-beta. Internal testers are waiting, the last load test showed stalls, some compliance and payment flows still have open defects, and the team is small. Outline how you would take us through pre-beta, beta (public, free), and official launch (paid). Your answer must cover: for each phase, the readiness criteria, the go / no-go criteria, and the top three risks; what you would do in your first two weeks; how you would run bug triage and resolution with testers; how you would make sure the platform has the capacity to grow; how you would lead the team and divide work with the Lead Developer; and an example of a launch you led, what went wrong, and how you handled it. 13. WHAT HAPPENS AFTER WAVE 1 - Wave 2 and later waves — written follow-up. Deeper questions based on your earlier answers, plus a short code-reading exercise on a sanitized snippet. - A short, scoped trial task may follow before a long-term engagement begins. Each wave builds on the previous one. Applicants who copied answers or relied on AI without understanding will not get through the later waves. 14. TECHNICAL SCREENING EVALUATION Answers are not graded on terminology. Candidates are evaluated on whether they reason correctly through system behavior: identifying specific race windows, describing transaction boundaries, writing or accurately describing the SQL, explaining PostgreSQL locking semantics, recognizing unsafe retries, understanding idempotency across database and provider boundaries, building deterministic concurrency tests, diagnosing pool saturation and host contention rather than simply increasing capacity, distinguishing test contamination from real defects, designing safe migrations, understanding mobile client constraints, reasoning about CI execution rather than CI status, and identifying the evidence required to prove a correction. Perfectly compilable code is not required at this stage, but each answer must be detailed enough for a senior engineer to determine whether the candidate has actually worked on these systems. 15. HIGH-WEIGHT QUESTIONS Questions 1, 2, 3, 4, 5, 6, 8, 13, 14, 19, 20, 21, 22, 23, 24, and 25 receive the greatest weight. A candidate who cannot reason clearly through several of these will not move forward, even with strong general backend experience. Question 19 receives particularly high weight because it tests whether the candidate can methodically investigate a real multi-layer failure alongside the Lead Engineer. Questions 22, 23, 24, and 25 receive high weight because leadership and execution ability, startup and mobile launch experience, long-term commitment, payments and security depth, and willingness to accept delayed compensation are required, not preferred. 16. AUTOMATIC REJECTION INDICATORS An application will not advance if: - any of the 25 questions is unanswered, or the proposal does not begin with “Root cause first.”; - several answers consist mainly of statements such as: use a transaction, add retries, use Redis, increase the connection pool, upgrade the server, use a mutex, add a unique key, run more tests, check the logs, use a queue, or CodeRabbit will catch it; - answers read as generated text without the applicant’s own reasoning, examples, or specifics; - the applicant has no startup experience, has not been involved in a mobile app launch, or cannot commit to weekends and a long-term engagement; - the applicant is looking for immediate financial reward rather than working toward the vision through official launch; - the applicant is strong in only one layer of the stack and cannot take on complex frontend and mobile work as well as backend work; - the applicant cannot handle Stripe, Avalara, QuickBooks, platform financial management, and security; - the applicant does not accept that the work will take more hours than the two-milestone budget covers; - the applicant cannot show launch leadership and execution ability, or cannot produce a credible plan for pre-beta, beta, and official launch. Any of those mechanisms may be part of a valid solution, but they are not sufficient without explaining what state is protected, the transaction boundary, the race being eliminated, database guarantees, failure conditions, partial-success behavior, recovery behavior, and how the candidate would prove the solution works. 17. PREFERRED CANDIDATE PROFILE The preferred candidate is not simply someone who writes clean code. We are looking for a full-stack engineer who has been through startup launches, sees the vision, is willing to accept delayed compensation to get us to official launch, can work next to the Lead Engineer, and can independently own difficult technical remediation: receiving a difficult backend, frontend, or mobile finding → reproducing it → identifying the root cause → discussing the solution with the Lead Engineer → implementing the correction → testing the actual failure condition → surviving automated and human review → providing evidence → handing the work back cleanly. The selected engineer should reduce the technical burden on the Lead Engineer rather than create additional supervision requirements, and should be someone we want to keep building with long after launch. 18. FINAL ACCEPTANCE PRINCIPLE The purpose of this engagement is not to increase the number of pull requests merged. The purpose is to make the platform reliable enough to launch and scale, and to reduce the probability that the same classes of defects return. Successful performance will be evaluated on: correct root-cause analysis + disciplined implementation + real regression protection + valid CI evidence + sound PostgreSQL/concurrency engineering + measured performance work + productive collaboration with the Lead Engineer + technically defensible closeout.