What is the Happydance interview process for software engineers?

Interview processes are where companies' stated values go to be tested, and most fail: five rounds, ghosting, puzzles nobody solves at work. Ours is built on the same Sell The Truth principle as everything else here, which means total transparency about the stages, the criteria, the timeline, and the honest reasons candidates do not get through.

What happens at each stage?

Stage 1: the intro call (30 minutes, video)

A conversation with the hiring manager, not a screening interrogation. We tell you the truth about the role, the stack, the salary band and the hybrid expectation of 2 to 3 days together per week. You tell us what you are actually looking for. The single purpose is mutual filtering: around a fifth of candidates conclude here that the fit is wrong, usually on hybrid working or salary, and we count that as the process working, not failing.

We assess: whether what you want and what this is genuinely overlap. Nothing technical yet.

Stage 2: the technical conversation (60 minutes, video)

Two engineers walk through your real experience: systems you have built, decisions you made, trade-offs you regret, what you would do differently. Expect questions like "talk us through the gnarliest production issue you have dealt with" and "tell us about a technical decision you got wrong". There is no live algorithm quiz. We do not care whether you can invert a binary tree under stress, because the job never asks you to.

We assess: depth of understanding of work you claim as yours, technical judgement, and how honestly you talk about mistakes. That last one is genuinely scored. A candidate who has never been wrong is either unreflective or not telling the truth, and neither works here.

Stage 3: the practical exercise and review (take-home plus 60 minutes)

A small, realistic exercise in the territory of the role, typically extending or fixing a slice of code shaped like our actual platform, TypeScript for most roles. It is designed for two to three hours of your time, and we say so explicitly: gold-plating it for ten hours earns no extra credit and we can usually tell. If a take-home is impossible for your circumstances, tell us and we will run it as a paired session instead. The review session is the part that matters: you walk two engineers through your choices, we change a requirement and see how you think, and you experience what code review here actually feels like.

We assess: code quality at a realistic scale, reasoning under changed requirements, and how you respond to challenge. Not speed, and not whether your solution matches some secret ideal one.

Stage 4: the final conversation (45 minutes, usually in person)

With the hiring manager and someone from the wider team, about how you work: collaboration, disagreement, feedback, what has made past teams good or bad for you. If you have not yet met people from the squad you would join, this is where you do, and we encourage you to interview us hard. You can also ask for an informal call with any engineer, no managers present, at any stage.

We assess: whether the way you work will make the squad better, and whether we would be good for you, which is a real question and not a slogan.

How long does the whole process take?

Two to three weeks from application to decision is typical, and we tell you at each stage exactly when you will hear back, then keep to it. Feedback after every stage is specific and honest, including when the answer is no, because being ghosted after giving a company hours of your life is disrespect, and a company built on candidate experience software would deserve everything it got if it ghosted people.

If you are interviewing elsewhere with deadlines, say so. We can compress the process to about a week when it matters, and knowing your constraints helps us more than it hurts you.

How should you prepare?

Honestly, less than you think, and differently than you fear:

• Revisit your own work. The technical conversation goes deep on things you have actually built, so refresh your memory of the details, the numbers, and what went wrong.
• Read this site. The role pages tell you what we build, how we work and what the hard parts are. Candidates who have read them ask better questions and relax faster.
• Prepare real questions. You are making a bigger decision than we are. Ask about the debt, the frustrations, the ground truth. Nothing on this site is off limits in the room.
• Do not cram algorithms. Genuinely. There is no stage where that effort pays off.

Why do candidates actually fail?

In the spirit of the whole site, the real reasons, in rough order of frequency:

1. Shallow ownership. The CV says "built", the conversation reveals "was nearby while it was built". Depth on a modest project beats surface on an impressive one, every time.
2. No relationship with their own mistakes. Candidates who cannot name a decision they got wrong, or who blame every failure on someone else, fail stage 2 more than anything else does.
3. Brittleness under changed requirements. In stage 3, some candidates defend their first solution to the death. The job is 40 squads' worth of changing requirements a year; the review simulates one.
4. Wanting a different job. Fully remote, pure greenfield, a narrow specialist lane. Legitimate wants, honestly incompatible with this role, better discovered in stage 1 than month two.
5. Code that ignores the unglamorous. Error handling, accessibility, naming, tests. Our platform holds WCAG 2.2 AA as a hard requirement, and exercises that treat quality as optional polish tell us how you would treat it in production.

What adjustments do we offer?

Any adjustment that lets you show your real ability, offered as standard and arranged without ceremony. That includes: extra time or a paired alternative to the take-home, questions or materials shared in advance, breaks whenever you need them, interviews split across shorter sessions, video off if that helps you think, a preferred communication format for anything hearing or speech related, wheelchair-accessible interview spaces, and a named contact so you never have to re-explain your needs to a stranger at each stage. Tell us what works for you at any point, no diagnosis or justification required. Bias detection is literally a feature of our product; running an inaccessible interview process would be an embarrassment we are not willing to earn.

Frequently asked questions about interviewing here

Will I have to do a live coding test?

No live algorithm test, ever. The practical exercise is take-home by default, paired by choice, and always reviewed through conversation rather than judged in silence.

Who will actually interview me?

Engineers you would work with, plus the hiring manager. No outsourced screeners, and no panel you meet once and never see again. More candidate-side detail lives in the interviews and applying FAQ.

Can I get feedback if I am rejected?

Yes, specific and written, after any stage, as standard rather than on request. It is the least a candidate's time deserves.

What should I wear to the final conversation?

Whatever you would wear to work here, which is to say, whatever you like. Nobody has ever been assessed on it and nobody ever will be.

---

If a process this transparent tells you something about how the rest of the company runs, that is exactly the inference we hope you draw, and the live roles are where it starts. To hear from people who sat on your side of the table first, read the engineer stories.