First Resonance Software Engineer Interview Guide

The 60-second brief

As a Software Engineer at First Resonance, you are at the forefront of modernizing hardware manufacturing. The company develops the ION platform, an operating system designed specifically for the factory floor, enabling companies to manage their supply chain, production, and quality processes with unprecedented visibility. Your work directly impacts how complex, high-stakes hardware—such as rockets, satellites, and medical devices—is built and delivered to the world. This role is both technically rigorous and strategically significant. You will not just be writing code; you will be architecting solutions that solve real-world physical engineering challenges. You will work within a fast-paced, mission-driven environment where your contributions directly influence the stability and scalability of the ION platform.

This guide is scoped to a Software Engineer candidate at First Resonance.

Focus areas

• React
• SQL
• Python

The First Resonance interview process

First Resonance candidates report 3 rounds over 3-5 weeks. The stages below are what candidates describe, not a published process.

Initial Screening

The process begins with an initial screening to assess candidate fit.

What to demonstrate

• The process begins with an initial screening to assess candidate fit
• Depth in React

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 Assessments

Candidates undergo more granular technical assessments to evaluate their skills.

What to demonstrate

• Candidates undergo more granular technical assessments to evaluate their skills
• Depth in React

How to prepare

• Answer aloud and timed: What are the trade-offs between different database architectures for tracking hardware parts?
• Answer aloud and timed: How do you handle data integrity when managing thousands of individual component records?

Onsite Presentation

Candidates present their ability to communicate complex ideas in a final onsite presentation.

What to demonstrate

• Candidates present their ability to communicate complex ideas in a final onsite presentation
• Depth in React

How to prepare

• Answer aloud and timed: Given a set of requirements, how would you structure a component in React to ensure it remains performant?
• Answer aloud and timed: Can you explain your process for debugging a multi-layered application?

Where candidates lose points

Prioritize clarity in documentation

Even in code, comments and structure matter. The team values engineers who write code that others can easily maintain.

Be ready to talk about the "why

Do not just explain what you did; explain the constraints you faced and why your specific solution was the best trade-off.

Research the ION platform

Understanding what the product actually does for customers will give you a significant advantage when discussing architectural choices.

Prepare for ambiguity

If you are given a problem statement that seems incomplete, ask questions to define the scope before you start building.

Questions & practice

Given a set of requirements, how would you structure a component in React to ensure it remains performant?

Medium · Practical Coding and Development

Approach

1. Restate the input: its shape, its size, and what is guaranteed about it.
2. Name the brute-force solution and its complexity before improving on it.
3. Choose the data structure from the access pattern, not from familiarity.
4. State the target complexity and say which constraint rules the naive version out.

Follow-up

• How does this change if the input no longer fits in memory?
• What is the worst case, and how likely is it on real data?

How do you approach writing tests for critical system components to ensure reliability?

Medium · Practical Coding and Development

Approach

1. Restate the input: its shape, its size, and what is guaranteed about it.
2. Name the brute-force solution and its complexity before improving on it.
3. Choose the data structure from the access pattern, not from familiarity.
4. State the target complexity and say which constraint rules the naive version out.

Follow-up

• How does this change if the input no longer fits in memory?
• What is the worst case, and how likely is it on real data?

Diff a projection against the primary without per-row point reads

Hard · reconciliation · range hashing · throttling

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

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

Can you walk me through an efficient way to normalize this database schema?

Medium · Technical and Database Fundamentals

Approach

1. Name the grain you start from and join outward from it.
2. Check whether any join is one-to-many before aggregating, or the sums inflate.
3. Say which index the query would use, and what makes it unusable.
4. Handle the rows that do not match: that is usually the actual question.

Follow-up

• How does the query change if that join becomes one-to-many?
• What happens to this when the table is ten times larger?

How would you optimize a query that retrieves large datasets from a complex production environment?

Medium · Technical and Database Fundamentals

Approach

1. Name the grain you start from and join outward from it.
2. Check whether any join is one-to-many before aggregating, or the sums inflate.
3. Say which index the query would use, and what makes it unusable.
4. Handle the rows that do not match: that is usually the actual question.

