cswork / libraryOpen practice workspace

Interview guides · Hearth

Hearth Software Engineer Interview Guide

Hearth Software Engineer interview guide: reported rounds, questions and how candidates describe the process.

The 60-second brief

At Hearth, a Software Engineer plays a pivotal role in building the financial technology that empowers home improvement contractors to grow their businesses. By providing accessible financing options, streamlined invoicing, and digital payment solutions, Hearth bridges the gap between homeowners and contractors. As an engineer on this team, you are not just writing code; you are directly designing and scaling the financial pipes that process millions of dollars in transactions, directly impacting the livelihoods of thousands of small business owners. Because Hearth maintains a highly agile and lean engineering department, engineers here operate with an immense level of ownership. You will function as a high-agency generalist or deep specialist depending on your team, frequently crossing stack boundaries to solve pressing product challenges.

This guide is scoped to a Software Engineer candidate at Hearth.

Focus areas

  • Coding challenges (algorithmic problem solving)
  • System design
  • Backend engineering

The Hearth interview process

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

Recruiter Screen

Initial screening by a recruiter to evaluate your background and role alignment.

What to demonstrate

  • Initial screening by a recruiter to evaluate your background and role alignment
  • Depth in Coding challenges (algorithmic problem solving)

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.

Engineering Manager Conversation

Discussion with an engineering manager to assess technical background and fit for the role.

What to demonstrate

  • Discussion with an engineering manager to assess technical background and fit for the role
  • Depth in Coding challenges (algorithmic problem solving)

How to prepare

  • Answer aloud and timed: Given a raw dataset of financial transactions, write a SQL query to aggregate monthly transaction volumes and identify high-value contractor accounts.
  • Answer aloud and timed: Design a function to identify and resolve circular dependencies within a software build dependency graph.

Technical Assessment

Practical coding assessment, which may include a timed coding challenge or a take-home project.

What to demonstrate

  • Practical coding assessment, which may include a timed coding challenge or a take-home project
  • Depth in Coding challenges (algorithmic problem solving)

How to prepare

  • Answer aloud and timed: Design a rate-limiting system for Hearth's public-facing API to prevent abuse while ensuring high availability for legitimate contractor integrations.
  • Answer aloud and timed: Architect an end-to-end notification system that alerts contractors of payment updates via SMS, email, and push notifications, ensuring guaranteed delivery.

Onsite Loop

Comprehensive virtual or in-person interviews covering architectural design, live coding, and behavioral interviews.

What to demonstrate

  • Comprehensive virtual or in-person interviews covering architectural design, live coding, and behavioral interviews
  • Depth in Coding challenges (algorithmic problem solving)

How to prepare

  • Answer aloud and timed: Walk through the database schema design and API endpoints required to support a new multi-user billing and invoicing permissions system.
  • Answer aloud and timed: How would you design a distributed transaction system that guarantees consistency when processing loan applications across multiple third-party banking APIs?

Where candidates lose points

Over-communicate during quiet rounds

If your interviewer is silent during a live coding session, do not fall silent yourself. Treat the session as a presentation of your coding thoughts, explaining your logic, variable naming, and edge-case handling out loud.

Master the IPv6 challenge

If you are instructed to prepare for the IPv6 networking question, invest time in mastering it. Understand all edge cases, shorthand rules, and string manipulation techniques, as this is a heavily weighted technical benchmark.

Ensure your CodeSandbox or local development environment is fully functional and updated before your virtual onsite

Technical glitches can disrupt your focus, so having a clean, simple backup environment ready is highly recommended.

Questions & practice

Write a program to parse, validate, and compress or expand an IPv6 address, handling all valid shorthand repre

Medium · Technical and Coding Challenges

Write a program to parse, validate, and compress or expand an IPv6 address, handling all valid shorthand representations and edge cases.

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?

Implement an efficient search algorithm to filter through a large, in-memory dataset based on dynamic user que

Medium · Technical and Coding Challenges

Implement an efficient search algorithm to filter through a large, in-memory dataset based on dynamic user queries.

Approach

  1. Say what the runtime actually does before reasoning about the code.
  2. Name what is shared across threads and what owns each piece of state.
  3. Identify the window where an invariant is briefly untrue.
  4. Distinguish a value from a reference to it, and say which one you handed out.

Follow-up

  • What happens if two callers reach this at the same time?
  • Where could this allocate more than you expect?

Canonicalise a request body into a stable idempotency fingerprint

Medium · parsing · canonicalisation · hashing

idempotency_key.request_fingerprint is a SHA-256 over the method, path and canonicalised body, and a retry whose fingerprint differs must be rejected with 422 rather than served the stored response. Write the canonicaliser. Bodies are JSON up to 256 KB nested at most 32 levels; clients vary key order, whitespace and unicode escaping, and some send 64-bit ids as JSON numbers. Produce a deterministic byte string such that semantically identical bodies match and any semantic difference does not. State your complexity and name two normalisations you refuse to perform.

