My worst interview

We all know that the interview process is always tough: stressful environment, difficult questions, having to write and explain code to other people, and sometimes in another language?! We know, it’s hard.

But today I didn’t want to talk about techniques only, like “use the STAR method/xyz and blah”, no, I want to talk about how this interview taught me something.

The context

Throughout this year of 2025 I was flirting with Go, and decided to give it a real chance. I studied a lot, made projects and everything, then I decided to just enter a Go process to validate my level up to that point, and it was the best scenario: 7 days to study, a brief description of how my technical interview would be, but without many details.

It was the perfect scenario! I organized my study into topics, picked the most requested exercises in Go, for example, algorithms and LeetCode, how to create a micro-lib cache with thread safety, how to use go-routines, channels and stuff. I also studied the language fundamentals, something I haven’t even done in my main language in 10 years! I know, I should be ashamed haha

I thought I was chill, focused a lot on the language, I was even a little confident to be honest.

The interview

Then came the interview moment, there were two guys. Right off the bat I started with some bad vibes talk: “Good morning, how are you? Blah blah, sorry I’m nervous!” Look, words have power, and they can save you or bring you down lol.

Talk comes, talk goes, asking those things that were already memorized: biggest challenge, projects I was most proud of, what I liked to do and so on. Up to that moment it was great!

Then came the moment when one of the guys asked: “Let’s code?” The initial task was simple: create an API in Go, and given an interface they provided, apply a function to bring data from an Elasticsearch. A kind of proxy, nothing big.

The moment of truth

Here, at this exact moment they said: “Read it calmly, take the time you need, we’ll be here to answer your questions about it”.

And you know what I did? I asked, but I didn’t ask honest questions. I just did something like “ah so it’s to do this, and this right?”, they confirmed and that’s it, I started. And at this moment the interview was over.

I was so worried about applying patterns, folder structure following community standards, everything at the same time talking about everything here my ADHD kicked in big time lol, saying one thing and writing another. There came a moment where I had 10 folders and only one main.go.

Then one of the interviewers interrupted me, even joked that usually he played the bad cop role, but that he wanted to talk to me. He asked me why I wasn’t talking to them.

FOR GOD’S SAKE!!! THE BASICS!!!

What I did wrong

I was so focused on showing that I knew enough Go, that I didn’t even really ask. I assumed many things, and that, even though I knew everything I was doing, even though I verbalized what I wanted to do could be a great idea, the problem is that I didn’t share that with them. I just kept doing, typing, typing and typing.

We know that real life doesn’t work like that: you talk to people, make alignments, validate if you’re going in the right direction, receive feedback.

And of course, the interview ended faster than expected after that feedback and I bombed!

The reflection

It was great, I had never had such a bad interview! I’ve had interviews where I froze when I was speaking English, I’ve had experiences of not finishing code, not knowing how to solve algorithms and etc, but this was the one that hurt the most, because it was in the basics.

My rush and desire to show ended up externalizing a problem. Sometimes we don’t want to talk, we just want to have our turn in the conversation, and that’s horrible!

In an interview, you have to understand that this can’t happen. I’m also not saying you have to ask about everything, right? It’s important to have a balance.

The lessons I learned

Thinking about this type of live coding interview, some tips I give are:

First of all: grab a paper, or share the screen and open a txt.

1. Time for notes

Ask for some time alone just to make notes and questions, just to summarize the proposal.

2. Validate your doubts with the interviewer

Now, think that the interviewer at this moment is your friend, he doesn’t want to screw you over. So read your doubts out loud, share your notes with him. He wants to be truly inserted in the process.

A mistake here is thinking that live coding is just starting to code. Think of this as a design system interview.

Example: “So, I made my notes here, and I wanted to validate them with you to know if I’m on the right track, is that okay?”

3. Raise scenarios and possible problems

Put some cases and maybe possible problems that you see as doubts, and validate if this should be taken into consideration.

Example: “I have to build an API, but do I have to worry at this moment about security layers like cache, rate-limit, api-keys?”

He’ll usually tell you which things are good or bad. It’s good to have a feeling here, but if he focused on some subject, go along with him. He might be wanting to know the level of depth of your knowledge. Feeling is always important.

4. Confirm the complete scope

After notes, corrections and validations done, confirm the minimum requirements (AGAIN). Separate in a different section what is Bonus.

Now the key: think that you’re going to ask some AI to build this for you, but you only have one sentence. Create that sentence and read it again, ask the interviewer to validate the entire scope. Yes, add to your sentence what is bonus.

Example:

“Ok, just to confirm the understanding of the problem, so the idea here is to create an API to do X, and in this API the rules are ‘if age > than 20’ then J otherwise K, and as bonus the points to consider in this solution are cache, logs and tests, did I understand correctly?”

This will give you security and a guide on how to do it and where to focus first, and you’ll gain many points, trust me!

5. Organize in incremental steps

Perfect, now with everything you need to have, think even about the bonus, and try to organize this in sequential and incremental steps, but always focusing on the minimum requirement! Don’t forget: write down this sequence too, it’ll be good for you as a form of checklist.

Practical checklist example:

1. Have an API where GET /user?name=john returns the JSON below:

   {
     "id": 1,
     "name": "john",
     "role": "admin"
   }
   

2. API rules:

• Query param name:
  • cannot be empty
  • cannot be less than 3 characters
  • cannot be more than 10 characters
• cannot receive other parameters

6. Choose your approach: Test-first vs Code-first

Here we can have 2 approaches: test-first or code-first. You have to remember that you’re being evaluated, and how much time you have. If you have time left and you’re comfortable, go test-first.

6.1. Using test-first

Here you demonstrate seniority, very nice, top! But don’t fall into the trap of making all tests at once. Your tests should evolve with your code. I’m not talking about TDD, remember that you just have to demonstrate how you work.

Tip: Create just one test to hit your API returning 200, and creating 1 main file with the server, route, mocked response all together. Explain that you’re just structuring the code, and that this won’t stay like this, and that you just want to guarantee this first basic scenario. As you evolve your code, you’ll feel that you need new layers.

6.2. Using code-first

Let’s say you’re out of time, then you go code-first. Make it clear to the interviewer how you feel, say that you know the importance of tests, but that you’re not confident implementing them with the available time. This might cost you some points, but better some points than saying you don’t know or not writing any code right? 🤡

And here the idea is the same: start easy. The layers, the ports/adapters, everything will come naturally when you implement that checklist of yours.

6.3. Code patterns

Here it’s always good to implement good code patterns whenever possible. I’m referring to SOLID. If you’re going to remember any at this time, just remember the dependency injection part. If you’re in test-first it’ll come naturally; if not, just mention that with this you decouple the server from your service/use-case and stuff, just to demonstrate that you know how to do it.

Conclusion

And to conclude, I want to say that first of all, interviews are always difficult and even knowing these things I still made mistakes 🫠. I had never had such a remarkable interview haha.

And don’t feel bad about a bad interview you had either. I was so destroyed that I got to the point of writing this here, I survived and still learned more things. It’s always win-win in the end! The important thing is not to give up and understand where you went wrong.

If possible, always try to have that “shame notebook” - it’s useful to make you remember these things at each interview. Either you get the job or you publish it as a book, you know? It’s always win-win in the end 😜