loading...

What was your most challenging experience in a project you’ve worked on, and why?

aizkhaj profile image Aizaz Khaja ・1 min read

Yesterday I had a conversation with a tech recruiter and I failed to appropriately demonstrate how I can work on/architect web apps too and am more than just a glorified website builder. (Preparation makes perfect, I suppose 🤷🏽‍♂️).

I failed.

One question in particular that stuck with me was what I’ve posed in the title. I failed to come up with a more interesting experience working on one of my projects in a quick witted manner and choked up something along the lines of “um, authentication. I had to build one from scratch instead of using oAuth or sessions...”

For the record, I’m not a super experienced dev, but I’d like to think I have enough chops to creatively solve problems with code. For example, one “experience” project I developed was a markdown wikis app with authentication, authorization, building features particular to a premium user and then Stripe subscription payments integrated (do I get some points for third party API integration?). Not to mention database design experiences in both SQL and NoSQL.

At this point in my job search, I honestly can’t tell if that’s beginner level stuff or what you’d call intermediate (these terms are so relative it’s nuts. But there’s gotta be an average boundary to determine what’s beginner and what’s intermediate?)

So my dear reader; If you’re still here I’d like to ask you:

What was your most challenging experience in a project you’ve worked on, and why?

P.S. hit me up if you know someone looking for a JavaScript or Node/React developer. Thanks! 🤓

Posted on by:

aizkhaj profile

Aizaz Khaja

@aizkhaj

Backend developer with some frontend skills. I enjoy working in JavaScript but have been getting more hyped on TypeScript and loving it!

Discussion

markdown guide
 

I'm a senior level full stack (Microsoft) developer in the middle of a job search too and phone interviews almost always throw me off my game. I really dislike them. They'll almost always ask about something I haven't worked with recently (like authorization) or focus in on some little nuance with C#, Javascript or SQL that I've not used that much or at all.

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.

 

Anytime I hear questions like "most challenging blah" I interpret it to mean "an interesting and challening blah". Don't get caught up in trying to think about the actual most challenging thing you did, just pick something that was difficult. Pick something you succeeded at in the end, and make sure it isn't boring: interesting is a key word here.

When I ask questions I'm listening for specific details as well. Describing in brief the full stack of an app isn't interesting. Pick a hard part and say what you did.

For example, when asked said question, I could respond:

I worked on a financial trading system. We had several computers spread across various exchanges and needed to coordinate messages on multiple networks. The user needed a UI that responded quickly with many instruments open.

yawn says nothing, compare to:

On a finance project we had a real problem with writing tests. Multiple networks, and erratic markets, lead to some absolutely crazy scenarios. I had no choice but to somehow simulate this world in our tests. This lead to a YAML+M4 driven domain specific language that could create exchanges, behave as a user, and simulate acausal network activity (yes, that actually happened!).

 

M4, wow! (I never met a macro I didn't like.)

 

That's an interesting question, Aizaz!

In my opinion, the seniority of a developer is not only about the complexity of the system or the code, but also about:

  • user-centric thinking;
  • ability to make trade-offs and know the reasons for them;
  • ability to clearly explain the above.

The most challenging and the most interesting project in my life so far was a scalable distributed GIS-system.
Check out my set of articles about the architecture and our process:
smartpuffin.com/tag/fiji/
Note how I focus on the users, their requirements, and our approach to problem-solving.

(Working with users is, I believe, one of the most important and underestimated skills for a developer.)

So if I were describing my most challenging project, I would start my explanation with describing a task I was solving. I.e., why did I have to implement authorization myself? What was my thought process that led me to it? From defining the requirement to eliminating the possibility of using existing APIs to implementing to fixing bugs to success (or failure and learning). That would make a great story, show how I am involved in all aspects of development, and leave room to asking questions about every stage of the project.

Hope this was at least a bit helpful! I think I need to write an article about it:)

 

Aaand here you go with the article:
dev.to/ice_lenor/how-to-answer-the...

Again, really hope it helps!

 

Elena,

Thank you for sharing your thoughts! I love how approachable this becomes for a more junior developer like myself.

It’s interesting because it works for a dev of any level. Sparks my thoughts on how I should review some of my apps and note down the what’s, why’s and the challenging aspects more so that I can share a good story.

Personally, as someone with the business analyst background, I can totally understand the skill and ability to walk through your thoughts depending on the target audience.

Going to use this for another phone screening tomorrow 🔥

Cheers!

Hi Aizaz,
Good luck on your interview tomorrow!

I think this should help more junior developers as well. Of course, my advice is about framing the interview discussion, but maybe it could even help someone to start thinking of their next projects in these terms and approach the implementation accordingly.

Thank you!