Interviews are meant for companies and possible future employees to get to know each other and assess if they are a fit. Usually employers will lead interviews and try to get a sense of how proficient a candidate is. I have favorite programming interview questions that I use to achieve that goal.

I also have a set of questions that I do whenever I’m on the interviewee side. I’ll want to understand how I can add value to the company and how the company will add value to me, as a professional. If we’re to form an alliance we need to be mindfull of what’s ahead.

I’m mostly experienced in building web apps. And I always wondered how other types of applications are built. Embedded systems, mobile apps, desktop applications, etc. Do we share the same practices? And mostly: what can we learn from other ways of working?

In this interview I try to find out the differences to the AAA game industry by interviewing João Pataca Oliveira.

How are their quality processes? How to they ensure a healthy environment on such a fast pace and competitive area?

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.

(You may also be interested in the questions I like to ask interviewers.)

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.

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.