Please share an instance where you made a big mistake at work.

Question

Anonymous · Accepted Answer

I need to discuss a time when conflicts arose with the cross-functional security
team due to a mistake on my part. The security process usually takes two to
three months, depending on the project size. When starting a new project, we
initiate a conversation with the security team. We present our high-level
design, get approval, and then proceed with the low-level implementation. Once
our APIs are implemented in pre-production, we work with the team to get them
tested, which is the final step for security approval.

During the security review, we made an important decision that the security team
had concerns about. Although I was able to convince them of the benefits of our
decision, when we were later doing testing, they raised the same concern about
duplicating data without a paper trail to support our prior agreement.

Realizing my mistake, I immediately scheduled a meeting, discussed the past
trade-off points, and got the approval. To prevent similar issues in the future,
I created a framework for working with cross-functional teams. This framework
ensures that all agreements and sign-offs have a paper trail and email
confirmation from the relevant stakeholders. I also began recording meetings and
ensuring all important details are documented for clarity.

When working with the same cross-functional security team on my next project, I
followed this framework. As a result, everything went smoothly, and the security
manager appreciated the improved communication. Due to these improvements, we
completed the entire project a day ahead of schedule. Thank you.

Anonymous · Answer

One significant mistake I made early in my career at xxx involved a
misconfiguration in a testbed network. I was deploying a new routing policy for
our 5G core simulation and accidentally applied it to the production testing
subnet instead of the isolated simulation subnet. As a result, several
integration tests failed and the team lost about half a day of work.

I immediately took responsibility, analyzed the logs, and identified that the
error came from a missing namespace flag in my deployment script. I restored the
previous configuration, informed the team, and then added a validation step and
environment check into our automation pipeline to prevent similar issues.

The incident taught me two key lessons: first, never assume the target
environment—always verify before execution; and second, mistakes are valuable
only if you turn them into a process improvement. Since then, I’ve implemented
pre-deployment checks and peer reviews in every project I lead, which has
significantly reduced configuration errors.

Anonymous · Answer

I managed a team with 2 Senior Engineers who disagreed on the approach to
solving a big problem. I had the entire time discuss the solutions and determine
which one was a stronger proposal. Both Senior Engineers were able to present
their solutions and the team hashed out the pros and cons and came to a
conclusion. It worked so well that when this decision was challenged outside the
team the Senior Engineer who did not win the discussion stood up and defended
the decision like it was his own

Anonymous · Answer

I was managing organization wide restructuring program where goal was to map all
resources with their delivery accounts to keep a track of account’s PnL and
manage capability as cost centre. We also intended to design KRA and KPIs for
each individual level to make our Performance Assessment data driven and
transparent. This was a big change at employee level at professional and
emotional level too. It meant changes in their reporting structures, extra
reporting and performance management by all managers, clear KPIs alignment and
selection.
Planning Level: We identified all the major business account heads, capability
and other function head and organized a communication platform to make them
aware and comfortable with the changes. We undertook their inputs on pros and
cons and some caution to be exercised
Execution Level: We started executing these changes with L0 level employees and
moved up to leadership team. Along the way we encountered some risks and outlier
conditions to be managed.
Communication Strategy: We worked with all business and functional heads on our
communication strategy to reach out to all the employees. Head multiple events
and workshops to discuss the changes.
Data Platform changes: Evaluated all the data platform changes required and
planned a phased out approach to bring those changes in the system as well.
However, when we were about to reach closure of this program, I realized that I
have made a big mistake of readiness of our existing platforms to support all
the changes required and existing data integrity. It really took a toll on
everyone involved to clear up data accuracy before the changes could be
introduced.

Anonymous · Answer

One time I noticed that all of the items were past the expiration date. This was
a huge safety issue and decided to toss them away. About 2 dozens items were
tossed. It turns out, they weren’t expired and I had read the date incorrectly.
Luckily, someone checked the bag and returned the stock. From this, I have
learned to double with someone else before making a big decision.

Anonymous · Answer

I was working as a product designer in a SaaS platform, and I was the only
designer there and the ux culture before me was really poor. The platform was on
a process of being redesign using new technologies and a new framework that
allowed more user interaction and moving from a old dashboard with no friendly
usability to a self-service dashboard creation improvement.

So basically I need to work on the new dashboard experience while assissting to
any task related to the old dashboard maintainance.

I didn't know how to stablish limits in my work schedule, and everytime. they
asked me to attach a specific task then I'll said ok, create the ticket and jira
and cover ir, but then I was overload with tasks, no priorities defined,
everything was critical, and I was struggeling in how to communicate it to my
manager. I've learn that I can't work in more that 3 priorities by week, that
It's ok to say no and communicate clearly with desicion makers whats happening.

Anonymous · Answer

I was helping a dev fixing a bug that caused a blocker. I ended up making
another mistake on top of his bug and I felt terrible about it. Throughout the
whole process, my director was very calm and supportive. He solely focused on
solving the problem at hand and minimizing customer impact. We had an internal
RCA meeting afterward and put process in place to avoid this issue in the
future. I learned that it's ok to make mistake, we're all human being. It's
important to treat people with dignity and have empathy. It helps build a
supportive and positive working environment.

Anonymous · Answer

In a fix of one of the field where it depends on the country code, I wrote a fix
for millions of records on the 2-character country code, but a few are still
there in DB with 3-character code which was overlooked and due to code freeze in
Nov month it went to escalation for the delta. There is little tolerance for
escalation in our org. Although the severity is minimal but priority wise its
very important. With this lesson connected with different stakeholders next time
although how welll I know the system always analyze PROD data.

Please share an instance where you made a big mistake at work.

Practice this question with AI

Go Premium

Community Answers

Unlock Full Access

Unlock Full Access

Unlock Full Access

Unlock Full Access

Unlock Full Access

Unlock Full Access

Unlock Full Access

Unlock Full Access

Practice More Questions