My worst interview

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. ...

October 10, 2025 · 8 min

Refactoring CLIs with the Pipeline Pattern

A practical tutorial showing how to transform a monolithic data-collection flow into a modular, testable, and extensible design. Let’s say you’re building a CLI that interviews the user, asking for name, birth date, and document number. The initial version works, but soon becomes a hard-to-maintain block of code: how do you add validations without increasing complexity? how do you implement confirmation and retry logic for each input? 1. Initial Scenario package main import ( "fmt" "log" "strings" "time" "github.com/AlecAivazis/survey/v2" ) func main() { var name, dateStr, document string if err := survey.AskOne(&survey.Input{Message: "Name:"}, &name); err != nil { log.Fatal(err) } if len(strings.TrimSpace(name)) < 2 { log.Fatal("Name must have at least 2 characters") } if err := survey.AskOne(&survey.Input{Message: "Birth date (MM/DD/YYYY):"}, &dateStr); err != nil { log.Fatal(err) } birthDate, err := time.Parse("01/02/2006", dateStr) if err != nil || birthDate.After(time.Now()) { log.Fatal("Invalid birth date") } if err := survey.AskOne(&survey.Input{Message: "Document:"}, &document); err != nil { log.Fatal(err) } if len(document) == 0 { log.Fatal("Document cannot be empty") } fmt.Printf("Collected: %s | %s | %s\n", name, birthDate.Format("2006-01-02"), document) } Here we see some problems: Difficulty adding new steps: every new field or validation requires modifying the whole flow, increasing the risk of bugs. Validation rules mixed with data collection: it’s hard to isolate or reuse validations. Rigid, inflexible flow: not simple to reorder, skip, or repeat steps without rewriting code. No organized retry mechanism: any error terminates the program, no fine-grained retry control. Low clarity about the flow: as code grows, it becomes harder to understand the order and logic of each step. 2. Reasoning for Decoupling We want to split the process into independent steps, each responsible for: • Asking; • Validating; • Deciding whether to retry or move forward. ...

September 4, 2025 · 6 min

How I Finally Built This Blog

Okay, I just needed to get this blog working somehow. By this point, it was my fifth attempt. If you’re reading this, chances are you’re in tech—or maybe just curious. Something pretty common in this field, especially among developers, is wanting to have a blog. The idea sounds awesome—until you fall into the first trap. 1. Having a blog means actually building one I jumped in right away: started a React project with server-side rendering, set up eslint, plugins, sass yes, people still used that not long ago haha, and everything was moving along fine—until I hit the first roadblock: actually starting. ...

September 1, 2025 · 3 min