The work
What does a software engineer at Happydance do day to day?
A software engineer at Happydance spends most of the week writing and reviewing code for an AI-powered careers platform, punctuated by a daily 15-minute stand-up, a handful of sprint ceremonies, and 2 to 3 days a week working alongside the squad in person. A typical week is roughly 60 to 70% deep work, 20% collaboration and review, and 10% meetings, admin and the boring bits that every real engineering job contains.
Most "day in the life" pages are fiction. They describe a week with no interruptions, no tedious tickets and no Thursday afternoon where the build breaks for a stupid reason. This one is the truthful version, Monday to Friday, including the parts nobody puts in a job advert.
What does Monday look like?
Monday is usually an office day, and it starts with the sprint's shape rather than a pile of surprises. If you live out in Crosby or Ormskirk you are probably on Merseyrail, which is one of the UK's most punctual networks, so the commute is a podcast and a sit-down rather than a fight. City centre people walk or cycle in.
The day itself:
- 09:30, stand-up. Fifteen minutes, actually fifteen minutes. What moved, what is blocked, who needs a pair.
- 10:00 to 12:30, deep work. Monday morning is protected. You pick up the sprint's main course, say a change to the structured data pipeline that feeds AI discoverability for a client's careers site, and you get properly into it.
- Lunch. Together on office days more often than not. Nobody schedules meetings over it.
- Afternoon. More build time, one or two pull request reviews for squadmates, and if it is the first Monday of a sprint, planning, which takes about 90 minutes and sets the fortnight.
The honest footnote: Mondays after a release weekend occasionally start with a triage instead of deep work. Enterprise clients notice things on Monday mornings. It is not usually chaotic, but it is not never.
Is Tuesday just more of the same?
Broadly yes, and that is the point. Tuesday is typically the deepest work day of the week, often at home, with the calendar deliberately quiet. Engineers here guard long uninterrupted blocks because multi-tenant platform work punishes shallow attention. A change that behaves for one client and misbehaves for another forty is the kind of bug you only prevent by thinking properly, and thinking properly needs hours, not gaps between calls.
A realistic Tuesday: headphones on by 9, a hard problem until lunch, a walk or a run at lunchtime because you can, then implementation through the afternoon, with Slack on slow-reply mode and nobody minding. If you are blocked, you post in the squad channel and pair when it suits you both.
What happens on the collaboration days?
Wednesday is commonly the second office day, and it carries most of the week's talking. Sprint reviews and retros land here at the end of each fortnight. Retro is short and unusually candid, because the how-we-work culture treats "this frustrated me" as useful data rather than bad attitude. Backlog refinement happens here too, which is genuinely one of the less thrilling hours of the week, and we will not pretend otherwise. Somebody has to size the tickets.
Wednesday is also when the cross-squad stuff happens: an architecture discussion about how the LLM API layer should handle a new model version, a session with a product manager unpicking what an enterprise client actually meant by their feature request, or an accessibility review, because WCAG 2.2 AA is a hard requirement here and it gets checked like one.
Where does the deep work fit around meetings?
Deliberately, and in writing. The working agreement across squads is that mornings lean towards maker time and meetings cluster after lunch where possible. It is not perfect. Some weeks a client escalation or a release deadline tramples the tidy version, and anyone who tells you their calendar survives every sprint intact is selling something. But over a typical fortnight, an engineer here gets more protected build time than most of us got at bigger companies, mostly because there are fewer layers of people whose job is to schedule meetings.
Thursday reflects that: often a home day, long focus blocks, finishing the sprint work, writing tests, tightening the pull request so review is quick. Somewhere in the afternoon you will review someone else's PR properly, which at Happydance means reading it, running it and commenting like you care, because code review culture here is real rather than rubber-stamp.
What does Friday look like, honestly?
Friday is the finish-and-tidy day: closing out tickets, merging what is ready, writing the documentation you promised yourself you would write, and the small unglamorous jobs like dependency updates and flaky test fixes. Once a quarter Friday becomes a hack day instead, and those are the days people talk about for months, because some of the platform's better ideas started as someone's Friday experiment.
The last hour of Friday is loose by design. People peel off for five-a-side, for the school run, for a pint in the Baltic Triangle, or for an early train because the weekend in Liverpool starts with a parkrun. Nobody performs lateness here. Working late occasionally happens near a big release; working late as a lifestyle is treated as a planning failure, not a badge.
What are the boring bits nobody advertises?
Every engineering job has them and this one is no exception:
- Ticket admin. Keeping the board honest takes ten minutes a day and it is nobody's favourite ten minutes.
- Estimation. Sizing work on a platform this interconnected is hard and sometimes feels like guessing with extra steps. We do it anyway because sprints need shape.
- Enterprise process. Big clients have change windows, security questionnaires and release sign-offs. The stability that makes this a sane place to work comes partly from that process, so you learn to respect it even when it slows you down.
- Legacy corners. Parts of the codebase are older than our current standards, and some sprints you will be in them. Where the debt lives is mapped openly on the tech stack page.
We include this list because the persona we hire is allergic to being sold a fantasy. The week is genuinely good. It is not magic.
Frequently asked questions about the working week
How many meetings does a software engineer at Happydance have per week?
Typically five to seven hours in a normal week: daily stand-ups, plus planning, review, retro and refinement spread across each two-week sprint. Meeting load is lighter mid-sprint and heavier at the boundaries.
Which days do engineers go into the office?
Squads coordinate 2 to 3 shared days per week, most commonly Monday and Wednesday, chosen by the squad rather than imposed centrally. The point is overlapping in person, not filling seats.
Can I shift my hours around family life?
Yes, within reason. School runs, nursery pick-ups and the odd sports day flex around core collaboration hours without drama. What matters is that your squad can rely on you, not which sixty minutes you ate lunch in.
Is there on-call?
There is a lightweight rota for platform incidents, shared across engineers, with time back after any disturbed night. Incidents are rare enough that people mostly forget which week is theirs, but we would rather tell you it exists.
---
If a week shaped like this sounds like the rhythm you have been trying to find, the current software engineer openings show where you would slot in. For the tools you would spend that week using, read the tech stack, debt and all.
See the open roles, hard parts and all
Every vacancy publishes its salary band and its honest trade-offs. Read them as carefully as the good parts, then apply if it still fits.
Browse software engineer jobs in Liverpool