Software Engineering IQ

Ahmad Hasan Siregar

23 Sep 2025 — 2 min read

I started thinking about what is the "single" trait that will guarantee our new hire will be a good hire when our team needed to find a frontend engineer, after we just ended a previous position caused by a mismatched role.

A good hire, I defined as somebody who will ramp-up, contribute meaningfully, and continue to grow in the team.

One thing that stuck to me is that a candidate should be "smart". But, in hiring, I should be able to have an objective criteria that's applied across the candidates. So I began the journey of delving deep of what's smart in the context of software engineering.

I found that measuring just IQ is not a comprehensive set of measurements. Just being smart is not enough to be a good software engineer. So the smartness here needs to be contextualized in software engineering. But, it got close to home to what people understood a smart person is. So I just stuck with the term but slap-on the software engineering prefix, hence software engineering IQ.

We're actually looking for traits that a person demonstrates. To be more precise, a set of traits. After doing personal research and thinking, I decided the traits that embodies a smart engineer boils down to 3 dimensions:

Problem solving
Strong mental model capacity
Sound logic

Mental model is the capability to represent a reality internally in the brain which entails being able to conduct mental gymnastic on those representation. The analogy I frequently use is given a box of 6 sides and 6 colors, if I give you a sequence of flips and I ask you what's the color on the top side, that's the mental capabilities.

A practical example why this matters is, says one of the upstream service dependency failed which cause our service to fail as well. We need to be able to reason quickly how does that service failure cause our outage.

This is why I think a lot of people misunderstand "Leetcode" question used in the interviews. Though I hate the term "Leetcode" as a replacement for data structures and algorithm questions.

I think, the number one reason why people hate Leetcode in interview setting is because of lazy interviews which only took question(s) from the bank, threw it to candidates, and testing whether they can solve the problem or not. Similar to "can a monkey climb?"

TODO: fill the rest

Investing in People (in progress...)

Investing in people is more valuable than investing in systems or processes. A lesson learned that I try to apply more consciously. When I use the term "invest", I mean in the context of investing one's time, effort, and energy to a particalular undertaking in the

Outsourcing Mentorship to Reddit r/ExperiencedDevs

The story began when I was trying to validate my ideas for a set of problems that I'm uncertain of. Hence, I was looking for a mentor, somebody I can look up to, who can help me find answers to my questions. Unfortunately, in my organization, I did

Why Smaller, Stacked PRs Work (even with merge conflicts!)

Starts with concrete, tactical, and practical point of discussion. See at the bottom for foundational principles and values. Recently our team started making smaller PRs and stacking them. Here is my reasoning on justifying why smaller PRs is better than a big(ger) one even with several administrative overheads as

High Floor, High Ceiling Candidates

When our team was hiring, I was thinking types of good candidates. I defined two dimensions to judge a candidate. The floor and the ceiling. The floor is the existing cumulative experience the candidate has. The ceiling is the future potential of growth the candidate has. A fresher from the

Read more

Investing in People (in progress...)

Outsourcing Mentorship to Reddit r/ExperiencedDevs

Why Smaller, Stacked PRs Work (even with merge conflicts!)

High Floor, High Ceiling Candidates