Search This Blog

July 25, 2020

Can you talk about your most challenging technical problem?


This is a question that is invariably asked in technical interviews. You are perhaps smart enough to answer this question following some template answer by googling for it. This blog post is not intended to help you in that endeavor.

The purpose of this post is to seek genuine answers for that pertinent question. This post is my (strongly) opinionated view of things in the realm of software development on what constitutes a challenge in technical problem. Should you see it this way or otherwise, I would love to see your perspective.

Spoiler Alert : If you have worked with me, this post is likely redundant for you, for we might have discussed and debated about it at length.

My Perspective


More often than not the challenge of cracking technical problems is not just with the technical problem alone in silo. It is compounded by the context that surrounds it making the technical problem what it is -- truly challenging. Don't trust me on this? Take any technical framework from your very favorite programming language and see what problems it proposes to address as solution. 

Invariably it will speak about improving your business value. As technical as it may sound, it is still the  business value delivery that counts in titling your decision making. 

I give you an example or two to begin with leaving the rest as exercise for your thoughtful weekend.

Take AWS Cloud as our first example, they say, "AWS offers reliable, scalable, and inexpensive cloud computing services." where each of "reliable", "scalable" and "inexpensive" is a business challenge manifesting itself as technical problem. AWS introduced cloud to the world and are leading the cloud race. Now here is your question -- if you were tasked to build such cloud platform as a CTO, do you think your challenge is same as that of the tech-team that built AWS Cloud? If your answer is YES, you can't be more wrong.

As second example, go to ,Ruby On Rails website to see how DHH sells the framework -- "Imagine what you could build if you learned Ruby on Rails…". RoR truly is a big framework today and has its pros & cons. And here is your question -- if you were tasked to build a competing framework that is at least as good as RoR, do you think your technical challenge is same as that of RoR team? Would you take the business context into account in weighing your challenge?

In my decade and half or so years of experience, the one thing that I have come to witness is the tech teams treating technical problems in isolation. Guess the consequence? Rift between engineering and product managements. Are we not seeing frequently enough of how the product management "dismisses" engineering teams concerns? Don't we see engineering teams "challenging" product management for their decisions?


In reality though, there are more such technical problems but without a name. Being a first mover has its own set of challenges and advantages. Becoming a competitor by building a competing product has its own set of challenges and advantages. 

Same technical problem present in different contexts (be it business, team, technology, etc) could weight itself as a different challenge with respect to how it is to be tamed. 

This can be well understood by looking inwards into out product development challenges in our teams. We all love stories of others failures, right? So here goes two stories of failures from my experience leaving you with questions to think about the situation, and then possibly connect it with your experience to find answers to those set of questions.

1. Buggy Feature As Show Stopper


I was once in a web development project where our Business Analysts agreed to implement a jazzy feature-rich browser-based text-editor  to incorporate rich-text fields in the forms.  The development team in all their enthusiasm agreed to it at the beginning of the project. The front-end engineer saw it as one time opportunity to build a online rich-text editor that is compatible to all agreed browsers. Days before the first release of the product, the customer hits back at the development team that the rich-text editor is buggy in select set of browsers and that they can't go live this way.

Quiz Time : As an engineering leader, what do you think has gone wrong and why? How would you have averted this kind of situation? When faced with a situation like this how would you go about resolving this issue?

2. Dream Tech And Dreadful Timelines


In one of the product development endeavor for a startup that I had the privilege of leading the team, here is what happened. We acquired the project mid-way through the product development done by another team.  Our management decided to redo the project again with latest front-end tech and proper Agile engineering practices adopted.  For the curious, the reason for re-write was that the old code-base wasn't clean and without test coverage. It chose to adopt ReactJS when it was first announced its 0.01 candidature as open-source and it was raging hot topic in the tech world, because it was from Facebook. ReactJS took a paradigm shift in front-end development from the world of jQuery like libraries. 

And by the way, the management also decided to re-look at other components involved and decided to replace an expensive commercial VOIP solution with a cheaper one that fits business feasibility. The seed team was just 2 developers (including me) and we were supposed to grow the team to 5 quickly in a month's time assuming we could find right talent in a months time. The project started and the team went about hiring for candidates with penchant for front-end development using ReactJS and the efforts went in vain.  We decided to change tact and also hunt for great back-end engineers that could code in Ruby on Rails and could manage to add just one more to the team. We then were quick to hire a few freshers in the hope of training them on the job. We missed the first milestone and then the next. Damn, the time was ticking mercilessly without an iota of sympathy for the situation that the new development team is in. Our client's patience was at its tail's end... 

Quiz Time : As an engineering leader, how do you see this situation? What do you think could have gone wrong? What do you think I or us in leadership team could have done differently to have averted this situation?


Conclusion


Always remember, it is the business the drives technology and not the other way around. So, if you were to talk about your technology solution without the business context, you haven't learned your lessons yet!

No comments:

Post a Comment

Like it or hate it, feel free to share your feedback. Cheers!