Two Rejections: Rambling Answers and Focus in the AI Era

In this post, I want to talk about being rejected. If you have been through the same kind of failure, or if your answers tend to run long in interviews, you can see how far I traced the cause and what I decided to change. I write about what I failed at first, and at greater length than what I did well.

Two processes that mattered a great deal to me recently came to an end. Both ended in rejection. It stings, but there were clear failures and clear lessons in them, so I want to write them down before they fade.

Answers That Run Long

The first failure I noticed was in how I spoke. Getting my point across clearly in a conversation was harder than I expected. Say I was asked this about one of the projects on my resume.

"What led you to make this improvement?"

To answer, I first weave a story in my head about why I did the work and how I improved things. That part is not hard. The problem comes next.

The question asks for the reason (Why) and the method (How). So I could simply lead with the conclusion: "I improved it this way, for this reason." If that seems too thin, there are two options. Add one more piece of evidence to support that conclusion, or let the other person ask follow-up questions about whatever they want to know.

This second step is where I fell apart. No piece of work fits in a line or two. There were several possible solutions, I made wrong fixes while weighing trade-offs, and only at the end did a result come out. Trying to fit all of that into one short question, my answer turned into a solo speech before I knew it. The listener was probably thinking, "So what is he actually trying to say?"

As a person, I already know the answer. When I meet someone for the first time, the people I am drawn to are not the ones who talk on and on about themselves. They are the ones who answer my question in a way that makes me feel, through their expression and attitude, that they are focused on me. Yet when I stood up as an engineer to explain my own work, I could not do that well.

Not Enough Material to Explain

When I followed the reason my answers ran long a bit further, it was not only about how I spoke. The material I needed to explain my work had not stuck firmly in my head. In my case, my answers wavered in situations like these.

When I tried to highlight work I had done long ago and only vaguely remembered
When I tried to explain a result pieced together with help from several people
When I lacked the perspective to explain my problem-solving process in technical terms

A resume and a technical portfolio summarize a long stretch of one person's time, and every item carries a lot to talk about. So nothing in them should be something you cannot explain with confidence. In a field where collaboration is the norm, work done entirely alone is rare. That means I should separate what I owned from what I got help with clearly, starting in the document itself, and keep to that line when I speak.

I think the way I have been working lately also played a part in running short on material. In the past, I went down a lot of dead ends when solving a single problem. I ran things through a translator, searched, read other people's writing, and organized different perspectives in my head and in writing. Now I say "do this," and AI hands back everything from the judgment to the result on its own.

So did I open up that intermediate process and read it through, piece by piece? I did not. Because output and results mattered, I either skimmed only the key points of the process or just took the result. The process I skipped over did not stay with me as material I could bring up in an interview.

Some people will say that now that AI has come this far, this kind of process is no longer necessary, and that I should spend that time producing more results. I do not think so. Going forward, I will still have to make many choices based on the processes I went through and the results I got. Results built without the process can grow in number and still be an empty shell. The time I spent cutting the process short so I could do more and show more ended up working against me. This rejection is what made me realize it.

So here is what I will change. Before I accept a result from AI, I read the process all the way through. I restate the problem in my own words and check for myself whether that reading is right. Only work that has gone through this check lets me have a technical discussion, and only then do I have evidence to back up a one-sentence, answer-first reply in an interview.

Measuring My Focus

There was a deeper reason I could not read the process through to the end. Focus. Looking back on this failure, it is what struck me most.

I wanted to know how bad it was, so I tried the Pomodoro technique on an ordinary weekend. I set one cycle as 40 minutes of work and a 5-minute break and ran six cycles. To avoid being self-conscious about the measurement, I recorded my screen and reviewed it later.

Here is what I found. During work time, I drifted off to messengers, websites, or my phone 16 times without meaning to. That is two or three distractions every 40 minutes. For breaks, counting only the time beyond the set 5 minutes, the total came to 7 minutes 41 seconds. Every break ran over by a minute or so.

Seeing the numbers, things I had felt day to day came into focus. I lose the thread while talking to someone, and on the move I flick through YouTube Shorts and songs nonstop. I suspect my focus broke down as I handed more and more work to AI. I never measured it against the time before I used AI, so this is not verified. What is clear is that I have grown used to a short rhythm of waiting for results, skimming them, and sending the next request.

With focus this low, even when I ran several agents, it was hard to read their output properly. I tired easily and my judgment got cloudy. In conversations, too, I stayed inside my own thoughts instead of focusing on the other person. I think the long answers I described earlier are not far from this.

I once watched a video on Jin Yong-jin's YouTube channel about the focus of people studying for civil service exams. What stayed with me was this. People believe their focus is better than it really is, so they set goals of more than an hour from the start, fail to keep them, and give up.

Around me are people who started at the same time as I did but understand technology more deeply. They may be smarter, more diligent, or better placed to study. Even so, as I see it, the biggest difference is focus and immersion.

So instead of a grand plan, I am going to start by succeeding at short stretches of focus. Even if I run several agents, I look at only one thing per hour. Then I will measure again the same way and see whether 16 times and 7 minutes 41 seconds go down.

What I Held On To

It was not all failure. I want to note down a few things that went reasonably well.

Studying After Work

Studying after work is hard, as expected. It is even harder to get to the point where studying becomes a natural habit on weekdays and weekends alike.

For a month and a half, I put studying first. I cut back on drinks and plans and went to a SparkPlus lounge every day to study. There were plenty of temptations, but I resisted most of them. I cut carbs to feel less tired, which helped me lose weight and feel better, and I also got into the habit of taking supplements.

Since I wrote earlier that my focus had broken down, this may sound odd. As I see it, I built the habit of sitting down, but I still lacked the strength to make full use of the time I sat there. That is what I need to fix next.

Asking Why of Other People's Code

In the past, other people's code did not move me much. My reviews mostly stopped at asking about logic I did not understand. Even when I saw something that broke conventions or could be improved, I only mentioned it lightly.

This year I set a goal of building my own standards for writing code, and I read writing from many perspectives. Along the way I developed a way of judging based on technical grounds, and I became able to question other people's code.

That eye does not yet reach far enough into my own work. The failures I wrote about above are exactly that gap. I want to apply the same habit to my own work: not passing over a problem when I see it, and understanding each step by asking "why."

The People I Study With

Studying this time, I learned that there are many good people around me. The people in my study group give their own time to study and share that energy. They actively point out what I missed and show genuine interest. Every time we spend time together, there is a lot to learn.

Preparing Again

Looking back, these rejections were one chain of events. With my focus down, I could not follow the process to the end. Skipping the process left me with thin material to explain. With thin material, my answers ran long. So I will prepare again by walking that sequence in reverse. First regain short stretches of focus, then check the process behind AI's results myself, and then use the material built that way to practice leading with the conclusion.

If you have ever found yourself rambling in a similar situation, before fixing how you speak, it may help to check how well you can explain the process behind that work right now. For me, that was where the real cause began.

Looking Back on Two Rejections