Follow-up

• How does the query change if that join becomes one-to-many?
• What happens to this when the table is ten times larger?

What are the trade-offs between different database architectures for tracking hardware parts?

Medium · Technical and Database Fundamentals

Approach

1. Fix the scope first: who calls this, how often, and what they do when it fails.
2. Name the read and write paths separately; they rarely have the same bottleneck.
3. Choose a partition key and say what query it makes expensive.
4. State the consistency you need, and where you are willing to be stale.

Follow-up

• What breaks first when traffic grows ten times?
• How does this behave when that dependency is down for an hour?

Keep one unresponsive destination from stalling all webhook delivery

Medium · fan-out · circuit breaker · timeouts

Egress delivery sends about 1.5k webhooks/second to 40k destinations, with a per-destination concurrency cap of 4 and a 10-second connect-plus-read timeout. One destination begins accepting connections and never responding; within the hour 150 destinations behave the same way. Design the delivery path so unrelated destinations are unaffected: the pool structure, the timeouts, the retry policy, the per-destination circuit, and what is recorded so a retry is not a second effect at the receiver. State how many in-flight slots the degraded destinations hold and why that number decides the design.

Approach

1. Start with the number, and with the law that produces it. In-flight work is arrival rate times time in service, so 1.5k/second against a healthy 200 ms response needs about 300 concurrent slots. Per destination the same product applies, ceilinged by the concurrency cap: at the fleet average of 0.0375 deliveries/second per destination (1.5k spread over 40k) a 10-second timeout is 0.375 slots. A destination that has queued retries behind it is a different regime - every slot refills the instant an attempt expires, so it sits pinned at its cap of 4 - and 150 of those hold 600 slots, more than a pool sized for healthy traffic, entirely consumed by endpoints that will never answer. The per-destination cap bounds one endpoint and says nothing about the aggregate, which is exactly why it alone is not containment.
2. Contain with bulkheads and an admission bound rather than a larger pool. Cap total in-flight per pool and shard destinations across pools by a hash of destination id, so a correlated group - one provider, one region - cannot exceed its pool's share. A delivery refused admission and re-queued with backoff is strictly better than one holding a slot on behalf of a receiver that is not listening.
3. Treat the timeout as two timeouts, and be exact about what shortening one buys. Connect and read are separate failures and both must be shorter than the budget of whatever is waiting. Occupancy is min(cap, arrival rate x timeout), so dropping the read ceiling from 10 seconds to 3 cuts a merely slow destination's occupancy proportionally, 0.375 slots to 0.11 at the fleet average. It does not cut the 4 slots held by one of the 150: a destination with a retry backlog arrives far above cap/timeout - 0.4/second at a 10-second timeout, 1.33/second at 3 - so it stays pinned at the cap either way and only the slot-seconds per attempt fall. What that does buy is detection rate: 3.3x more failures observed per second on the same four slots, which is how fast the circuit reaches its threshold. Pick the value from the measured latency distribution of successful deliveries, with their high percentile as the floor, not from a round number.
4. Add a circuit per destination, counting a timeout as a failure. Once open, fail fast without taking a slot - that is the whole point, converting 4 held slots into zero. Half-open on a schedule with exactly one probe and close only if the probe succeeds, so a permanently dead endpoint costs one request per interval instead of a growing retry queue.

Follow-up

• The destination is not dead - it answers in 9.5 seconds with a 200. Does a failure-rate circuit open? Should anything shed that traffic, and on what signal?
• One destination requires deliveries in order. What does a per-destination concurrency of 4 do to that guarantee, and what would you change to offer it?

Can you explain your process for debugging a multi-layered application?

Medium · Practical Coding and Development

Approach

1. Establish what changed and when, before forming any theory.
2. Pick a bisection that eliminates candidates whichever way it turns out.
3. Check the instrumentation before believing the symptom.
4. Separate the trigger from the cause; the deploy is rarely the bug.

Follow-up

• What would you look at first, and what would it rule out?
• How would you tell a cause from a coincidence here?

