Tell about a time when you had to go against the norm and push for a change

In my first year on a backend team, the norm was to follow a manual release checklist exactly as written, even though several steps were repetitive and easy to miss. After seeing one release delayed because a step was skipped, I asked why we hadn't automated parts of it and learned the team had tried before but lost visibility into one risky verification step. I put together a small script for the safe repetitive parts, kept the manual verification explicit, and walked through it with my mentor and the teammate who owned releases. We tried it on a lower-risk service first, then adjusted the order of a couple of steps based on feedback. After that, releases were a bit faster and, more importantly, we stopped missing the specific step that had caused confusion. What I learned was that pushing for change worked much better once I understood why the old process existed instead of assuming it was just outdated.

At my previous job as a junior frontend developer, the team routinely prioritized visual polish and fast shipping, and accessibility fixes were usually pushed to an undefined 'later' backlog. After answering a few support tickets from users who couldn’t navigate our product with a keyboard, I felt strongly we were excluding real customers and raised it in our weekly planning. I built a small, accessible version of our signup flow that handled keyboard focus and used screen-reader-friendly labels, then demoed it side-by-side with the current flow to show the difference. I suggested adding three lightweight accessibility checks to our definition of done and offered to update the shared component library with accessible patterns. The team agreed to try the checks for the next two sprints; we caught and fixed several issues before release and saw fewer accessibility-related support requests. I learned that bringing concrete examples and low-effort fixes made it much easier to change team norms around inclusivity.