Not the perks page. The small habits that make a week here feel like a week somewhere specific.
You are paired with someone from day one. They answer the questions you would feel silly asking in a group, and they are supposed to.
Show the working thing, warts included. A half-finished screen that runs beats a beautiful slide about a screen that does not.
Asking early is treated as good judgement, not as a gap. The expensive thing is the person who quietly guessed for three days.
Whoever builds it should watch somebody use it. It is humbling, it is the fastest way to learn the domain, and it changes what you build next.
The migration that went quietly, the flaky test finally killed, the error message rewritten so it actually helps. Those get called out.
First hospital live, a nasty bug closed, someone's first shipped feature. Work in this domain is long, so the milestones are worth pausing on.
No two weeks look identical, and none of the above is a policy. It is just what tends to happen.
Where we are hiring, and what each role would own. If nothing below fits but you think you should be here, say so.
We are not hiring at this moment, and we would rather tell you that plainly than leave a stale listing up for you to apply to.
If you think you should be here anyway, send us a note about what you do and what you would want to work on. We keep them, we read them, and we do come back to people when something opens up.
Teams are small enough that there is nowhere for a decision to hide. You will be the person who understands a part of the system best, and the person asked when it breaks.
Almost nobody arrives knowing how a ward actually runs, what an HL7 message carries or why a consent rule is worded the way it is. You are expected to learn it, not to have arrived with it.
A release that is not ready gets stopped, by whoever spots it. That is slower some weeks. It is the reason the thing works at three in the morning when somebody is relying on it.
Decisions get written down so the reasoning survives the person who made it. You do not need to be a stylist, but you do need to be able to explain a choice in a paragraph.
This is not software that disappears into a backlog. You will sit in on implementations, watch it used, and hear directly when a screen is in somebody's way.