Describe a time when you took on work outside of your comfort area.

Early in my first year, I had mostly worked on small bug fixes, and my team needed someone to add a new internal reporting page. That was outside my comfort area because it was the first time I had to touch both the backend and the UI for one feature. I broke the work into smaller pieces, reviewed similar code paths, and asked a more experienced teammate to check my approach before I started on the part that affected data access. I built a simple first version, added tests, and got feedback in two short review cycles instead of waiting until the end. We shipped it on time, and the biggest result for me was that I became much more comfortable owning a feature instead of just isolated tasks. After that, my lead started giving me broader tickets in that same area.

On my second internship after joining the web team I was mainly styling components, but our product owner asked for someone to fix several accessibility issues flagged by users — something I had never done and felt nervous about because it meant testing with screen readers and changing how interactive elements worked. I spent a few evenings reading the accessibility basics, paired with our UX designer to learn semantic HTML and ARIA roles, and practiced keyboard-only navigation and a screen reader to reproduce the problems. I broke the work into concrete checks (focus order, readable labels, keyboard support), implemented fixes for a modal and form components, and asked QA to run an accessibility checklist I drafted. The changes reduced repeat accessibility bug reports and the UX lead adopted my checklist for future sprints. Personally, the experience shifted how I approach front-end work — I now build components thinking about all users, not just visuals, and I volunteer to review accessibility in pull requests.