I've been getting this question a lot lately in interviews, and am having trouble coming up with something. Either it's imposter syndrome and I think that nothing I've worked on was challenging, or I really haven't.<p>I'm wondering what other people would answer for this question, and how much detail would you give?<p>I'm specifically asking this question in a Software Engineering/Programmer context, not that interested in manager type challenges.
My most challenging thing was doing the last rewrite of the child care subsidy management system at our agency. It combined all the bits and pieces I had developed in the last decade, added several new layers of detail (was able to complete all forms and reports) and added depth (historical data tracking). Went from single user app (FoxBase - actually the old version used a distributed-data method so it was multi-user) to Web Based (LAMP) one. Well integrated...<p>There's just a lot to write about it, lots of different challenges and successes. and I could tell stories on those older systems too there are successes and challenges all the time.<p>I think a lot of this is demonstrating experience, interest and problem solving skills, might also touch on communication skills and able to relate technical aspects understandably.
As developers , we grapple with challenges everyday. This is the reason I chose this as a direction in life rather than just a profession. What one thinks (as a developer in my opinion) was the most challenging problem today would certainly be overshadowed by something even more formidable tomorrow. As far as details are concerned , that really depends. I say quote the challenge you could rate as the highest, and elaborate on how you went about dealing with it and coming out with a solution and making that particular module or feature work. Not all challenges get dealt with elegantly, most are just last minute bug-fixes (from my experience) to ship the code / feature to production and does lead to code that might not make us feel too proud about later on. So think it through choose the challenge to narrate about wisely and prioritize those with elegant solutions.Quick-fixes are not always bad if they serve the purpose to fix bad / buggy code. As for the main points on how to begin or what to highlight:
1. What was the challenge (a brief description)?
2. What were your foreseeable possible solutions (There are always multiple approaches to attack any code problem)?
3. Was there any collaborative brainstorming (sharing your challenges / problems within your team and seeking advice from those who might be able to give you a direction is the way to go) ?
4. What was the solution and how did you implement in the code ( the real "under the hood" details come here)?
5. What did you learn from this challenge ( Bonus Points for this) ?
You need to reframe the question. The interviewer isn't interested in the challenge, they are interested in the how you solved it and <i>why it matters</i>.<p>What is the most <i>meaningful</i> contribution you've made?
This is an easier question to answer if you've ever worked on some open-ended research or problems where the path to the solution is just not known. Those sorts of problems seep into your dreams even when the last thing on your mind is work.<p>However, even if you aren't doing research, good answers are probably found in those scenarios where you are pushing the limits of some particular software framework. Anywhere you have to bend the rules or invent new rules just to accomplish something makes for a good interview story. How detailed you go in your answer depends on how entertained the guy on the other side of the table is.
The interviewer is not actually interested in challenges you faced. He is interested in how to handled them. So simply prepare a good story about how you overcame adversity and solved a huge problem with an extremely intelligent solution. Interviewers love that kind of stuff.