My favorite programming interview questions

It’s common for companies to have a set of technical questions to perform at programming interviews. We may have a set of generic questions, and also questions specific to the language and technologies we use. Having this script of questions is great for having a common ground between different interviews. If we always ask the same questions, it’s easier to compare candidate performances.

With time I’ve came up with my own set of questions. I have a different style. I favour open questions that let the candidates talk freely about their past experiences.

Software engineering KPIs

What would be a good set of key performance indicators for engineering projects and teams? We’re usually accustomed to see KPIs in a business context, and more used by sales, marketing, product squads. But I believe that the exercise of figuring out KPIs is very important. We’re talking about measuring our performance with simple numbers. Is that possible at all?

If we do figure it out, we’d have some kind of software development metrics dashboard. That would have value by itself. We could see were we’re at, we’re we going and the impact or correlation between KPIs,

But it’s very difficult to measure productivity in software engineering teams. Having the work mostly being creative makes the modeling it as numbers pretty tricky. We may look to KPIs that only reflect volume, but neglect to consider added value. The typical lines of code metric comes to mind.

Decision log: result based APIs

I usually advocate for building APIs that have the top level service classes/functions returning results. It’s common to return a value directly, but many times I feel the necessity of returning more things. It can be an error when something goes wrong, or even additional metadata that add information to the returned value.

This is a decision log that discuss if we should use this technique.

Developer speed versus team speed

I was always very focused on speed and productivity, but mostly from my point of view. Developing features fast and with quality is still one of my favorite problems to solve. But now that I’m more of a manager, I have to deal with new insights. How can I balance developers that are so fast that they slow the team down?

Usually developers frown on processes. They want to be left alone working on their tasks and concentrated. And indeed that’s the best use of their time. The problems arise when we have several developer threads working in parallel and we need to sync them. So a new favorite problem to solve is how to make developers productive individually while potentiating the team and the overall output of the team. But for that… I need processes.

Suffering as a source of progress

While reading Atomic Habits I stumbled on a phrase that got me thinking on my goals as a team leader: “Suffering is the source of progress.”

I’ve worked on several projects where the suffering was seen as usual. It was so usual that the developers didn’t even question it at all. I still see it happening to this day even on healthy teams and projects. There’s this thing that happens that causes suffering somehow, but we’re all so used to it that we just take it as is without questioning.