Explain how you managed a project with strict deadlines

In my last internship, I worked on a reporting feature that needed to be included in a customer demo at the end of the sprint, so the date was fixed. My part was building the data display and connecting it to an existing service, and early on I realized one of the data fields behaved differently than I expected. I raised that quickly to my mentor, suggested a simpler display for the first version, and we agreed to defer a couple of lower-value formatting details so the core flow would work reliably. I broke my work into a few small checkpoints, shared progress each day, and asked for an early code review on the riskier parts instead of waiting until the end. We finished in time for the demo, and the feature worked well enough that the team kept most of that version for the actual release.

At my first full-time role I was the sole engineer assigned to connect our app to a third-party shipping-rate API for a partner launch that had a hard go-live date. Early in development I found the API sometimes timed out and returned incomplete data, which would have caused a poor user experience if released as-is. I proposed and built a simple local cache and a fallback that used our previous default rates, added a feature flag so we could turn the new integration on gradually, and wrote a handful of focused tests that covered the failure cases. I kept the product manager and QA updated daily, asked QA to prioritize a few critical scenarios, and agreed with ops on a short deployment window and a rollback plan. We pushed the integration on schedule, the fallback prevented customer-impacting errors during peak traffic, and we later scheduled a follow-up task to harden retry logic once the deadline pressure subsided.