I'd like to hear about a time when you failed at work.

Question

Anonymous · Accepted Answer

Situation: I was tasked with building a prototype of our DIGITS app on the
Hololens 2, a mixed-reality device. This was new territory for us, and I was
excited to explore how our telephony experience could translate to AR.

Task: My goal was to create a working demo that integrated our telephony SDK
into the Hololens experience using Unity and C#. I had about two weeks to get
something functional enough to evaluate viability.

Action: I dove deep into learning Unity3D and Hololens development from scratch,
and spent considerable time trying to bridge our SDK — which was built in C++/C#
— with the Hololens platform. Despite my efforts, I couldn’t get reliable
communication between Unity and our SDK.

Rather than give up, I pivoted and simplified the approach by porting our
existing Windows desktop app into the Hololens environment. This at least
allowed for basic app functionality and UI testing. Through further research and
prototyping, I discovered a key platform limitation: Hololens did not support
background notifications, meaning incoming calls couldn’t be surfaced while
another app was in use.

Result: I documented everything, demoed the prototype to my manager, and
recommended that we pause development until the Hololens platform evolved. While
I didn’t deliver the full solution I set out to build, I learned a ton, clearly
communicated risks, and saved the team from investing more time into a blocked
path. I see this as a failure in the original goal, but a success in terms of
ownership, problem-solving, and protecting resources.

Anonymous · Answer

During the beginning stage of a software design team project, I failed in terms
of solid communication with my peers.
In the beginning, I laid out our plan for developing the front end and even
assigned tasks to my peers so that we could tackle each one by one efficiently.
As the deadline closed in for the front end portion, none of my team did any
work, so I took it upon myself to do the rest of the work.
After submitting the front end, I looked back and realized I was wrong. I
shouldn’t have assumed my peers wouldn’t do any work. When situations like that
occur, the right thing to do is to go to your peer and ask “Hey, have you made
any progress on [so and so]? If you need any help or feel lost, I’m here. We can
work together to tackle the problem.”
this was the right approach. It shows your peers that you care not only for
delivering a solid product, but also showing that you care for their effort as
well. This approach worked wonders and for the remaining stages of the project
we worked together with great chemistry. As a team, I believe everyone should
put in their efforts even if one member lacks more in skill than other.
Collaboration and communication leads to the best results for team projects and
it’s never safe to assume that someone will not do their work.

Anonymous · Answer

during my first internship i volunteered and was tasked with researching options
for a new framework for our graph component.
i researched and found a certain option which was more expensive than the others
but i made a case it had much more needed features and would be worth it, using
more of the excitement of being given autonomy and a chance to prove myself,
than actually taking everything into consideration and tools like a swot
analysis. after much resources and time and money poured into this we realised
the framework wasn't compatible with the version of our aws deployment service
we were using and would not be able to use the framework without rehauling every
other component. altough a big failure, it taught me the responsibility that
comes with these types of tasks and the importance of careful research, and
being open with the team.

Anonymous · Answer

* There was a time the team was developed a search optimization capbility for
   users based on given requirements by product manager, so it could add more
   search filters for faster accessibility so . I asked the team to create demo
   on dev environment and to show customer, in order to make sure it is aligned
   with users need. I scheduled the meeting and we showed the demo, suddenly we
   undrestood all the usecase were not covered by program manager which lead to
   poor design it means some of the file type were not identified by specific
   locations. And that wasn't a feature for customer. On the other side we
   didn't have enough time. Since we needed to release this feature on time and
   as manula accessibility got block the program
 * 
 * So I pushed the product manager to schedule meeting with diverse useres to
   make sure to capture diverse uses cases. I put together team and we discussed
   on options and tried reestimate we identified that by one more api resource
   we can have this feature on time. So I escalae that to leadership since the
   timeline was crucial for them, they assign api resource from india Lesson
   learned: 25 percent

I'd like to hear about a time when you failed at work.

Practice this question with AI

Go Premium

Practice More Questions

Community Answers

Unlock Community Insights

Unlock Community Insights

Unlock Community Insights

Unlock Community Insights

Stop Winging It. Start Using Frameworks.