As for the question, it is one I'd ask interviewees from time to time. It usually got some good responses. As the one being interviewed, I like this kind of question a lot more than a round of Trivial Pursuit.
My real answer is having to support a poorly designed and written legacy system. A system where there was huge chunks of redundant code in an outdated and obscure language mixed with an awful database design. Unit testing was almost impossible. There was no functional test environment and no budget to create one so all changes had to be tested in production. The system was incredibly fragile, a change here would cause unexpected problems there. It should have been replaced a decade ago but it still limps on.
But, since that story focuses on a huge negative, I rarely mention it.
Instead, I focus on a complex scheduling application where I used a facade pattern in a web service to integrate and simplify interaction between 5 different database systems. This involved coordinating between several different systems, using threads and callback and so forth. I also wrote the front end, creating a scheduling time block grid.
I try to relate this back to the position I'm applying for so that it sounds like it would be similar to what they're wanting to do or have done themselves.
Thanks for sharing with such detail :D. It's just the kind of perspective I was seeking. I really like how you recognize not to focus on a negative story to reflect upon with an interviewer, I think it's easier to overlook something like that in a high pressure environment.
Ok, so that experience definitely gives an impression of "ok this guy has seen things and worked on enterprise-y apps" without necessarily having to say "hey, I built the whole thing start to finish" 🤔 - because well, let's face it - most workplaces have teams in place.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.