I Bombed a Technical Interview With 3Sum. Here's What It Taught Me About Being an Engineer.
A real story about walking into a Flutter interview and getting asked to solve 3Sum first, and what that failure taught me about the difference between writing code and solving problems.
I walked into my first interview with a US-based organization expecting to discuss Flutter. The role was for a Flutter developer, so that was where I expected my experience to matter.
The first question was 3Sum.
I had never solved 3Sum before. I could talk through an approach, but I could not turn that approach into a working implementation. Then 2Sum came up. I had studied it shortly before the interview, but I had not mastered it either. I could not solve that one.
The interview never reached Flutter. Not one Flutter question.
I had spent my time building apps and portfolio projects in the framework I was interviewing for, but I could not get through the problem-solving portion that came first. It was one of the most embarrassing moments of my life.
That failed technical interview taught me something I had avoided for too long: writing code and solving problems are related skills, but they are not the same skill.
Rewinding to How I Learned
When I started learning software engineering, I did learn about data structures. But I learned them at a surface level, usually in whatever programming language I happened to be using at the time.
I knew the names of some structures. I had seen examples. I understood enough to follow along when someone explained a solution. What I had not done was go deeply into the important topics or build real problem-solving ability through repeated practice.
This was before AI coding tools existed. There was no model generating a solution for me or explaining an error on demand. Even then, my attention was on the visible side of learning: building products and creating portfolio projects I could showcase.
That work was not useless. Building products taught me practical skills, and a portfolio gave me evidence of what I could make. The problem was what I had allowed it to replace.
I was not regularly practicing DSA. I was not working through LeetCode problems until I could recognize patterns and implement solutions myself. I was not strengthening the foundations underneath the projects.
My mentor had already been telling me to start learning data structures and algorithms properly. I heard the advice, but I did not understand how soon I would need it. DSA felt like something important for later, while projects felt urgent now.
Then later arrived as an interview invitation.
AI Had Arrived, but It Could Not Prepare Me Retroactively
By the time I got the interview, AI had become widely used in software development. I was just beginning to use it as a helper: to explain things or help me get unstuck.
I was not relying on it to do all my work, but its arrival made one thing clearer. Getting code onto a screen was becoming easier. The ability to understand a problem, choose an approach, and explain why that approach worked was becoming more important, not less.
I had built Flutter projects. I could write code. But when the interview stripped away the familiar product context and gave me a raw problem, the missing practice showed immediately.
What Happened With 3Sum and 2Sum
The first challenge was to solve 3Sum. I had never worked through that problem before, and the brief DSA study I had done beforehand had not given me enough confidence or pattern recognition to implement it.
I could explain an approach. That was as far as I could go.
There is a big difference between recognizing the shape of an explanation and being able to produce a correct solution under pressure. I discovered that difference in real time.
I had studied 2Sum just before the interview. Even so, I had not mastered it. When it came up, I could not solve it either. Seeing a problem once was not the same as understanding the pattern well enough to retrieve and apply it when it mattered.
That is the part that stayed with me. The interview was for a Flutter role, but my Flutter experience never entered the conversation. I could not get past the DSA section, so the interviewers never needed to find out what I knew about the actual framework.
The opportunity came. I was not properly prepared for the door it used.
The Advice That Gave the Failure Meaning
Afterward, I discussed what had happened openly with the interviewer. They gave me direct advice: I needed to build and grow like an engineer, not only as a developer who writes code without understanding what they are building.
The heart of the advice was simple: these days, anyone can write code, but few people can actually solve problems.
They were looking for people who could solve real business problems, not just produce code.
That distinction gave the interview a meaning beyond one algorithm question. The point was not that every day in a Flutter job would involve implementing 3Sum. The point was that an engineer needs a practiced way to approach unfamiliar problems.
Can you break a problem into smaller parts? Can you identify the information that matters? Can you choose a suitable data structure? Can you reason about tradeoffs? Can you turn an idea into a correct implementation? Can you explain it clearly enough for someone else to evaluate your thinking?
Those abilities matter when the problem is an algorithm, but they also matter when the problem is a slow feature, confusing state, duplicated data, an unreliable workflow, or a business requirement nobody has translated into software yet.
The interviewer’s words landed because the evidence was sitting right in front of me. I had portfolio output, but I had not invested equally in the thinking underneath it.
The Developer I Was and the Engineer I Wanted to Become
At that point, I was a developer who could build. I do not need to erase that progress to admit where it was incomplete.
I knew how to turn ideas into projects. I had learned tools and frameworks. I had spent time creating things people could see. But I had confused visible output with complete preparation.
An engineer needs to understand more than the happy path that produces a demo. Engineering means understanding foundations, asking why a solution works, recognizing where it can fail, and developing the problem-solving ability to adapt when the familiar answer is unavailable.
That is why data structures and algorithms matter. They are not only an interview ritual or a collection of puzzles. Practiced properly, they force you to reason about how data is represented, how work grows, and how one approach compares with another. They train the part of development that cannot be reduced to remembering framework syntax.
My mistake was not building portfolio projects. It was treating the portfolio as though it could stand in for deeper engineering growth.
What I Changed After Failing
Since that interview, I have continued building my portfolio. I have not stopped making products or sharing visible work.
But I am now deliberately building my engineering and problem-solving skills in parallel. That means studying fundamentals, practicing DSA, and giving the slower parts of learning real time alongside project work.
I do not describe this as a finished transformation. I have not reached a point where I can say I have mastered every important topic or solved every pattern. This is ongoing, active work.
What has changed is the priority. I understand why the work matters now, and I never want that interview experience to repeat because I chose visible output over preparation.
Failure did not prove that I could not become an engineer. It showed me exactly which part of becoming one I had neglected.
I failed the interview before I got to the Flutter questions. I do not want to hide that. It is one of the clearest lessons I have received about the engineer I was, the engineer I want to become, and the work between those two points.