My Worst Interviews and the Lesson They Taught Me

If you’ve been around long enough in tech, you know hiring is broken.

We all have horror interview stories. It’s a shared experience all the way from small companies trying to imitate FAANG processes and large companies with dozens of “phases” to go through.

I’m not the exception, so here are two of my horror stories and a lesson.

They wanted to test my IQ

Before the bubble of 2020, a recruiter from a staffing company reached out on LinkedIn.

The meeting had an awkward start. The recruiter refused to speak in our native language, but in English. I might understand that, since they worked with American clients.

But the horrific part came when she told me they were going to test my IQ to see if I was “smart enough” to work with them. At that moment the interview ended for me. Run, Forrest, run!

They wanted a screen-recording

I’ve been asked to solve take-home interview challenges more than once.

But this time, with another staffing company, I had an unusual interview challenge: not only did I have to solve a medium-size coding exercise, but also record my screen while explaining out loud my thought process, in no more than 2 hours, and send them a link.

I guess a poor soul had to watch my recording at 2x, if anyone ever watched it. My thought was to create a YouTube channel and solve it live. At least, it would count towards the watch time to monetize a YouTube account. Of course, I didn’t continue.

Probably I had more horror stories I can’t remember.

The lesson

Hiring is a two-way street: you’re evaluating them the same way they’re evaluating you.

The first meeting shows how they’re going to treat you as an employee. And if you notice red flags during the process, like unclear expectations and unrealistic demands, imagine what it would be like working there.

Always ask about the next steps, salary, and compensation in the first meeting.

When I was job hunting, my rule was to step away if they didn’t share salary details in the first meeting. Why waste months only to discover they’re offering half of your current salary?

The Not-an-Architect Effect

Has this also happened to you?

You’re in a meeting discussing a technical issue or a bug. After many ideas, you share yours. But it passes unnoticed.

Since there was no consensus, another meeting is scheduled. But this time with a figure of authority or expertise: an architect, director, or VP.

Surprisingly enough, they share the same idea as yours. But this time, it’s considered.

That’s when you say “I said the same thing, but since I’m not an architect, director, or VP nobody listened.” Arrggg!

Sure, those moments are frustrating. But they earn us points in our authority and trust score.

It’s not only about sharing good ideas, but how we present them and how others perceive us, just another team member or a trusted one.

That’s what I call: the not-an-architect effect. A reminder that how we present our ideas is as important as the ideas themselves.

Minifeed Showed Me the Indie Web: My Favorites from Yesterday's Feed

If you’re not new to writing online, you’ve heard blogging is dead.

And there’s some truth behind that. Social media has killed blogging. Google doesn’t like personal blogs anymore. It’s regurgitating AI answers. That made me change my writing strategy, by the way. My blog isn’t the only place I show up anymore.

Personal blogs are still alive…in a small corner of the Internet. The problem is discovering them.

If Google’s bots don’t crawl and index your blog, your posts will sit there forever, waiting for visitors. That’s not the case with social media. Just open your account and scroll your feed. And boom! Content is there!

These days, while looking at my analytics, I discovered out a “feed” for blogs: minifeed

Minifeed is “a curated blog directory, reader, and search engine.”

Its goal is to collect personal blogs and make them discoverable. No AI or algorithms behind the feed, just human curation.

Yesterday, I scrolled through minifeed’s feed and went down the rabbit hole of personal blogs. Here are my favorite posts:

#1. A photo of a big door. This is from a photographer running a plog, a photo blog. Did I just invented a new Internet word?

#2. A diagram of feline feelings.

#3. A software engineer who changed his mind about AI.

#4. A reflection on time passing.

#5. A developer who learned about nonograms. Imagine a sudoku marrying a crossword, but instead of putting numbers in cells, you have to color them. Definitely, I’m giving them a try.

#6. A writer who decided to stop writing down ideas because good ideas always come back. Well, I need to write them down to tell my brain “it’s OK, we already did something about it. Back to sleep.” I also discovered another daily blogger.

#7. A post on why requests to fire people are often rejected.

#8. Someone using music as a pain reliever after getting his knee replaced.

#9. And of course, my own post with tips to read code. Shameless plug.

If you want to go down the rabbit hole of personal blogs, try indieblog.page to get a random post or searchmysite.net for a search engine of personal blogs, ooh.directory, or blogroll. Blogging isn’t dead yet.

Three Tips to Read Code More Effectively

We spend more time reading than writing code, but we’re seldom taught how to read it.

Almost 100% of my coding courses in university were about writing code: syntax, algorithms, and class design. Nothing about reading. I only learned about reading code from a coworker at a past job.

Yesterday, I found this conversation as part of the GOTO Conference about reading code:

Here are some key points from that conversation:

#1. Read a piece of code at first glance and see what stands out. Maybe that’s a function or a symbol or a messy block of code. That’s also my go-to guide to refactor a piece of code: while scrolling through a piece of code, if I need to stop and read it twice, there’s something to refactor, something needs to be better explained.

#2. Read with empathy. After reading Clean Code for the first time, when I found a piece of code that wasn’t closely aligned to the book, I always said “who wrote this crap?!” I had to learn that we all do our best with the context and deadlines we have. If we have to fix a pressing issue in 24 hours, we do our best. That might not be the perfect solution. And of course, there will always be better ways to solve a problem, once we solve it for the first time.

#3. Always start by pointing the good parts, especially when auditing or reviewing other people’s code. It reminds me of the principle from How to Win Friends and Influence People: don’t tell anyone they’re wrong.

Read more code, that’s the best way to learn to code. The more code you read, the better at writing you become.

A Simple Script to Keep a Log File with Bash and Vim

To keep track of my client work, I’ve been using a simple “did” file. You know, I’m a plain-text fan.

At the end of every workday, I write down what I did for that client and what I need to do the next working day.

Here’s the script I use—add it to any of your dotfiles:

function did() {
    vim +'normal Go' +'r! date "+\%Y-\%m-\%d \%H:\%M:\%S"' +'normal o' ~/did.txt
}

From a terminal, simply type did, and it opens a “did.txt” file with Vim, appends the current date and time at the end, and you’re ready to type. Simple as that.

For everything apart from client work, I’ve ditched my to-do lists.