Question: Tell me about a time you came up with a simpler solution.
Answer: I was working on a project for an insurance company. My primary responsibility was to create Android and iOS applications; however, the client wanted to have a Web version as well.

I had no prior experience building Web applications and was following tutorials and sample code snippets to build the POC. Eventually, the POC was delivered and put to production as a huge monolithic class with many functionalities.

Later on, the client asked for more features, but the Web application was not easily extensible due to poor structuring. A co-worker and I worked on better modularizing the application to better follow the MVC pattern, which allowed us to build more features to deliver to the client.

Q: Why was it shipped in poor condition the first time?
A: I was just learning and following simple guidelines.

Q: What made you decide to revisit and re-design?
A: Some new features were really difficult to do with the old monolithic class. Modularizing the application seemed like the better choice.

Q: How were you able to re-design + deliver on time?
A: There wasn’t really any time pressure – we were given the time we said we needed to re-write the application.

Q: Were there additional gains due to the re-design? Ops? Maintenance?
A: It gave me an opportunity to better understand how the system works under the hood like request routing.


Competency asserted: Invent & Simplify
Job title: Software Development Engineer (SDE II)
Interviewer role: Software Development Engineer (SDE III)

Vote: 👎

I asked the candidate about a time when he simplified an existing solution for the better. He talked about a time when he restructured a piece of old code he rolled out to production for better extensibility. The example isn’t negative. It aligns more with improving his work/tasks, which falls below the bar in terms of impact. Instead of quantifying this as Invent & Simplify, it raises concerns for not insisting on high standards as modularizing a monolithic class seems like a fairly standard practice we should always be following as software engineers.

Why Insist on Highest Standards? I can understand, at times, building a POC leads one to take shortcuts and skip best practices. Still, I question how one allows such a product to ship to production without a plan to reduce the tech debt and address fundamental issues after launch.


In this example, it’s not clear if the candidate tried to push back on having his proof of concept deployed to prod or not. I worked in consulting for about five years, and this is something that happened many times without being in control of developers. Product Owners, Product Managers, Customers make those decisions for devs most of the time. If you have a similar experience, make sure to mention if you stood against this, your concerns, your arguments, the tradeoffs, short term impact vs long term impact etc. Thinking long term is what distinguishes a more senior engineer from someone with less experience.

Leave a Reply