Prepare for the work, then the interview.
Bring a project you understand, decisions you can explain and questions that help both sides assess the fit.
Interview preparation starts with the role and the employer's process. Ask about the format, duration, expected preparation and tools you may use. The exercises below are original practice prompts, not leaked questions or a promise of what an employer will ask.
1. Learn how this team evaluates work.
Read any hiring guide the company publishes. Galoy's engineering guide, reviewed on 13 September 2026, describes technical conversations about real problems and systems a candidate has built, with emphasis on reasoning and tradeoffs. That is evidence about Galoy's process, not a rule for every Bitcoin employer.
Read the product documentation or a small part of a relevant public repository. Prepare one observation and one question. You do not need to claim expertise in an unfamiliar codebase after a quick inspection.
2. Prepare a ten-minute project walkthrough.
- The problem: who needed what, and which constraints mattered?
- Your contribution: what did you personally design, implement, review or test?
- The decision: which alternatives did you consider and why did you choose this one?
- The difficult case: what failed, surprised you or remained uncertain?
- The result: what evidence supports the outcome, and what would you improve?
Keep a working demo or a short recording, the exact project revision and a one-page explanation ready. Label local prototypes and test data clearly. If your example involves confidential work, use an approved description or a separate public example.
3. Practice a scenario close to the role.
| Role | Original practice prompt | What to explain |
|---|---|---|
| Payment backend | A checkout receives the same payment-status event twice. | Your order model, source of truth, repeat handling and how you would test the outcome. |
| Infrastructure | The payment service is slow, but the node is reachable. | The evidence you need, how you narrow the fault and what the user should see while status is uncertain. |
| Wallet QA | A request appears expired on one screen and paid on another. | Reproduction steps, timing, authoritative state, expected behavior and a regression test. |
| Product design | A new user cannot tell whether a payment request was sent or paid. | The task, content and state distinctions; alternatives; and how you would evaluate understanding. |
| Firmware | A device action is interrupted before completion. | The documented device constraints, recovery behavior, tests and assumptions you need to investigate. |
| Engineering leadership | An integration deadline competes with unresolved reliability work. | How you define risk, gather evidence, agree priorities and communicate the decision. |
Start by asking clarifying questions. Draw the boundary between the user interface, your service and external systems. Name assumptions instead of silently choosing them. Explain how you would verify uncertain behavior in the relevant documentation or test environment.
4. Use reference material deliberately.
Choose material for the problem you are practicing: the versioned Bitcoin Core RPC reference for node interfaces; Boltz documentation for its SDK-based swap integration; or the design portfolio guide for a complete wallet task flow. Check which implementation and version an example assumes.
Write a short test record with the inputs, expected behavior, actual result and remaining limits. An explanation becomes much stronger when a reviewer can reproduce it.
5. Prepare questions for your future teammates.
- What would a useful first month look like for this role?
- How do changes move from review to testing and release?
- Which user or operational problem takes the most team attention?
- How are design, engineering and support involved in a product decision?
- What overlap hours, on-call duties or travel does the role require?
- How does the team use and review AI-assisted work?
- What are the remaining hiring steps and expected timing?
For a take-home task, clarify the time budget, evaluation criteria, permitted tools and whether you may discuss the work publicly. If a requested task is larger than you can accommodate, propose a bounded alternative before starting.
6. Debrief without rewriting history.
After the conversation, record what you were asked, what you explained clearly and where you need more evidence. Separate employer feedback from your own interpretation. Improve one example or one explanation for the next conversation.
If you find a factual error in your submitted work, correct it through the employer's normal process. A candid correction is more useful than continuing to defend an answer you no longer believe.
Still building your shortlist? Use the Bitcoin job-search guide and CV guide to connect your evidence to a relevant role.
Keep your next step visible.
Use the editable application tracker to record role fit, evidence, questions and your next action. The completed file stays with you.
Download application tracker ↓