Suggested practice checklist

Built from the rounds and topics First Resonance candidates report.

Day 1 — Map the First Resonance loop

• Write out the reported sequence: Initial Screening, Technical Assessments, Onsite Presentation.
• 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.

Day 2 — Work React

• Spend the session on React, which First Resonance candidates report being tested on.
• Write one worked example in React and time yourself on it.

Deliverable: One timed worked example in React.

Day 3 — Work SQL

• Spend the session on SQL, which First Resonance candidates report being tested on.
• Write one worked example in SQL and time yourself on it.

Deliverable: One timed worked example in SQL.

Day 4 — Work Python

• Spend the session on Python, which First Resonance candidates report being tested on.
• Write one worked example in Python and time yourself on it.

Deliverable: One timed worked example in Python.

Day 5 — Answer out loud: Technical and Database Fundamentals

• Answer aloud, timed: Can you walk me through an efficient way to normalize this database schema?
• Answer aloud, timed: How would you optimize a query that retrieves large datasets from a complex production environment?

Deliverable: Spoken answers to 2 reported Technical and Database Fundamentals question(s), under time.

Day 6 — Answer out loud: Practical Coding and Development

• Answer aloud, timed: Given a set of requirements, how would you structure a component in React to ensure it remains performant?
• Answer aloud, timed: Can you explain your process for debugging a multi-layered application?

Deliverable: Spoken answers to 2 reported Practical Coding and Development question(s), under time.

Day 7 — Answer out loud: Behavioral and Experience-Based

• Answer aloud, timed: Can you describe a complex technical project you led and the specific challenges you overcame?
• Answer aloud, timed: How do you handle situations where project requirements are ambiguous or missing?

Deliverable: Spoken answers to 2 reported Behavioral and Experience-Based question(s), under time.

Behavioural preparation

Behavioural rounds judge the decision you made and what it cost.

How do you handle data integrity when managing thousands of individual component records?

Medium · Technical and Database Fundamentals

Approach

1. Pick a story where you made the decision, not one where you watched it.
2. State the situation in two sentences and spend the rest on the reasoning.
3. Give the blast radius: what could have broken, and what you measured.
4. Name the disagreement and how you resolved it with evidence.

Follow-up

• What would you do differently if you ran that again?
• How did you know your change caused the improvement?

Can you describe a complex technical project you led and the specific challenges you overcame?

Medium · Behavioral and Experience-Based

Approach

1. Pick a story where you made the decision, not one where you watched it.
2. State the situation in two sentences and spend the rest on the reasoning.
3. Give the blast radius: what could have broken, and what you measured.
4. Name the disagreement and how you resolved it with evidence.

Follow-up

• What would you do differently if you ran that again?
• How did you know your change caused the improvement?

How do you handle situations where project requirements are ambiguous or missing?

Medium · Behavioral and Experience-Based

Approach

1. Pick a story where you made the decision, not one where you watched it.
2. State the situation in two sentences and spend the rest on the reasoning.
3. Give the blast radius: what could have broken, and what you measured.
4. Name the disagreement and how you resolved it with evidence.

Follow-up

• What would you do differently if you ran that again?
• How did you know your change caused the improvement?

Describe a time you had to explain a highly technical concept to a non-technical stakeholder.

Medium · Behavioral and Experience-Based

Approach

1. Pick a story where you made the decision, not one where you watched it.
2. State the situation in two sentences and spend the rest on the reasoning.
3. Give the blast radius: what could have broken, and what you measured.
4. Name the disagreement and how you resolved it with evidence.

Follow-up

• What would you do differently if you ran that again?
• How did you know your change caused the improvement?

How do you approach feedback and collaboration within a fast-moving engineering team?

Medium · Behavioral and Experience-Based

Approach

1. Pick a story where you made the decision, not one where you watched it.
2. State the situation in two sentences and spend the rest on the reasoning.
3. Give the blast radius: what could have broken, and what you measured.
4. Name the disagreement and how you resolved it with evidence.

Follow-up

• What would you do differently if you ran that again?
• How did you know your change caused the improvement?