Top 3 Questions From Hotjar Engineering Candidates

Who doesn’t have tech debt? Our codebase has existed for over seven years, and it definitely has parts that need more love.

Different squads (our internal term for a single cross-functional team) have varying amounts and deal with it differently depending on their needs. If it isn’t broken and the code doesn’t need to change, it often becomes debt as a result of other parts evolving.

For example, an endpoint for a new feature might use a different validation library. Generally, the old endpoint will remain on the old method unless there’s a pressing need to remove it (such as the older validation library becoming outdated and this dependency blocking us from moving to the next version of Python.)

We try to look at this as technical solvency rather than technical debt. No debt means you’re over-engineering for today’s requirements, which can easily change tomorrow; too much means you’re under-engineering and sacrificing quality, which reduces your reliability and time to market. Striking a good balance between the two is something we try to do every day.

If we count all the initiatives we invest in to manage our technical debt, we spend around 20% of our time managing it. This includes work done by squads in the various product Tribes, our Engineering Enablement Tribe, and Chapter Weeks, where we spend one week per quarter on wider-impact initiatives instead of product squad work.