I Knew the Answer Until Someone Asked Me Differently: How I’m Training Myself to Think Like an Engineer | Abdullah Rasheed | Software Engineer
Software Engineering
I Knew the Answer Until Someone Asked Me Differently: How I’m Training Myself to Think Like an Engineer
I noticed an uncomfortable weakness in myself: I could understand a concept, yet struggle when the same idea appeared inside an unfamiliar question. Here’s how I’m changing the way I practice problem solving, critical thinking and technical reasoning.
Abdullah Rasheed | Software Engineer· 10 min read
There is a particular kind of frustration I have experienced more than once at university.
I study the subject properly. I comprehend the lecture. I am able to understand the examples. When I get a familiar problem, then I will most likely be able to solve it. At times I may even be able to confidently explain the concept during revision. Someone asks me the same question but in a different way.
The words change. The familiar clues vanish. The problem may contain both concepts at once, or someone may ask me to explain why I selected that particular answer and not just give the answer.
Suddenly my confidence level goes down.
What follows is the frustrating bit. The solution is explained to me, and I discover that:
I knew almost everything that was required to answer this.
"Why then could I not?"
This one is more bothering me now than the ignorance of some knowledge.
Since, if I am ignorant about the concept, I will find the solution by just learning it.
But what do I do if I have the knowledge in my head but cannot utilize it when the situation presents itself to me in a different form?
This is a different kind of weakness.
I believe that I have been cultivating it for the wrong years now."
I Was Better at Recognizing Answers Than Producing Them
My previous educational experience provided me with a predictable cycle of learning.
I studied the content. I saw what kind of questions were asked before. I memorized or comprehended the answer. And the exam asked me something so similar that I knew which answer should be there. Such a system makes you believe that you know everything. The university made me realize the flaw of such an approach.
In the university setting, particularly in software engineering, the term is known to you but the question itself is completely new to you. The lecturer gives you a different situation, puts additional constraints or takes away some obvious cue.
Now recognition isn't enough.
You need to retrieve what you know, identify what part of it matters, ignore what doesn't, connect several ideas together and construct an answer that you may never have rehearsed before.
That is a very different activity from remembering a definition.
And software engineering makes this difference impossible to avoid.
Real Problems Don't Tell You Which Chapter They Belong To
I know the topic immediately. My brain opens the correct drawer.
But imagine somebody instead tells me:
"Our system was okay when there were just 20,000 records. Now we have millions in one table and queries that are filtered by tenant_id and created_at are getting slower. Where would you begin?"
Nobody said index. Now I have to recognize that something I learned earlier might be relevant. The same thing happens with security.
Real software doesn't work like chapters in a textbook.
A client doesn't tell me which data structure to use. A production error doesn't specify which networking concept I'm missing. An architectural problem doesn't conveniently tell me that today's solution involves caching, database normalization or asynchronous processing.
The first part of solving the problem is recognizing what kind of problem it actually is.
I think this is the gap I had underestimated.
Knowledge and Thinking Are Not the Same Skill
Previously, when talking about my efforts to quit my pursuit of tech stacks, I discussed the idea of directing my focus from the process of accumulating tools to the process of becoming a better problem solver.
It raises an obvious follow-up question.
What does it even mean to become a better problem solver?
It certainly cannot be about knowing more things. Knowledge is incredibly valuable. I can hardly reason about anything about databases without knowing anything about databases. Critical thinking won't conjure up all necessary technical knowledge by its own.
But knowledge is what I think about; not necessarily the thinking itself.
National Association of Colleges and Employers describes critical thinking as an ability to understand the situation, analyze the available information logically, make decisions, solve problems, and explain the process of reaching those decisions. In their 2026 employer research, critical thinking was one of the skills considered most important by employers but with still some room for improvement.
That definition helped me because it makes critical thinking feel much less mysterious. It isn't some personality trait where certain people are simply born “logical.” It is what happens between receiving information and deciding what to do with it.
And that can be practiced.
My Real Problem Was the Type of Practice
My first instinct was: Fine, then I just need more practice.
That's partly true.
But there is an important catch.
If I do the same type of problem twenty times, I will probably be very proficient at recognizing the type of problem. However, this does not always imply that I have become equally proficient at making use of my proficiency elsewhere.
This is how the American Psychological Association defines this difference. The learning and problem-solving guidelines of the APA state that transfer is not always automatic. Practice can be made increasingly effective for transfer when the problems that are being learned are structurally similar but different superficially, thus requiring the learner to make distinctions between what is important and what isn't.
That immediately changed what “practice more” meant to me.
When I am trying to learn something, maybe I should not just do five problems which nearly tell me the answer to the problem itself. I want the concept to be hidden.
If I know about caching, can I see a scenario where caching could be useful without being told about it?
If I know about concurrency, can I detect a race condition within a scenario?
If I know about normalization of databases, can I see a terrible data model and know why there will be problems?
The Question I Want to Start Asking Is “Why?”
Another weakness I've noticed appears when I actually have the correct answer.
Someone asks what technology I would use.
I answer.
Then they ask:
Why?
I explain.
Then:
Why not the alternative?
That second question is where things become interesting.
It's easy to say:
“I'd use PostgreSQL.”
It is significantly more complicated to justify why the use of PostgreSQL suits the specific system, what are the underlying assumptions for such a choice, what trade-offs I make and when I could do things differently.
The same thing occurs during the presentation.
You may remember your architecture slide word by word. But someone will ask you why you placed a specific part of it there, why didn't you use another approach or what would be the consequences if some requirement changed.
The presentation suddenly shifts from remembering the text of the slide to justifying it.
I used to consider such situations communication issues primarily.
Sometimes they are.
But now I understand that communication reveals the quality of thinking beneath it.
If my thought process was based on the deep understanding of the problem, then the explanation becomes simpler. But if my knowledge is mostly "it's done this way in the tutorial," then one additional why? may completely break the entire answer.
It is good feedback.
Not comfortable, but still good feedback.
This Is Also Why Unexpected Questions Feel So Difficult
I used to think being good at an unexpected question meant somehow preparing for more possible questions.
Prepare question A.
Prepare question B.
Prepare question C.
Maybe if I prepare enough of them, eventually nothing will surprise me.
That strategy doesn't scale very well.
There are infinite ways to change a problem.
What I actually need is a process that still works after the question surprises me.
When I see something unfamiliar now, I'm trying not to immediately search for the answer. First I want to slow the problem down.
The Industry Seems to Want the Same Thing
It’s not just relevant in university examinations.
According to HackerRank’s 2025 Developer Skills Report, 96% of the interviewed developers felt that problem solving was more important than rote learning in technical assessment. However, at the same time, 66% of them preferred being evaluated via practical scenarios rather than the current ones, which they felt focused too much on preparing candidates for algorithmic problems.
This doesn’t mean that algorithms are irrelevant.
Explaining Out Loud Is Becoming Part of My Practice
Something that I particularly would like to enhance is verbal responses.
It seems to me that in some cases my written knowledge is better than my verbal response.
The fact is when I have time to write down, I can put together the parts. While when somebody asks suddenly, my ideas may come faster than I can organize them.
Therefore I start to think of verbal explanation as a separate process which deserves practice.
After coming up with an idea, I can ask myself:
How do I explain this to my classmate?
How do I justify this to my professor?
How do I explain this decision to my customer who does not understand technical terms?
Is it possible for me to explain this without the use of any jargon?
If it is impossible for me to explain something without using the exact definition that I know, then in most cases it means that I need to dig deeper.
I don't need every answer to sound perfect.
I want the reasoning to survive outside my notes.
I'm Trying to Practice the Problem, Not the Answer
Therefore, my learning process is gradually shifting.
Once I learn a particular idea, I am working on avoiding thinking about it as "learned" merely because I can understand the examples.
I would like to approach it from various angles. Solve a simple problem first, and then change some constraints. Explain my solution. Argue against it. Relate to something I have learned before. Recognize the idea as part of an actual system. And sometimes I would like to purposely leave myself with a problem before seeking an explanation.
Not for too long.
Getting stuck for three hours just to avoid showing one's ignorance is also not very smart.
But long enough to make my brain engage into decomposition and reasoning prior to substituting this process with somebody else's solution.
There is a difference between productive struggle and confusion.
I am working on developing the ability to tell the difference.
The Test I'm Starting to Use
I still want to know the definitions.
I still want strong fundamentals.
I still need technical knowledge.
But after learning something, I'm trying to stop ending with:
“Do I know this?”
That's too easy to answer while the book is open.
The better question is:
“Could I recognize where this knowledge applies if nobody told me what topic the question belongs to?”
And then another:
“Could I explain why I chose this answer if somebody challenged me?”
If I can do both, I'm much closer to understanding the concept in a way that survives outside an exam.
If I can't, that's okay too.
At least now I know what I need to practice.
Because the goal isn't to prepare myself for every unexpected question.
That's impossible.
The goal is to reach a point where an unexpected question no longer means I have nothing to do.
I may not know the answer immediately.
But I want to know how to think my way toward one.
