We want every candidate to come into the process informed and prepared. This guide explains what we look for, what our interviews focus on, and how to give yourself the best chance of a good outcome — for both of us.
What We Look For
Real Production Experience
We want to hear about systems you’ve actually built, contributed to, or maintained at any level — a side project running in production, open-source contributions, client work, or employer projects. What matters is that you’ve dealt with real-world constraints: performance, reliability, maintainability, and the messy bits that don’t show up in tutorials.
You don’t have to have built the entire system yourself. If you’ve deeply understood a system, contributed to it, and can talk to the engineering decisions made — that counts.
Strong Engineering Fundamentals
We test for depth, not trivia. Expect questions around architecture, API design, database modelling, debugging, and how you make engineering decisions under uncertainty.
Problem-Solving Ability
We’re interested in how you think, not just what you know. Walk us through your reasoning. Talk about what you’d consider, what trade-offs you’d weigh, and what you’d do if your first approach didn’t work.
Communication
Clear communication matters to us — not formal language, perfect grammar, or long essays. We mean: can the people receiving your message understand it? A short, clear reply beats a long, vague one every time. Not responding to emails is the only communication issue we take seriously.
The Human Element
We’re not hiring robots. We want people who bring curiosity, personality, and genuine engagement to the work. Interviews are two-way conversations. Ask questions. Share your perspective. We’re not looking for rehearsed answers — we’re looking for real ones.
How to Prepare
Before You Apply
- Make sure your resume reflects what you have actually built or contributed to
- Your GitHub profile or portfolio should be current — if it’s not, mention what you’ve been working on recently
- Answer application questions with specifics, not generalities
- The introduction video (2–5 minutes) is your chance to make a first impression in your own words — it doesn’t need to be polished, it needs to be you
For the Screening Call
- Be ready to discuss your availability, preferred contract type, and time zone
- Be honest about your experience — we’ll go deeper in the technical interview
- Confirm that the work in your application is genuinely your own
For the Technical Interview
- Review the systems and projects you’ve listed — be ready to go deep on architecture and decisions
- Think through how you’d approach a problem you haven’t seen before — talk out loud
- Brush up on API design, database modelling, and distributed system concepts relevant to your role
- Don’t memorise answers — understand concepts
For the Final Interview
- Prepare questions about the role, the team, and the projects
- Be honest about what you’re looking for — alignment matters to us
- Think about how you work best and how that maps to a distributed, async-leaning team
On Using AI
We use AI tools ourselves and provide access to them if you join us. In the interview process, we’re evaluating your understanding, not your ability to produce output. If you’re asked to discuss code or architecture, we want to hear your thinking — demonstrating that you understand what you’ve built and why is more important than any polished answer.
Entry-Level and Non-Technical Roles
Not every role requires a technical assessment. For internships, junior roles, and non-technical positions, assessments are adapted to the role. What we’re still evaluating: communication, problem-solving mindset, willingness to learn, and character.
We invest in the people we hire. If you’re entry-level and the foundations are there, we’ll help you grow into what the role requires.
Back to Careers