As a Software Engineer at Life.Church, you are more than just a developer—you are a minister using technology as a powerful tool to fulfill the mission to lead people to become fully devoted followers of Christ. You will contribute to high-impact products like the YouVersion Family of Apps, writing clean, scalable code that helps millions of people around the world engage with the Bible and connect with God every day. Your work directly drives digital experiences that encourage, challenge, and inspire people to take their next steps in faith. This role requires balancing technical excellence with a deep, mission-driven mindset. Whether you are building high-performance API Services, crafting fluid mobile interfaces in Android Development or iOS Development, scaling Web Development platforms, or managing critical Data workflows, you will take ownership of tasks from concept to deployment. You'll collaborate closely with designers, product managers, and fellow engineers in a culture that values innovation, high feedback, and continuous learning. You can expect an environment where your code has global reach, but your personal growth and spiritual alignment are equally prioritized. Because Life.Church views staff members as ministers, you will find a unique workplace culture that blends rigorous engineering standards with a profound sense of calling and shared purpose. Preparing for this role means demonstrating both your technical mastery and your heart for ministry.
Recruiter Screen
reportedInitial conversation focusing on your background, motivation for joining Life.Church, and a high-level overview of your technical experience.
What to demonstrate
- Initial conversation focusing on your background, motivation for joining Life.Church, and a high-level overview of your technical experience
- Depth in Take-home coding challenge
How to prepare
- Be able to walk your CV end to end in two minutes, and say why this company specifically.
- Have your salary expectations, notice period and location constraints ready, and ask for the rest of the loop in writing.
Technical Evaluation
reportedInvolves a technical phone screen or a take-home coding assessment, focusing on real-world problems you might face.
What to demonstrate
- Involves a technical phone screen or a take-home coding assessment
- Focusing on real-world problems you might face
How to prepare
- Answer aloud and timed: How would you approach building a responsive web feature using React and Next.js while ensuring performance and accessibility?
- Answer aloud and timed: Can you explain how you design and structure microservices or API endpoints using Python or Golang?
Comprehensive Loop
reportedIncludes deep-dive technical interviews, system design discussions, and behavioral rounds with engineering leaders and potential teammates.
What to demonstrate
- Includes deep-dive technical interviews, system design discussions, and behavioral rounds with engineering leaders and potential teammates
- Depth in Take-home coding challenge
How to prepare
- Answer aloud and timed: How do you write and optimize queries in BigQuery for large-scale data exploration?
- Answer aloud and timed: What strategies do you use for automated testing and maintaining code quality across a distributed codebase?
PracHub editorial advice for the preparation topics above.
Going into the loop without having done this.
Embrace radical authenticity: Do not attempt to craft a persona or give rehearsed, corporate answers during behavioral rounds. Interviewers are deeply skilled at sensing insincerity, and being genuinely yourself is your greatest asset.
Going into the loop without having done this.
Prepare for high feedback: Read up on how the organization values direct, loving feedback. Be ready to share specific examples of how you have handled constructive criticism in past roles without becoming defensive.
Going into the loop without having done this.
Involve your family early: If you have a spouse, keep in mind that they are often included in later interview stages and events. Ensure they are informed, supportive, and prepared to participate in the discernment process.
Going into the loop without having done this.
Tie technology to purpose: Always remember the overarching mission. When discussing your technical projects, connect your engineering decisions back to how they ultimately serve users and advance spiritual engagement.
Going into the loop without having done this.
Clarify technical trade-offs: During coding and system design assessments, narrate your thought process clearly. Explain why you choose certain data structures, algorithms, or cloud architectures over alternatives.
Choose a category, try a prompt, then open its approach, worked solution or follow-up when you need it.
14 technical prompts0 include a worked solution
What experience do you have with asynchronous programming in Swift, and how do you handle concurrency in mobil
medium
What experience do you have with asynchronous programming in Swift, and how do you handle concurrency in mobile applications?
Approach
- Separate the two models: Swift Concurrency (
async/await,Task, actors, since Swift 5.5) and the older GCD/OperationQueuestyle with completion handlers. Say which you have shipped and how you bridged them, since most real iOS codebases contain both. awaitmarks a suspension point that frees the thread instead of blocking it;asyncis not "background". Before Swift 6.2 a nonisolated async function runs on the global concurrent executor; with 6.2'sNonisolatedNonsendingByDefaultit runs on the caller's actor, so mark CPU-heavy work@concurrent.- Use structured concurrency for parallel work:
async letfor a fixed number of child tasks,withTaskGroup/withThrowingTaskGroupfor a dynamic number. Cancellation propagates to children and the parent scope cannot exit until they finish, so child work never outlives the task that started it. - Protect shared mutable state with an
actor(e.g., an image cache) and keep UI updates on@MainActor. Mention actor reentrancy: other calls can run and change actor state at anyawaitinside a method, so re-check invariants after each suspension instead of trusting values read before it. - Handle cancellation cooperatively: check
Task.isCancelledor calltry Task.checkCancellation()in loops. Start screen work from SwiftUI's.taskmodifier, which cancels it when the view disappears; an unstructuredTask {}keeps running unless you keep its handle and callcancel(). - Name the pitfalls: never block the cooperative thread pool with
DispatchSemaphore.wait()or synchronous I/O inside async code; wrap callback APIs withwithCheckedThrowingContinuationand resume exactly once; adoptSendablechecking, which Swift 6 language mode turns into compile errors.
Follow-up
- How do you wrap a delegate API that emits many values over time? Use
AsyncStreamorAsyncThrowingStream, yield from the delegate callbacks, and stop the underlying source inonTermination. - What is the difference between
Task {}andTask.detached {}?Task {}inherits the current actor isolation, priority and task-local values;Task.detachedinherits none, so reserve it for truly independent work. - How do you stop two screens downloading the same image at once? Keep in-flight
Tasks in an actor-held dictionary keyed by URL and have later callers await the existing task instead of starting a new one.
Archive a resource graph without breaking live references or recursing
medium
Resources reference other resources within a tenant; for the largest tenant the reference table holds up to 2,000,000 nodes and 8,000,000 edges. Archiving a resource must archive everything reachable from it that nothing outside the set still references, refuse when a live external referrer exists, and terminate when references form cycles, which they legitimately do. Produce the archive order and the refusal list, targeting O(V+E). Say what stops the traversal crossing a tenant boundary, and why recursion is the wrong control structure at this size.
Approach
- Load the subgraph with the tenant predicate on both endpoints of the edge, not only on the side you started from. Scoping the left table alone is the classic cross-tenant leak: one mis-entered edge then pulls another tenant's resources into the traversal and, worse, into the archive.
- Traverse iteratively with an explicit stack. A 2,000,000-node graph can hold a chain deep enough to exhaust a native stack in the low tens of thousands of frames, and that failure is a process crash rather than an error you can return.
- Treat cycles as data rather than corruption: compute strongly connected components with Tarjan in O(V+E) using its own explicit stack, then condense. The condensation is a DAG, so a topological order over it gives the archive order, and every member of a component archives in one transaction because no order within a cycle is valid.
- Decide refusals with reverse edges. A candidate is archivable only if every in-edge originates inside the candidate set, so build the transpose or count in-degrees restricted to the visited set, and emit each blocked resource with the id of the external referrer, which is the only part of the answer an operator can act on.
Follow-up
- The graph is read in one query and the archive writes a minute later. What can change in between, and how do you make the write safe?
- The candidate set is 400,000 resources. Is that one transaction, and if not, what does a half-finished archive look like to a reader?
Diff a projection against the primary without per-row point reads
hard
The listing projection has drifted and some rows show a stale version. The primary holds 40,000,000 resource rows across 12,000 tenants while serving 1,200 writes and 14,000 reads per second. The obvious repair, reading each resource row and comparing its version against the projection, is correct and would eventually finish. Explain precisely why it is unacceptable here, then give a diff that finds the differing rows, state its complexity, and make it safe to run against a live primary. Replication lag is usually under 100 ms and is not bounded.
Approach
- Quantify the naive cost rather than calling it slow: 40,000,000 point reads at even 0.5 ms each is over five hours serialised, and the only lever is concurrency, which is exactly what you cannot spend. The primary's pool is sized for the write path, and 40,000,000 random reads evict the buffer cache that sustains the 85 percent cache hit rate, so the audit degrades the system it is auditing.
- Replace random access with one ordered pass per side. Both sides can be read in (tenant_id, resource_id) order, which is a sequential scan on each and a merge join in O(n) time and O(1) memory. For a dense diff that is the whole answer, and it reads the primary once instead of 40,000,000 times.
- For the expected sparse case, compare range hashes instead of rows: partition the key space, compute per range an order-independent aggregate over hash(resource_id, version), compare aggregates, and descend only into ranges that differ. With d differing rows and branching factor B, at most d ranges mismatch per level, so the drill-down examines O(d log_B(n/d)) ranges and reads full rows only in mismatching leaves.
- Aggregate with a sum modulo 2^64 or a multiset hash, never XOR. XOR is order-independent but self-cancelling, so two rows wrong in the same way, or a row duplicated on one side, leave the range aggregate matching and the range is declared clean.
Follow-up
- The diff reports 900 stale rows. How do you decide between patching those rows and rebuilding the projection from resource_revision?
- Same job, but the projection lives in a search index that cannot be scanned in key order. What changes?
How do you write and optimize queries in BigQuery for large-scale data exploration?
medium
How do you write and optimize queries in BigQuery for large-scale data exploration?
Approach
- Start from the cost model: BigQuery is columnar and on-demand pricing bills bytes read from the columns you reference.
SELECT *reads every column andLIMITdoes not cut bytes scanned on an unclustered table, so name only needed columns and dry-run to see the estimate first. - Filter the partitioning column with constants so BigQuery prunes: the DATE, TIMESTAMP, DATETIME or integer-range column itself, or
_PARTITIONTIME/_PARTITIONDATEon an ingestion-time table, where filtering your own timestamp column does not prune. Setrequire_partition_filteron large tables. - Cluster on the columns you filter or join by most (up to four, order matters) so storage blocks can be skipped. For exploration, sample with
TABLESAMPLE SYSTEM (1 PERCENT)or a small extract, and useAPPROX_COUNT_DISTINCTwhen an exact distinct count isn't needed. - Shape the query to cut shuffle: filter and pre-aggregate in CTEs before joining, check each side's grain to avoid fan-out that inflates sums, replace self-joins with window functions, and use
QUALIFYfor latest row per user, with a unique tiebreaker inORDER BYso ties are deterministic. - Read the execution details: stage timings, slot time, bytes shuffled and the wait-versus-compute ratio reveal a skewed join key or a stage that spills. Query
INFORMATION_SCHEMA.JOBSordered bytotal_bytes_billed(what on-demand pricing charges) ortotal_slot_msto find your costliest queries. - Persist repeated work: write intermediate results to a partitioned scratch table or use materialized views for common aggregates. The 24-hour result cache only helps when the query text and tables are unchanged and the query has no non-deterministic functions such as
CURRENT_TIMESTAMP().
Follow-up
- Why did the same query cost nothing on the second run? It was likely served from the result cache, which is free; confirm with
cache_hitin the job metadata. - How do you count distinct users over any date range without rescanning raw events? Store daily HyperLogLog++ sketches with
HLL_COUNT.INITand combine them per range withHLL_COUNT.MERGE. - How do you keep ad-hoc exploration costs bounded? Set maximum bytes billed per query, add custom daily quotas per user or project, and give analysts views limited to recent partitions.
Denormalise tenant onto revisions and backfill it live
hard
resource_revision (revision_id, resource_id, version, actor_user_id, change_kind, patch, request_id, created_at) has 400M rows and no tenant column; tenant_id lives only on resource. Two reads need it: a tenant-scoped audit feed ordered by created_at DESC, and an offboarding purge. Both join back to resource today. Justify adding tenant_id to resource_revision against those two reads, name the anomaly the copy introduces and the constraint that prevents it, then give the ordered migration for a live table taking 1.2k writes/second — the lock each step takes, how the backfill is batched, and where each step stops being reversible. PostgreSQL 16.
Approach
- Justify from the access path rather than from taste. Without the column, the audit feed either scans resource_revision by created_at and discards other tenants' rows, or resolves the tenant's resource_ids first and probes with them — both proportional to the tenant's whole history rather than to one page. With (tenant_id, created_at DESC, revision_id DESC) it is a seek that stops at 50 rows, and the purge becomes a ranged delete instead of a join.
- Name the cost exactly: a second copy of a fact can disagree with the first. Make the disagreement unwritable rather than documented — add UNIQUE (resource_id, tenant_id) on resource so it can serve as a foreign-key target, then FOREIGN KEY (resource_id, tenant_id) REFERENCES resource (resource_id, tenant_id) on the revision table. A revision can then only ever carry its parent's tenant.
- Step one, expand: ALTER TABLE resource_revision ADD COLUMN tenant_id BIGINT NULL, with no default, so it is a catalogue change and no rewrite. It still needs ACCESS EXCLUSIVE for an instant, and that instant queues behind the longest open transaction on the table while every later query queues behind it — set lock_timeout to 2s and retry rather than wait.
- Step two, dual-write: deploy the writer that populates tenant_id on every new revision while reads still use the join. Reversible by redeploying the previous build, because nothing reads the column yet.
Follow-up
- The backfill is half finished and a rollback is required. What state is the table in, and what does the previous build do with a half-populated column?
- How do you verify the backfill actually finished, given rows are still being inserted while it runs?
Stop tag and share joins from fanning out a page
medium
resource_tag is (resource_id, tag_id) with PK (resource_id, tag_id); resource_share is (resource_id, shared_with_user_id, permission). The tagged-and-shared listing inner-joins resource to both, filters tenant_id, tag_id = ANY($2) and shared_with_user_id = $3, orders by updated_at DESC and takes 50. Pages come back with fewer than 50 distinct resources and the total in the header is far too high. Explain the row multiplication, rewrite both the page query and the count query so each is correct, and name the index each one needs. PostgreSQL 16.
Approach
- Do the arithmetic against the predicates that are actually there. An inner join emits one row per matching child row, and both joins are filtered: tag_id = ANY($2) admits only the requested tags, shared_with_user_id = $3 admits one user's share rows. So a resource holding three of the requested tags and shared with $3 once yields three rows, not one — the multiplier is its count of matching tags times its share rows for that single user, and that second factor is 1 unless the table admits duplicate (resource_id, shared_with_user_id) pairs. LIMIT 50 then limits rows rather than resources, and COUNT(*) counts pairs — the header is the product, not the population.
- Reject DISTINCT as the fix. It deduplicates after the product has been built, so the planner must materialise and sort the fanned-out set before the LIMIT can apply, and it leaves any SUM or AVG in the same select list wrong.
- Rewrite both filters as semi-joins, keeping resource as the only row source: AND EXISTS (SELECT 1 FROM resource_tag rt WHERE rt.resource_id = r.resource_id AND rt.tag_id = ANY($2)) and the same shape against resource_share. A semi-join stops at the first match per resource and preserves the driving index order, so ORDER BY updated_at DESC, resource_id DESC LIMIT 50 still stops after 50 rows.
- Count with the same predicates and no join at all: SELECT count(*) FROM resource r WHERE r.tenant_id = $1 AND r.status = 'active' AND EXISTS (...) AND EXISTS (...). Nothing multiplies a resource, so the number is the population.
Follow-up
- The filter changes from 'any of these tags' to 'all of these tags'. Rewrite it and state what it costs relative to the ANY form.
- A resource can be shared with the same user twice under different permissions. Does your count change, and should it?
These questions test your proficiency in your primary technology stack, whether that is mobile, web, backend,
medium
These questions test your proficiency in your primary technology stack, whether that is mobile, web, backend, or infrastructure.
Approach
- Name the one stack you have shipped the most production code in and commit to it instead of listing five. Proficiency shows in how far down one stack you can explain behavior, not in how many stacks you have touched.
- Know your stack's runtime model cold. Mobile: app lifecycle states and why UI work stays on the main thread. Web: the render pipeline (style, layout, paint, composite) and hydration. Backend: a request's path through the concurrency model to the DB pool. Infra: how a commit reaches production.
- Prepare one under-the-hood mechanism per layer, e.g., how your UI framework decides what to re-render (React reconciliation, SwiftUI view identity), how memory is reclaimed (ARC and retain cycles in Swift, tracing GC in Go, the JVM or JavaScript), and what happens when the connection pool runs dry.
- Back every claim with a production story: a bug or slowdown in that stack, the tool that found it (Xcode Instruments, the Chrome DevTools Performance panel,
pprof,EXPLAIN ANALYZE), the fix, and the metric that changed afterward. - Show judgment about the stack's limits: when you would step off its defaults (raw SQL instead of the ORM for a hot query, server rendering instead of a client-only SPA) and one known weakness of your tools that you have worked around.
- Know how your stack is tested and debugged: its test tools (XCTest or Swift Testing, Jest or Vitest, Go's
testing, pytest), how you reproduce a production-only bug locally, and which logs, traces or crash reports you check first.
Follow-up
- What changed in the latest major version of your main framework? Name one concrete change (e.g., React Server Components, Swift 6 strict concurrency) and the migration cost you weighed before adopting it.
- How would you onboard a new engineer onto your stack in a week? Name the three concepts that cause the most bugs for newcomers and the tooling that catches them early.
- What would you change about your stack if starting over? Give one real pain point with its measured cost rather than a trend-driven rewrite.
How would you approach building a responsive web feature using React and Next.js while ensuring performance an
medium
How would you approach building a responsive web feature using React and Next.js while ensuring performance and accessibility?
Approach
- Choose a rendering strategy per route: static generation or ISR for content identical for everyone, server rendering for per-request data, client fetching only for user-specific or interactive parts. App Router components are Server Components by default, so push
"use client"down to the leaves. - Build the layout mobile-first with fluid CSS Grid/Flexbox,
min-widthmedia queries or container queries for component-level breakpoints, and relative units. Size touch targets generously (WCAG 2.2 AA sets a 24×24 CSS px minimum; 44×44 is the safer goal) and test on real device widths. - Budget against Core Web Vitals at the 75th percentile: LCP ≤ 2.5 s, INP ≤ 200 ms, CLS ≤ 0.1. Use
next/imagewithsizesand explicit dimensions, preload the LCP image, usenext/fontto avoid font-swap shift, and lazy-load heavy client components withnext/dynamic. - Keep the client bundle and main thread light: inspect it with
next experimental-analyze(Turbopack, Next.js 16.1+) or@next/bundle-analyzer(needsnext build --webpack), keep large libraries on the server, virtualize long lists, and memoize only where the React Profiler shows wasted renders. - Start accessibility with semantic HTML: real
<button>,<a>,<label>, ordered headings and landmarks. Add ARIA only where no native element fits; adivwithrole="button"still needs keyboard handling and focus, and incorrect ARIA is worse than none. - Verify keyboard order, visible focus, focus in and out of modals, contrast (4.5:1 body text; 3:1 large text and UI component boundaries) and
prefers-reduced-motion. Automate witheslint-plugin-jsx-a11yand axe in Playwright, then test with VoiceOver or NVDA; tools catch only some issues.
Follow-up
- How do you avoid hydration mismatches? Match the server's first render: move
Date.now(),windowand random values intouseEffector a Client Component'snext/dynamicimport withssr: false;"use client"alone still server-renders. - How would you measure performance for real users rather than in Lighthouse? Collect field Web Vitals with
useReportWebVitalsor theweb-vitalslibrary and track p75 per route and device class. - When would you pick ISR over SSR? When content changes on a schedule or on publish and is the same for all viewers; revalidate on a timer or on demand with
revalidatePath/revalidateTag.
Can you explain how you design and structure microservices or API endpoints using Python or Golang?
medium
Can you explain how you design and structure microservices or API endpoints using Python or Golang?
Approach
- Draw service boundaries around business capabilities that own their data (accounts, content, notifications), not around technical layers. A database shared across services is a monolith with network calls; with a small team, start as a modular monolith and split when deploy or scaling needs diverge.
- Design endpoints resource-first: nouns plus HTTP verbs (
GET /users/{id}/devices,POST /devices), precise status codes (201, 400, 404, 409, 422, 429), one error body shape, cursor pagination for large lists, and explicit versioning. Publish the contract as OpenAPI and generate clients from it. - Make writes safe to retry:
PUTandDELETEare idempotent by HTTP semantics if implemented that way.POSTis not, so accept anIdempotency-Keyheader, store the key with its result atomically, and return the stored result on a retry so a flaky network never creates duplicates. - Layer every service the same way: thin handlers (parse, validate, map errors), a service layer with business logic, a repository for data access. In Python, FastAPI with Pydantic gives validation and OpenAPI for free; in Go,
net/http(1.22+ routing) or chi, passingcontext.Contextfor deadlines. - Pick communication per interaction: synchronous HTTP or gRPC with timeouts when the caller needs an answer now, async events (Kafka, Pub/Sub, SQS) when others only react. A transactional outbox saves the event in the write's transaction; a relay publishes it at least once, so consumers dedupe by event ID.
- Build in operability from day one: separate liveness and readiness endpoints, structured JSON logs carrying a request ID, OpenTelemetry traces propagated between services, RED metrics per endpoint, and graceful shutdown that drains in-flight requests on
SIGTERM.
Follow-up
- How do you evolve an API without breaking mobile clients that rarely update? Make only additive changes within a version, have clients ignore unknown fields, and keep old versions alive until their traffic drops.
- When would you choose gRPC over REST? For internal service-to-service calls that benefit from typed contracts, streaming and low overhead; REST with JSON stays the better fit for public and browser clients.
- How do you handle an operation that spans three services? Use a saga with compensating actions instead of a distributed transaction, and make each step idempotent so it can be retried.
What strategies do you use for automated testing and maintaining code quality across a distributed codebase?
medium
What strategies do you use for automated testing and maintaining code quality across a distributed codebase?
Approach
- Interpret "distributed codebase" as many services or repos owned by different teams, where breakage happens at the seams. Invest per layer: fast unit tests for logic, integration tests against real dependencies in containers (e.g., Testcontainers), and a few end-to-end tests for key journeys.
- Test service boundaries with contracts: consumers publish expectations (e.g., Pact) that providers verify in CI, or providers check their OpenAPI or protobuf schema for breaking changes (
buf breaking, oasdiff). This catches cross-team breaks without depending on a shared staging environment. - Gate merges with the same checks everywhere: formatter, linter and static analysis (
go vet, staticcheck, ESLint), type checker (mypy or pyright, TypeScriptstrict), unit tests, and dependency and security scans. Share configs via a template repo or common package so repos don't drift apart. - Treat flaky tests as bugs: track flake rate per test, quarantine and assign an owner with a deadline, and don't paper over them with blanket reruns. A suite nobody trusts gets ignored, which costs more than a missing test.
- Use coverage as a signal, not a target: require tests for changed lines and look at diff or mutation coverage on critical modules, because a global 90% target breeds assertion-free tests. CODEOWNERS and small pull requests keep code review meaningful.
- Pair tests with safe releases: trunk-based development, feature flags, canary or staged rollouts gated on error-rate and latency SLOs, and automated rollback. Some defects only appear under production traffic, so the release process is part of code quality.
Follow-up
- How do you keep CI fast as the codebase grows? Run only tests affected by a change using build-graph tools (Bazel, Nx, Turborepo), cache results, and shard slow suites across runners.
- What belongs in an end-to-end test versus a contract test? E2E covers a few critical journeys across the deployed stack; contracts cover every field and status code each consumer relies on.
- How do you get a team with almost no tests started? Add characterization tests around code you are about to change and require tests for new code, rather than pausing features for a coverage push.
How would you design a system architecture to handle sudden, massive spikes in global traffic for a daily digi
hard
How would you design a system architecture to handle sudden, massive spikes in global traffic for a daily digital devotional?
Approach
- State your assumptions and confirm them: a day's devotional is likely the same for every reader of a language, reads dwarf writes, and spikes cluster at local mornings and right after any push notification. Assume, e.g., tens of millions of readers and a 20–50× jump within minutes.
- Make the content static: publish each day's devotional per language in advance as JSON in object storage (e.g., S3 or GCS) behind a CDN, with a long edge TTL (
s-maxage) and a short clientmax-age. Clients fetch/devotionals/{lang}/{yyyy-mm-dd}.jsonby local date, so most requests hit the edge. - Split any personalized data (e.g., completion marks or streaks, if the product keeps them) into small API calls that load after the content and can fail without blocking reading. Queue those writes, idempotent on (user, date), so a spike becomes a backlog instead of a database overload.
- Shape the spike instead of only absorbing it: if the app sends push notifications, batch them per time zone with jitter, and have clients prefetch tomorrow's content so the morning open often needs no network. Pre-scale the API on a schedule; reactive autoscaling lags a sudden burst.
- Run the dynamic API in multiple regions behind a global load balancer: stateless app servers, a cache such as Redis in front of the database, and read replicas. Rate-limit per client and put circuit breakers on non-critical features so extras degrade before reading does.
- Guard the day rollover: publish and warm the next day's objects (at least at the origin shield) before midnight in the earliest time zone, and enable request collapsing so concurrent misses on a new dated URL become one origin fetch.
stale-while-revalidateonly helps objects that expire mid-day.
Follow-up
- How do you fix a typo after the day's content is live? Publish the corrected file and purge that one URL at the CDN; the short client
max-agelets readers pick it up soon, and apps should revalidate prefetched days with anETag. - What if the database fails during the spike? Reading continues from the CDN; queue any per-user writes for replay and show saved state as possibly stale instead of an error screen.
- How would you load-test this? Replay a spike-shaped ramp from baseline to peak in about two minutes, including CDN misses hitting origin, and check that pre-scaling finishes before the ramp.
How do you ensure high availability and fault tolerance when integrating third-party cloud services?
medium
How do you ensure high availability and fault tolerance when integrating third-party cloud services?
Approach
- Classify each third-party service as critical-path (auth, payments, storage) or deferrable (email, analytics, push). Availability of serial dependencies multiplies (three 99.9% services in a chain give about 99.7%), so every critical-path vendor caps your own SLO.
- Put connect and read timeouts on every outbound call, set from the vendor's observed p99 plus margin. Retry only transient failures (timeouts, 5xx, 429 honoring
Retry-After) with exponential backoff, jitter and a capped retry budget, and send idempotency keys so retried writes are not duplicated. - Wrap each vendor in a circuit breaker so that past a failure threshold you fail fast instead of stacking up waiting requests, and give it its own connection pool or concurrency limit (a bulkhead) so one slow provider cannot starve unrelated requests.
- Decide each vendor's fallback before the outage: cached last-known-good data, a degraded feature (hide the widget), or accept the request and queue the call for later. Deferrable calls go through a durable queue with a dead-letter queue and a replay tool.
- Hide each vendor behind an internal adapter so retries, metrics and error mapping live in one place and an SDK or API change touches one module. For managed cloud services, deploy multi-zone by default and multi-region only where the business need pays for it.
- Observe the vendor from your side: per-dependency latency, error rate and breaker state, synthetic checks, and alerts on quota and rate-limit headroom. Rehearse failures with fault injection in staging (block the host, add latency) so fallbacks are not first exercised in production.
Follow-up
- What if the vendor processed the request but your call timed out? Treat the outcome as unknown; retry with the same idempotency key or reconcile through the vendor's status API before acting again.
- How do you choose circuit-breaker thresholds? Base them on error rate over a rolling window with a minimum request count, and use a half-open state that lets a few trial calls through.
- When is a second provider worth it? When measured vendor downtime costs more than building and continuously testing two integrations; otherwise invest in graceful degradation.
These questions evaluate how you design scalable systems and troubleshoot complex technical challenges.
medium
These questions evaluate how you design scalable systems and troubleshoot complex technical challenges.
Approach
- The prompt has two halves, so prepare a structure for each. Design: requirements, estimate, API and data model, then scale the parts that break. Troubleshooting: stabilize, find the bottleneck, confirm the cause, then change the design so the problem does not recur.
- Open a design answer by clarifying what the system must do and at what scale: core use cases, users, read/write ratio, peak requests per second, latency and consistency targets. Estimate aloud, e.g., 10M daily users × 20 requests ÷ 86,400 s ≈ 2,300 rps average, 5–10× that at peak.
- Sketch a few API endpoints and the data model as entities plus their access patterns, because access patterns pick the store: relational for transactions and joins, key-value for high-volume lookups by key. Draw the simplest version that handles today's load before adding parts.
- Scale only what your estimate says will break: a stateless app tier behind a load balancer, a cache for hot reads, read replicas, partitioning on a key that spreads load evenly, async queues for slow work. Name each tradeoff aloud, such as cache staleness, replica lag or cross-shard queries.
- When troubleshooting, scope first: which endpoints, regions or accounts, and does latency track request rate or data volume? Then find the saturated resource with RED metrics per service and USE per resource (CPU, memory, DB connections, worker pools, queue depth); traces show which hop slowed.
- Mitigate before root-causing (scale out, shed traffic, flag off expensive features) and watch for retry storms. Test one hypothesis at a time with
EXPLAIN ANALYZE, a CPU profile or a staging load test, then close with the design change and the alert or load test that would have caught it earlier.
Follow-up
- How would your design change at 10× the load? Re-run the estimate, find the first component to saturate (often primary-database writes), and partition or queue there instead of scaling everything evenly.
- How do you tell a capacity problem from a code regression? Plot latency against request rate over several days; if the curve shifted at a deploy while load stayed the same, it is a regression.
- What if only p99 latency is bad? Look for a subset such as large accounts, cold caches, GC pauses or one slow shard, and segment traces by attribute instead of averaging them.
Walk through your debugging process when a critical service fails or an application experiences memory leaks i
medium
Walk through your debugging process when a critical service fails or an application experiences memory leaks in production.
Approach
- Stabilize first: declare an incident, name one incident lead, and check what changed (last deploy, config or flag change, dependency status, traffic). If a deploy lines up with the failure, roll back before investigating; restoring service beats a perfect diagnosis.
- Scope from the outside in: error rate and latency by endpoint and instance, health-check status, crash loops, and dependency errors in logs and traces. All instances failing suggests a shared dependency or bad config; some failing suggests a bad host, zone or shard, which halves the search.
- For a suspected leak, read the memory graph's shape: a sawtooth returning to baseline after GC is normal, a rise that plateaus is usually a cache warming or heap sizing, and a baseline that climbs until the process is killed (Kubernetes
OOMKilled, exit code 137) is a leak. - Pull one leaking instance out of rotation and capture heap data before restarting it (
jcmdheap dump on the JVM, Gopprofheap profile, Node heap snapshot,memray attachfor Python), then rolling-restart the rest. Enable these hooks in production in advance; some can't start mid-incident. - Diff two snapshots taken minutes apart to see which object types or allocation sites keep growing. Usual causes: unbounded maps or caches keyed per user or request, listeners never removed, goroutines blocked forever, retain cycles in closures, and unclosed connections or file handles.
- Close the loop: reproduce under a soak test, fix, keep the soak test as a regression check, and alert on memory growth rate rather than only absolute usage. Write a blameless postmortem with a timeline and action items that each have an owner.
Follow-up
- What if a restart fixes it for a day, then it returns? That pattern is unbounded growth; use scheduled restarts only as a stopgap and capture heap diffs at intervals to find the growing type.
- How do you debug a crash you cannot reproduce locally? Gather symbolicated stack traces from crash reports, correlate by device, OS and app version, and add targeted logging behind a flag.
- How would you find a goroutine leak in Go? Track
runtime.NumGoroutine()over time and inspect/debug/pprof/goroutine?debug=2for many goroutines stuck on the same channel operation or lock.
Built from the rounds and topics Life.Church candidates report.
Small steps. Visible outcomes.0 / 7 completed
ONE WEEK · YOUR PACE
Prepare, practise & reflect
One practical outcome each day. Spend longer where you need it.
0 / 7 done01Map the Life.Church loop
- Write out the reported sequence: Recruiter Screen, Technical Evaluation, Comprehensive Loop.
- For each round, write one sentence on what it is judging, from the description above, and mark the one you are least ready for.
Deliverable: A one-page map of the 3 reported rounds, with the weakest marked.
02Work Take-home coding challenge
- Spend the session on Take-home coding challenge, which Life.Church candidates report being tested on.
- Write one worked example in Take-home coding challenge and time yourself on it.
Deliverable: One timed worked example in Take-home coding challenge.
03Work JavaScript
- Spend the session on JavaScript, which Life.Church candidates report being tested on.
- Write one worked example in JavaScript and time yourself on it.
Deliverable: One timed worked example in JavaScript.
04Work SQL
- Spend the session on SQL, which Life.Church candidates report being tested on.
- Write one worked example in SQL and time yourself on it.
Deliverable: One timed worked example in SQL.
05Answer out loud: Technical & Domain Knowledge
- Answer aloud, timed: These questions test your proficiency in your primary technology stack, whether that is mobile, web, backend, or infrastructure.
- Answer aloud, timed: What experience do you have with asynchronous programming in Swift, and how do you handle concurrency in mobile applications?
Deliverable: Spoken answers to 2 reported Technical & Domain Knowledge question(s), under time.
06Answer out loud: System Architecture & Problem Solving
- Answer aloud, timed: These questions evaluate how you design scalable systems and troubleshoot complex technical challenges.
- Answer aloud, timed: How would you design a system architecture to handle sudden, massive spikes in global traffic for a daily digital devotional?
Deliverable: Spoken answers to 2 reported System Architecture & Problem Solving question(s), under time.
07Answer out loud: Behavioral & Self-Awareness
- Answer aloud, timed: These questions gauge your emotional intelligence, ability to receive feedback, and interpersonal dynamics.
- Answer aloud, timed: Can you share an area of weakness or professional growth, and how you actively work to improve it?
Deliverable: Spoken answers to 2 reported Behavioral & Self-Awareness question(s), under time.
Expand any day for tasks and deliverables. Your progress is saved on this device.
Behavioural rounds judge the decision you made and what it cost.
Describe a time when you had to refactor a legacy system without disrupting active user experiences.
medium
Describe a time when you had to refactor a legacy system without disrupting active user experiences.
Approach
- Pick a story where the system was live and the change was substantial (a service, a schema, a core module), not a cleanup nobody noticed, so the answer shows how you changed something people relied on without an outage.
- Open with why the refactor was worth doing in business terms, e.g., "every change to the notification service took a week and caused an incident a month," and what constrained you, such as no maintenance window or no existing tests.
- Show the safety net you built before changing anything: characterization tests pinning current behavior, new metrics on the old path to compare against, and a written rollback plan with the signal that would trigger it.
- Name the incremental mechanism: strangler-fig routing to a new component, branch by abstraction behind an interface, percentage rollouts behind flags, or shadow traffic diffing old and new output. For data, describe expand/contract: new schema, dual writes, backfill, switch reads, drop the old path.
- Quantify the outcome: user-visible incidents during the migration (ideally zero), latency or error-rate change, deploy frequency or lead time before and after, and how long the rollout took. Include one thing that went wrong midway and how the rollback plan handled it.
- Avoid a big-bang rewrite framed as a win, and don't blame the original authors; acknowledge the constraints they probably had. End with what you would do differently, such as cutting the migration into smaller slices.
Follow-up
- How did you get time approved for the refactor? Tie it to delivery speed or incident cost with numbers, and show it shipped in slices that each delivered value on their own.
- How did you know the new path behaved like the old one? Shadow-run or dual-read, diff mismatches after normalizing expected differences (timestamps, generated IDs, ordering), and cut over once no unexplained mismatches remained.
- What did you do about undocumented behavior users depended on? Preserve it in the new path first, document it, and schedule its removal separately with notice to affected users.
These questions gauge your emotional intelligence, ability to receive feedback, and interpersonal dynamics.
easy
These questions gauge your emotional intelligence, ability to receive feedback, and interpersonal dynamics.
Approach
- Prepare stories that show you reading your own and others' reactions, staying steady under friction and repairing a strained working relationship, where the point is how you changed rather than that you were right.
- Build a bank of four short stories you can adapt: feedback that stung, a conflict with a peer, a mistake you owned publicly, and a time you noticed a teammate struggling before they said anything. One story can serve several questions if you know which beat to lead with.
- In each story, name what you felt and what you did with it, e.g., "I was defensive in the moment, so I asked for a day before responding." Naming the emotion and the choice is the evidence of self-regulation; leaving it out makes the story sound scripted.
- Show perspective-taking: what the other person needed, what pressure they were under, and how you found out (you asked). A story where the other person is the villain signals low empathy even when the facts are on your side.
- Land on what changed in how you handle people, e.g., you now pause before replying to a tense message or check in privately when a teammate goes quiet, and how you know it stuck (that peer now raises concerns with you early).
Follow-up
- How do you notice a teammate is upset when they don't say so? Name the concrete signals you watch for, such as shorter replies or silence in reviews, and how you check in privately without assuming.
- When have you misread a situation with a colleague? Pick a real misjudgment, name the cue you missed, and describe how you check your assumptions earlier now.
- How do you adapt your communication style to different people? Give one example of changing format or directness for someone and what improved as a result.
Can you share an area of weakness or professional growth, and how you actively work to improve it?
medium
Can you share an area of weakness or professional growth, and how you actively work to improve it?
Approach
- Pick a real weakness that affects engineering work but is not disqualifying for the role; "I'm a perfectionist" or "I work too hard" reads as evasion.
- Name it precisely and show its cost: not "communication" but, e.g., "I stayed heads-down and raised blockers late, which once pushed a release by a week." A concrete consequence proves you understand why it matters.
- Describe the mechanism you use to improve, not an intention: a practice with a trigger, e.g., posting a risk note in standup whenever a task runs 50% over its estimate, or asking your manager to call it out in 1:1s.
- Give evidence of progress with a number or a changed outcome: fewer late escalations, a later review that noted the change, a presentation you now volunteer for. Say it is still a work in progress; claiming it is solved undercuts the answer.
- Keep it to about 90 seconds: one weakness, one mechanism, one result, without over-confessing or listing several weaknesses at once.
Follow-up
- What is another weakness? Have a second one ready from a different area (technical versus interpersonal) with the same shape: cost, mechanism, evidence.
- How would your current manager describe that weakness? Answer consistently with what a reference would say, ideally quoting feedback you actually received.
- How do you find your blind spots? Name specific sources: patterns in your code review comments, peer or 360 feedback, retrospectives, and asking directly after projects.
Tell me about a time when you received direct, challenging feedback from a team member or leader, and how you
medium
Tell me about a time when you received direct, challenging feedback from a team member or leader, and how you responded to it.
Approach
- Choose feedback that was genuinely challenging, at least partly valid, and that changed how you work; a story where you proved the critic wrong answers a different question.
- Quote the feedback as closely as you can and say who gave it, e.g., "My tech lead told me my code reviews read as dismissive and juniors had stopped asking me questions." Specific wording makes the story credible.
- Be honest about your first reaction in one sentence, then show the pivot: you asked for examples, checked with others, and separated the part you agreed with from the part you didn't. Claiming you felt nothing sounds rehearsed.
- Describe the specific change you made, e.g., asking a junior what they had tried before leaving review comments, and the evidence it worked: the same person's later feedback, or juniors bringing you questions again.
- Close the loop with the person who gave it: thank them, or check back a few weeks later to ask whether they see a difference, which shows you value hard feedback and makes them more willing to give it again.
Follow-up
- What if you disagreed with part of the feedback? Say which part, how you raised it respectfully with evidence, and that you still acted on the part that was valid.
- Would you deliver that feedback the same way to someone else? Say what you would keep from how it reached you and what you would change about the delivery.
- What feedback have you received more than once? Pick a recurring theme and show how your response changed from the first time to the most recent.
How do you handle disagreements on a technical approach when collaborating with cross-functional team members?
medium
How do you handle disagreements on a technical approach when collaborating with cross-functional team members?
Approach
- Pick a real disagreement with a product, design, QA or data partner where the stakes mattered, not a style argument, and where the working relationship survived it.
- Start by understanding their goal and constraints before defending your approach; restate their position until they agree you have it. Often the disagreement is about priorities (deadline versus maintainability, polish versus performance), not facts.
- Translate the technical tradeoff into their terms: user impact, time to ship, risk, and the cost of changing course later. Offer options with consequences, e.g., "ship the animation now and accept slower loads on older phones, or ship a lighter version and measure."
- Break ties with evidence: a quick prototype, a performance measurement, user data, or a time-boxed spike. Agree up front on the decision criteria and who makes the call, so the debate has an end.
- Show you can disagree and commit when the decision goes the other way, and how you revisited it with data afterward. Quantify the outcome (shipped on time, the metric that moved) and describe the working relationship afterward.
Follow-up
- What if the other person has more authority and won't budge? State the risk in writing, propose a measurable checkpoint, then commit fully and help the chosen approach succeed.
- When should a disagreement be escalated? When it blocks delivery or carries real user or security risk; escalate together, with a shared summary of both options.
- When were you wrong in a technical disagreement? Name the evidence that changed your mind and how quickly you said so.
These questions explore your personal journey, faith, and alignment with the core values and expectations of t
easy
These questions explore your personal journey, faith, and alignment with the core values and expectations of the organization.
Approach
- Cover the three threads the prompt names: your personal journey, your faith, and your fit with the organization's core values and expectations. They overlap, so decide in advance which story anchors each thread.
- Find how the organization describes its core values, pick the two or three you most identify with, and attach a real example from your life or work to each. Reciting values without examples sounds memorized.
- Prepare a one-minute version of your personal journey alongside the full telling, and note one or two moments from it that you can offer as evidence for each value you picked above.
- Be honest about where you stand: if a stated expectation is something you want to understand better, ask about it directly. Performing beliefs or commitments you don't hold sets up a mismatch for both sides.
- Prepare questions of your own that show you care how values are lived out day to day, e.g., how the team balances deadlines with its values or what helps new engineers thrive. Good questions also help you judge fit.
Follow-up
- Which of our values resonates most with you, and why? Pick one, give a concrete moment you lived it, and say how it would shape your work on the team.
- What would a colleague say about how your values show up at work? Offer one specific observation someone has actually made about you.
- Is there any expectation here you would find hard? Answer honestly, name how you would approach it, and ask a clarifying question if you are unsure what it involves.
Can you share your life story and how your faith journey has shaped your professional calling?
medium
Can you share your life story and how your faith journey has shaped your professional calling?
Approach
- Tell your story honestly and connect your faith to how you work; it does not need to be dramatic, and a quiet, steady journey told plainly is a complete answer.
- Structure it in three movements in about three minutes: where you came from, the turning points in your faith and career (and where they crossed), and why this role is the next step. Avoid a résumé walkthrough with faith appended at the end.
- Make the connection concrete by naming how your faith shapes daily work, e.g., how you treat users, honesty in estimates, how you own mistakes, or why you chose to point your skills at a mission. Behaviors convince more than labels.
- Include doubt, struggle or a season of change if it is true; how you grew through it is often the most compelling part. Share only what you are comfortable with; you set the depth.
- Finish on the present: what you are looking for in this role and how it fits your sense of calling. Rehearse aloud so it sounds natural rather than memorized and stays within time.
Follow-up
- Who has shaped your faith or career the most? Name one person and one specific thing they did or said that changed how you work.
- How has your sense of calling changed over time? Contrast an earlier view with your current one and name what prompted the shift.
- How do you sustain your faith during demanding seasons at work? Describe practices you actually keep, briefly and without preaching.
What does it mean to you to view your engineering work as a ministry rather than just a job?
medium
What does it mean to you to view your engineering work as a ministry rather than just a job?
Approach
- Connect everyday engineering (bug fixes, code review, on-call) to the people it serves, and show how that changes what you actually do; an abstract answer ("I want to make an impact") gives no evidence of either.
- Give your own definition in a sentence, e.g., "a job is done when the ticket closes; ministry means caring whether the person on the other end was actually helped," then show what that looks like in practice.
- Point to concrete behaviors: treating accessibility and performance on older devices as care for real people, guarding users' privacy and data, writing the test or doc that helps the next engineer, and fixing the unglamorous bug because someone is hitting it.
- Include how you treat teammates (patience in code review, mentoring, honesty about mistakes), since how the work gets done is part of the answer, not only what ships.
- Show healthy balance: a mission does not justify burnout or cutting quality to ship faster, so say how you hold that line. Anchor it with one short story where this sense of purpose changed a technical decision you made.
Follow-up
- How does that mindset show up on a routine day of maintenance work? Pick one unglamorous task, say who it helped, and explain why you did it carefully.
- How do you stay motivated when a project you cared about is cancelled? Separate the outcome from the purpose and name what you carried forward into the next work.
- What would you do if urgency pushed the team to cut corners? Name the risk, propose a smaller scope that keeps quality, and escalate if users would be affected.
How do you actively support and contribute to a team culture that emphasizes high feedback and vulnerability?
medium
How do you actively support and contribute to a team culture that emphasizes high feedback and vulnerability?
Approach
- Answer with practices you have personally used to build psychological safety, not only your willingness to hear feedback; "I love feedback" with no example gives no evidence.
- Show that you model vulnerability first: asking for specific feedback ("What is one thing I could have done better in that design review?"), admitting mistakes openly in postmortems or standups, and saying "I don't know" in front of the team.
- Explain how you give feedback so it is safe to receive: specific and timely, framed as situation, behavior and impact, praise in public and criticism in private, and asking for their view before prescribing. High feedback without care turns into harshness.
- Mention structures you have used or proposed that make feedback routine rather than personal, e.g., blameless postmortems, retros with a rotating facilitator, review norms that separate blocking comments from nits, and regular 1:1s.
- Include one example of it working and one where it was hard, e.g., someone who shut down after critical feedback and how you repaired it. Note how you make room for quieter or junior teammates, who take the biggest risk by speaking up.
Follow-up
- What do you do when someone's vulnerability is met with judgment in a meeting? Address it promptly, restate the team norm, and follow up privately with both people.
- How do you get honest feedback from someone junior to you? Ask a narrow question, make it low-stakes (written or 1:1), and visibly act on what they tell you.
- How can you tell whether a team feels safe? Watch who speaks in meetings, whether bad news surfaces early, and whether people ask for help or hide mistakes.
- 01
Describe a time when you had to refactor a legacy system without disrupting active user experiences.
- 02
These questions gauge your emotional intelligence, ability to receive feedback, and interpersonal dynamics.
- 03
Can you share an area of weakness or professional growth, and how you actively work to improve it?
- 04
Tell me about a time when you received direct, challenging feedback from a team member or leader, and how you responded to it.
How difficult is the interview process, and how much preparation time should I expect?
The interview process is widely regarded as rigorous, lengthy, and thorough, often spanning several weeks or months. Expect to invest significant time not just in technical prep, but in culture and personality evaluations. Give yourself at least two to four weeks to review your core technical stack and reflect deeply on your personal story and ministry calling.
Life.Church Software Engineer candidate reports ↗What differentiates successful candidates from those who are not selected?
Successful candidates combine high technical competence with profound self-awareness and authentic alignment with the church's mission. Because the culture places a heavy emphasis on high feedback and vulnerability, candidates who can openly discuss their weaknesses and accept constructive criticism tend to stand out.
Life.Church Software Engineer candidate reports ↗Is church membership an absolute requirement for employment?
Yes, candidates must be active members or willing to become members of Life.Church and align fully with its doctrinal statements and practices. Staff members are classified as ministers, and this requirement is applied strictly throughout the hiring process.
Life.Church Software Engineer candidate reports ↗What should I expect during the final interview stages?
The final stages often include an intensive multi-day on-site or interview event where you and your spouse participate in campus tours, panel interviews, and group discussions. This phase is designed as a mutual discernment period to ensure long-term cultural and relational fit.
Life.Church Software Engineer candidate reports ↗Are remote work options available for Software Engineers?
While many engineering roles are anchored around the Edmond, Oklahoma hub, specific position requirements regarding remote or hybrid flexibility can vary. Check individual job postings or discuss location expectations during your initial recruiter screen.
Life.Church Software Engineer candidate reports ↗How hard is the Life.Church interview?
Candidates most commonly rate Life.Church interviews as hard, based on 217 reported interviews. About 73% of candidates who interview go on to receive an offer.
Life.Church Software Engineer candidate reports ↗What topics does Life.Church test in interviews?
Life.Church interviews most often cover Behavioral Interviewing, Stakeholder Management, Problem Solving, SQL, and Systematic Problem Solving. The exact emphasis depends on the specific role you apply for.
Life.Church Software Engineer candidate reports ↗Is Life.Church a good place to work?
Employees rate Life.Church 4.7 out of 5 overall, based on aggregated workplace reviews spanning career growth, work-life balance, compensation, culture, and management.
Life.Church Software Engineer candidate reports ↗Where is Life.Church headquartered?
Life.Church is headquartered in Edmond, US.
Life.Church Software Engineer candidate reports ↗Sources & methodology 3 sources ↗
Official role evidence, timestamped platform data and clearly labeled preparation advice.
- 01Life.Church Software Engineer candidate reports ↗
Company-reported rounds, questions and FAQ.
candidate · Accessed 2026-09-22 - 02PracHub Software Engineer practice ↗
PracHub practice material, not company-reported.
platform · Accessed 2026-09-22 - 03PracHub preparation framework ↗
PracHub preparation guidance.
platform · Accessed 2026-09-22
Explore related engineering environments and compare the preparation focus.
SpotOn: Corporate Software Engineer Interview Guide
What SpotOn: Corporate asks Software Engineer candidates, from reported rounds and questions.
Teramind Software Engineer Interview Guide
What Teramind asks Software Engineer candidates, from reported rounds and questions.
Xometry Software Engineer Interview Guide
What Xometry asks Software Engineer candidates, from reported rounds and questions.
Vibotek Software Engineer Interview Guide
What Vibotek asks Software Engineer candidates, from reported rounds and questions.