Approach

  1. Parse once into a tree, then re-serialise under fixed rules: object keys sorted, array order preserved, one escaping convention, no insignificant whitespace. Parsing is O(n) and sorting keys is O(k log k) per object, so O(n log n) overall with O(depth) stack, and the 32-level cap is enforced during parsing because hostile nesting is how a canonicaliser becomes a stack overflow.
  2. Sort keys by their UTF-8 bytes and say why the obvious implementation is wrong in some runtimes: a default string comparison that orders by UTF-16 code units places surrogate pairs, meaning code points from U+10000 up, below U+E000 to U+FFFF, which is not UTF-8 byte order, so two services written in different languages disagree on the same document.
  3. Do not re-encode numbers through a double. IEEE-754 binary64 represents integers exactly only up to 2^53, so normalising a 19-digit id through a float changes it, and 1 against 1.0 cannot be reconciled without deciding whether they are the same value. Preserve the literal token, and require ids as strings at the API boundary if you want them comparable.
  4. Reject duplicate keys rather than picking one. JSON permits them and parsers disagree, most keeping the last, so any choice you make ties the fingerprint to a parser detail that the code handling the request does not necessarily share.

Follow-up

  • A client sends the same logical request with an extra field your API ignores. Same key, different fingerprint, so you return 422. Is that the right answer?
  • Where does the fingerprint get computed relative to request decompression and the body-size limit?

Given a raw dataset of financial transactions, write a SQL query to aggregate monthly transaction volumes and

Medium · Technical and Coding Challenges

Given a raw dataset of financial transactions, write a SQL query to aggregate monthly transaction volumes and identify high-value contractor accounts.

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?

Write the update path that detects a concurrent edit

Medium · optimistic concurrency · transactional outbox · audit history

resource carries version INT NOT NULL DEFAULT 1. resource_revision holds revision_id, resource_id, version, actor_user_id, change_kind, patch JSONB, request_id, created_at with UNIQUE (resource_id, version). outbox_event holds aggregate_type, aggregate_id, aggregate_version, event_type, payload, status. A PUT carries the version the client read. Write the exact statements for the single transaction that applies the edit, records the revision and enqueues 'resource.updated', and give the handler's branch on zero affected rows. Then say what PostgreSQL 16 does under READ COMMITTED when two of these updates hit one row at once.

Approach

  1. One transaction, three writes, no network call inside it: UPDATE resource SET title = $3, version = version + 1, updated_at = now() WHERE resource_id = $1 AND tenant_id = $4 AND version = $2; then INSERT the resource_revision row at version $2 + 1; then INSERT the outbox_event row at the same aggregate_version. The event goes to a table rather than a broker because no transaction spans both.
  2. Branch on the affected-row count before doing anything else. Zero has three causes — stale version, wrong tenant, row gone — so re-read once and map to 409 carrying the current version, or 404 for an id outside the caller's tenant, which also stops the endpoint confirming that another tenant's id exists.
  3. State the engine behaviour instead of assuming it. Under READ COMMITTED the second UPDATE blocks on the row lock, and when the first commits PostgreSQL re-evaluates the WHERE clause against the newly committed row, so the version predicate now fails and the statement reports zero rows. Under REPEATABLE READ the identical collision raises SQLSTATE 40001 instead, so the handler must fold both shapes into one conflict response.
  4. Keep UNIQUE (resource_id, version) even though the predicate already serialises writers. It is what makes a lost update unwritable if any other path ever reaches the revision table, and it converts a logic bug into 23505 rather than into a silently missing history row.

Follow-up

  • A client sends the version it read ten minutes ago and the resource has moved three versions. What is in your 409 so it can resolve the conflict without a full re-fetch?
  • Two editors, two disjoint fields, no overlap. Does your answer still refuse the second write, and should it?

Design a function to identify and resolve circular dependencies within a software build dependency graph.

Medium · Technical and Coding Challenges

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?

Design a rate-limiting system for Hearth's public-facing API to prevent abuse while ensuring high availability

Medium · System and Product Design

Design a rate-limiting system for Hearth's public-facing API to prevent abuse while ensuring high availability for legitimate contractor integrations.

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?

Architect an end-to-end notification system that alerts contractors of payment updates via SMS, email, and pus

Medium · System and Product Design

Architect an end-to-end notification system that alerts contractors of payment updates via SMS, email, and push notifications, ensuring guaranteed delivery.

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?

Walk through the database schema design and API endpoints required to support a new multi-user billing and inv

Medium · System and Product Design

Walk through the database schema design and API endpoints required to support a new multi-user billing and invoicing permissions system.

Approach

  1. Say who the caller is and what they do when the call fails halfway.
  2. Define the identity of a request so a retry cannot double-apply it.
  3. Separate accepted, pending, failed and confirmed; they are different facts.
  4. Design the error taxonomy before the success shape; callers branch on it.

Follow-up

  • What happens if the caller retries after a timeout?
  • How does a client discover it is on an old version of this contract?

How would you design a distributed transaction system that guarantees consistency when processing loan applica

