ExperienceSoftware Developer Intern
Software Developer Intern
Dayforce, Performance Engineering Team
Sep '23 - Dec '23 · 4 months
Case study
Returning to the Performance Platform
A second term on the Performance Engineering team, on the same platform I had started earlier that year. In between, I did an SDE internship at Amazon - and I came back to my own code as a noticeably more confident engineer, on a project that had also outgrown where I left it.
Context
This is a short write-up of the second term and what changed, kept at the level of engineering ideas rather than internal specifics.
It picks up the project from my first term earlier in 2023 - written up here.
Same project, further along
First term
A single-snapshot performance dashboard, designed in Figma and built in plain JavaScript. It worked, but it was still shaped like a prototype.
Second term
Comparison across a large set of historical snapshots, an automated data path feeding it, and a codebase moved onto footing that could keep growing.
What had matured - me, and the project
The gap between the two terms mattered. The Amazon internship put me on a large codebase with real review and real constraints, and I came back with more instinct for structure, types, and shipping in small increments instead of big ones.
The project had moved on too. What started as a way to view one performance snapshot now needed to answer questions across many of them at once, which is a different kind of problem.
The new capability: comparison
The new work was comparative analysis. Instead of reading a single snapshot, engineers needed to line up a large set of historical ones and see where behaviour had drifted - regressions, patterns, the moment something changed.
That is a data-modelling problem as much as a UI one: put every number on screen and it stops being useful, so a good part of the work was deciding what to compare and how to reduce it before it ever reached a chart.
Automating the data path
The data those comparisons needed used to be gathered by hand. I built a Node.js path that retrieves and prepares it automatically, with Azure services behind it, so the comparison view always had current data without someone assembling it first.
Firmer engineering foundations
With the scope growing, the prototype-era tooling had to go. I moved the front-end to TypeScript so the shape of the data was enforced rather than assumed, and adopted shared design-system tooling so the UI stayed consistent as more views were added.
Working part-time around a course load also forced good habits - tight scoping, and shipping in small, reviewable increments rather than large drops.
My contribution
- I extended the platform with the multi-snapshot comparison feature, front to back.
- I built the automated data-retrieval path that keeps it fed.
- I helped move the codebase onto a more maintainable footing - types, shared components, smaller changes.
What I took from it
Coming back to your own code after growing as an engineer is the clearest mirror you get. I could see every shortcut I had taken the first time, and why it had cost something since.
The tooling choices that feel optional on a prototype - types, a shared component system, an automated data path - are exactly what decide whether it can keep growing or quietly calcifies.
Technology
TypeScript · React · Tailwind CSS
The front-end, now with enforced data shapes
Design-system tooling
Shared components keeping the UI consistent as it grew
Node.js
The automated data-retrieval path
Azure · C#
Services behind the data pipeline
© 2026 Gaurav Divecha. All rights reserved.