3 interview examples to check that developer can understand business

Yurii Drozd
5 min readSep 2, 2020

--

There are many checklists to assess developer’s hard skills, design patterns, data structures and programming language syntax.

However, being able to write efficient, readable and structured code is not enough for software engineers today. They should be capable of understanding problems that needs to be solved, product owners, business stakeholders and their customers.

As a CEO of a software development company, over the past couple years I’ve conducted hundreds of different interviews, technical and behavioral, and was surprised to learn that even candidates that are applying for Senior Engineer level, often fail to understand business contexts. I should note here, that I saw this being more of a problem for developers from Eastern Europe, where product companies employ only like 5% of all IT folks, and less of an issue for North Americans, who tend to dive deeper to the roots of the problem. As a result, we added couple more benchmarks to our interview process:

  • Are candidates capable of understanding business model, monetization, how does specific product contribute to making business successful, i.e their abilities to understand business owners.
  • Can they select most useful features of the product, see future of the product, come up with ideas, i.e their abilities to understand product owners.
  • Can they propose alternative ways of achieving the same goal, i.e their abilities to understand end users.
  • Can candidates ask the right questions to get to the right answer.

And don’t get me wrong, I’m not expecting candidates to take product owner responsibility if the company does not have one, or show excellent entrepreneurship skills and grow business instead of business devs or owners. What I’m looking for is the ability to put themselves on the other side of software engineering and understand that:

  • the code they are writing is needed for a reason.
  • it does not matter when the code is great, but it’s an overkill for a task.

To test those capabilities, I’ve come up with few case-based questions. Usually I use one or two of them at a single interview, spending 7–10 minutes on average. I’ve also included some possible answers, but there are no right answers here since questions are open-ended and conversation can drive them to totally different results.

Case 1 — for mobile/front-end/full-stack devs

Imagine an app that gives users the ability to find restaurants nearby, see the menu, opening hours and etc.

Q: how would MVP for such a product look like?
A: users should be able to open the app, be auto-located or provide their zip code, then see the list of restaurants on the screen, be able to see details of the restaurant and get transferred to Maps for directions.

Q: to show restaurants on UI, would you choose list or map view?
A: from a user perspective, a map is better than a list, but a list is cheaper to build. But at some point we will likely have both.

Q: how or where can we gather restaurant data for this app? Would it be better to use open databases, or build your own system to gather this info from restaurants owners?
A: 3rd party data can be used for MVP or long-term if the business model is not about the restaurant data but something else (booking, reviews etc.) If the business model is about having relevant, up-to-date restaurant data, then it’s better to start with limited locations but build relationships with restaurant owners, create sign up flow etc.

Case 2 — for full-stack/backend devs

Imagine a SAAS product: SMS campaign management tool, where the operator has to add recipients into the system, then build up a sequence of messages and schedule execution of the campaign.

Q: What would be the easiest way to input recipients into the system? What functionality is needed to allow input of thousands of recipients into the system?
A: Creating them one-by-one will be problematic. We can start from simple CSV upload, using third-party libraries to ease the mapping and data validation. Later we may need to integrate with customer’s CRM systems or build API so they can push data to our system.

Q: What monetization could we have for such a product?
A: It can be a fixed fee per SMS, added on top of cost of SMS. The more SMS are sent, the bigger would be the profit of the company. The company could also provide additional services, like business intelligence and insights, charge for custom integrations etc.

Case 3 — for front-end/full-stack devs

Imagine a platform that gives some operation teams the functionality to create text-based, image or video content, that their company will use for advertising. The app has functionality to upload text or media and put them on a template. These units can be previewed and pushed to the server for processing.

Q: is designer needed to create mocks for such a system?
A: any front-end developer would love to have professional mocks built, but for systems that are used internally, it is not always the case. Moreover, there should be an understanding that main requirements for internal systems are to be effective, robust and performant. UX in this case is more important than UI.

Q: a product owner asks you to build an image editor, but you know that it will take months of work. Can you think of an alternative?
A: think about the use cases for this editor and make sure that product understands the effort to be put into it. Maybe, using something as simple as Paint and having the upload functionality would do the job.

Q: you’re asked to add the functionality of changing the font family on the template, but once you start working on this task, it appears that the only existing font is hard-coded and you’ll need to refactor a large piece of code to make it configurable. What would you do?
A: it is important to understand that when developers can’t hit their original estimates or their changes require broad testing and impose risks, they should raise this to their managers and make sure that the business value of the feature is worth the effort/risk.

--

--