Medium · System and Product Design

How would you design a distributed transaction system that guarantees consistency when processing loan applications across multiple third-party banking APIs?

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?

Edge instances grow 400 MB per hour until the nightly restart

Hard · memory leak · heap analysis · metric cardinality

Edge API instances start at 700 MB resident and grow about 400 MB/hour; a nightly rolling restart has hidden it for weeks. Growth continues unchanged when request rate halves overnight, p99 degrades in the last hours before an instance is recycled, and heap used immediately after a forced full GC rises monotonically. The service holds no product state. Name the discriminating measurement that separates the plausible causes, give the most likely cause, and give the fix and how you would verify it.

Approach

  1. Separate resident memory from live heap first, because they fail differently. Resident size can grow from fragmentation, native buffers or thread stacks while the heap is flat; heap used after a full GC rising monotonically is the measurement that says objects are reachable and not being released. You already have it, so this is retention, not fragmentation, and that closes off half the candidate list.
  2. Use the rate's independence from traffic as the discriminator. Growth that continues at half the request rate rules out per-request objects that are merely slow to collect and points at a structure that grows with distinct values observed rather than with call volume. Write the candidates that have that property: a metrics registry keyed on a high-cardinality label, an unevicted cache, an interner, a per-key lock map.
  3. Take two heap snapshots an hour apart and diff by retained size, reading the dominator tree, not by allocation count or instance count. Expect one root holding a map with millions of entries, then follow the reference chain to the code that inserts and never removes. Allocation profilers point at churn, which is the wrong signal here.
  4. The candidate that fits this service is an observability label carrying an identifier, such as a request path recorded before templating so that /v1/resources/48213 becomes its own metric series. That grows with distinct ids seen, is independent of rate, and explains the late p99 degradation, since GC cost rises with the size of the live set.

Follow-up

  • Post-GC heap is now flat but resident size still creeps. What are you looking at, and does it matter?
  • How would you have detected this before an OOM, given the nightly restart masked the trend?

Suggested practice checklist

Built from the rounds and topics Hearth candidates report.

Day 1 — Map the Hearth loop

  • Write out the reported sequence: Recruiter Screen, Engineering Manager Conversation, Technical Assessment, Onsite 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 4 reported rounds, with the weakest marked.

Day 2 — Work Coding challenges (algorithmic problem solving)

  • Spend the session on Coding challenges (algorithmic problem solving), which Hearth candidates report being tested on.
  • Write one worked example in Coding challenges (algorithmic problem solving) and time yourself on it.

Deliverable: One timed worked example in Coding challenges (algorithmic problem solving).

Day 3 — Work System design

  • Spend the session on System design, which Hearth candidates report being tested on.
  • Write one worked example in System design and time yourself on it.

Deliverable: One timed worked example in System design.

Day 4 — Work Backend engineering

  • Spend the session on Backend engineering, which Hearth candidates report being tested on.
  • Write one worked example in Backend engineering and time yourself on it.

Deliverable: One timed worked example in Backend engineering.

Day 5 — Answer out loud: Technical and Coding Challenges

  • Answer aloud, timed: Write a program to parse, validate, and compress or expand an IPv6 address, handling all valid shorthand representations and edge cases.
  • Answer aloud, timed: Implement an efficient search algorithm to filter through a large, in-memory dataset based on dynamic user queries.

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

Day 6 — Answer out loud: System and Product Design

  • Answer aloud, timed: Design a rate-limiting system for Hearth's public-facing API to prevent abuse while ensuring high availability for legitimate contractor integrations.
  • Answer aloud, timed: Architect an end-to-end notification system that alerts contractors of payment updates via SMS, email, and push notifications, ensuring guaranteed delivery.

Deliverable: Spoken answers to 2 reported System and Product Design question(s), under time.

Day 7 — Answer out loud: Behavioral and Leadership

  • Answer aloud, timed: Describe a time when you had to make a critical architectural decision under tight deadlines with incomplete product specifications.
  • Answer aloud, timed: How do you approach explaining complex technical trade-offs to non-technical stakeholders, such as product managers or business executives?

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

Behavioural preparation

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

Describe a time when you had to make a critical architectural decision under tight deadlines with incomplete p

Medium · Behavioral and Leadership

Describe a time when you had to make a critical architectural decision under tight deadlines with incomplete product specifications.

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 explaining complex technical trade-offs to non-technical stakeholders, such as product man

Medium · Behavioral and Leadership

How do you approach explaining complex technical trade-offs to non-technical stakeholders, such as product managers or business executives?

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?

Share an experience where a project you were leading fell behind schedule. How did you manage stakeholder expe

Medium · Behavioral and Leadership

Share an experience where a project you were leading fell behind schedule. How did you manage stakeholder expectations and get the team back on track?

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?

Why do you want to work in the fintech and home improvement space, and how do you maintain high productivity i

Medium · Behavioral and Leadership

Why do you want to work in the fintech and home improvement space, and how do you maintain high productivity in a self-directed startup environment?

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?