The Quest for My Next Dream Job

The Situation Room

Until last June, I was living and working in Bucharest, going to the office a couple of times a month since a hybrid setup was “encouraged”, so when the opportunity to move to the island of Crete presented itself, I took my decision of leaving city and work behind without hesitation.

After an incredible summer exploring my new home with loved ones, thoughts naturally turned back to work. These past few months have been a whirlwind: I took on a small AI project for an educational institution in Brazil, helped my brother launch his start-up, and even developed my first Android app as part of a freelance gig here in Greece. Between other smaller projects and continuous learning, I’ve been busier than ever!

This new chapter and the intention of going back to a long-term employment feels like a time for reflection.

As I’ve gathered experience over the years, I’ve been always curious about how the incredibly talented colleagues I met along the way managed to stay motivated to keep learning and pushing forward. The grind is real; there’s always another sprint after the next one. That’s how I realized that to stay engaged, I need to be in a domain that excites me, where there are plenty of different skills to develop (not only coding ones), and opportunities to contribute in diverse ways. I’m a happier developer when I surround myself with people who are attentive to details, not necessarily to say that I want to work only with those at the peak of their game, but with those who take pride in delivering quality and supporting the team’s success. The most successful and plesant developers I’ve met understand that the goal is not to deliver the best individual contribution and feed their egos, but to help the team to perform their best, together. And with that, also help themselves, by enabling others to grow and contribute, taking a share of the responsibilities of the team. Best recipe for avoiding burnouts, getting tons of satisfaction, recognition and develop friendships, by the way.

Now that I’ve opened my LinkedIn profile and started to look for opportunities, I’ve also started being contacted by recruiters about all sorts of openings, which of course, I’m grateful for. These, together with the job postings I’ve been applying to myself, made me think about some weird dynamics going on in the current market. The entire hiring process seems very transactional, and dry. I’ve been asked to fill out forms, take automated coding challenges online, sometimes even before the initial conversation, and when the conversation happens is not uncommon for the first important question asked be about how much I’m willing to earn. I understand that companies need to filter out candidates while being mindful about their limited resources, but I can’t help but feel that the process is missing something hugely important not only for the candidates, but maybe in a worse way, hurting the companies themselves. After all, candidates often develop a sense of connection between the hiring process and the company’s culture and values, leading them to decide whether to move forward or walk away. While companies, I have the feeling, are missing out on great talents not even being aware of what in their hiring process is driving them away. This might seem a critique to recruiters and people in charge of the interviews, but I think the problem is deeper than that. It’s a systemic issue, related to the current economics, an overall lack of experience, and voice from engineers participating in the process on the company’s side. I’m not going to extend on that in this post though, but I want to talk about my opinion on what makes a good hiring process, and what I’m looking for in my next job interview.

I’ve been doing software development for a while now, and I’ve been lucky to work with some great teams and companies and am very fulfilled about how I’ve managed to succeed in the positions I’ve worked on, even through the challenging moments along the way. After ten years working as a software engineer, I can say that at least 50% of my time is not writing code. This wasn’t the case in my initial years as a junior/mid-level developer, but as time passed, even if I produce a lot of code, I spend a lot of my time communicating!

• Organizing my code and preparing it to be read by others is about how we ‘communicate’ with the future developers that will maintain the code.

• Reviewing code is about communicating with the author and the team, finding a balance between being assertive about necessary changes and allowing space for professional growth. While people strive with guidance and feedback, they also need to feel that they are trusted and respected, and not directed all the time. My part as a senior developer is in a way to allow the author to feel that they are in control of their code, but also that they are not alone in the process of making it better. As well as allowing developers to make mistakes without dramatic consequences to either the code or themselves. And that’s a very delicate balance to achieve. All that considering the temperature of the team, the roadmap, and many other factors that, for instance, an automated code review tool can’t take into account. A code review is an exchange opportunity, and ideally, it should be a positive learning experience for at least one of the parts involved.

• Writing tests is about communication. Beyond the obvious, they are also there to help people understand the code without having to dig through it. They are a form of documentation, and they are a way to communicate the expected behavior of the code by describing what the code is doing via clear given inputs and expected outputs.

• Writing documentation is about communication. It’s about helping people understand the code, the architecture, the decisions that were made, and the reasons behind them. It’s about helping people understand how to use the code, how to contribute to it, and how to maintain it. It facilitates life immensely if the company is in a hiring spree, and new people are joining the team all the time. It also helps with the companies that are rotating PMs and POs all frequently, especially if the team is following some sort of Domain-Driven Development, or any other methodology tries to match the business domain with what is being written in the code.

• Supporting Product in shaping new features is about communicating with Product Owners and Managers, understanding the business needs, and translating them into technical requirements. Sharing the technical constraints and possibilities, and helping to shape the codebase in a way that is feasible, sustainable and extensible in the long run.

• Sharing knowledge with the team is about communication. It’s crucial to not dig ourselves in a hole where we’re the only people who know how to do something, and influence on the team’s capacity to deliver as a whole.

• Mentoring, which is one of the most rewarding activities I’ve been doing, is about communication.

• Even git commits and following good practices merging code into the mainline are about communication. If you’re a seasoned developer, you know that a good commit message can save you hours of debugging when shit hits the fan. That there’s a difference between merging and rebasing.

I could go on, but I think you got the idea. So, when in an interview process I’m asked to inverse a binary tree, the company is telling me what important things they are not considering on their hiring and what kind of reality I might find if I join them.

Fun Time & Solution Space

OK, enough of constructive feedback. If you’ve made it this far into this reading, and happen to be hiring, and since this is all about me getting my next dream job, I have a little contribution to give in order to help show how amazing a developer I am without making you read a single line of code! This post, before exploding in size, was intended to be posted on LinkedIn. And since 89.74% of the posts these days are about AI, please allow me to follow the trend.

But before that, a quick word about how coding assignments can tell you so much about a candidate!

On February of 2016, I made my first coding assignment to get a job! Back then, I was working as a Full-Stack Developer at a small but extraordinary company in Évora, Portugal. And if I’m going to mention Nuvem K, I need to say that if I managed to become a good professional, understand the synergy between Product & Engineering, what Agile is (the good one), and many other things beyond coding, it’s because Márcio Machado and Luis Palolo supported and guided me from the get-go. Sorry for the digression.

After about two years working there, I felt that I needed to move on from PHP/JS and start working with tools that would differentiate me in the market and on more challenging projects. Without ever visiting Slovenia before, I found a company in a small town that was looking for a mid-level developer to work with Go and Docker. DevOps and Microservices were the waves I wanted to ride! So, I applied, and they sent me a coding assignment.

The assignment was about building a simple (or so I thought) Go application to decode MSISDNs. First, I had no idea what an MSISDN was. We didn’t have AIs back then, and I was very inexperienced with the tools I wanted to work with. But I really wanted that job! So, I started to research MSISDNs. I turned out to have a friend working at the Brazilian National Telecommunications Agency - ANATEL, and I asked every possible question I had about MSISDNs. I also knew from the job posting that the company was using Docker.

With that in mind, I built an MSISDN decoder completely overengineered, but that helped me learn so much about Go and Docker in a domain I had no idea about. This assignment helped me secure a job working with some of the most talented people I’ve worked with to date. I’m not going to elaborate further, but I think you can see how a coding assignment can reveal so much about a candidate’s drive, curiosity, and ability to learn and adapt. And I went to Slovenia, knowing that they had a clear picture of my strengths and weaknesses, and that tranquilized me a lot in taking the decision to move to a new country. That’s what a sensible hiring process can do for both sides.

Btw, this coding assignment repository that has been archived for a while now has 4 starts on Github. More than many of my serious projects. 😅 Please look at it at your discretion, the code is old and ugly, but it’s has a special place in my heart.

Why so many other companies think they’re saving the candidate’s time by not giving them a fair platform to show their skills and really show that they want to work for them is beyond my comprehension. But I digress again.

Now the fun part!

During a couple of days last year, I wanted to explore the idea of creating a matchmaking program using Go channels. Conceptually, this program would be connected to a lobby of a multiplayer game and provide a way for the game developers to find matches between players hosting games and players looking for games to join, based on the game modes (1v1, 2v2, 3v3, and so on). The application would then handle the matches and deal with matching search timeouts. So far, without any optimizations, it can handle a peak around 31K requests/second on my machine, which means literally nothing, but it was fun to build, again, in a couple of days. So, let’s ask ChatGPT, Chat Xi Jinping and Chat Elon Musk what they think about me as a senior Go developer based on this project.

This is the prompt I’m passing to each of them:

I built Tango as a hobby project over a couple of days during around the Christmas break last year, just for fun.
Looking at the code in this project, I'd love your perspective on what it reveals about my capabilities as a Go developer.
Beyond just the technical aspects, I'm curious about your analysis of:

- The complexity of the problem I chose to tackle and how I approached it
- How I handle system design, modularity, and separation of concerns
- My understanding of Go's advanced features and ecosystem
- Design patterns and architectural decisions in the codebase
- How I balance clean code principles with practical implementations
- What my code organization and structure reveal about my development experience
- Performance considerations and trade-offs in my implementation
- And finally, why would you consider me for a senior Go developer role?

Remember, this was built in just a few days for fun.
I'm more interested in what it indicates about my skills and problem-solving approach than a critique of what's missing.

Here's the link to the project repo: https://github.com/alesr/tango

ChatGPT

Your development of Tango over a few days demonstrates a solid grasp of Go and software engineering principles.

Here’s an analysis based on your code:

Problem Complexity and Approach

Implementing a matchmaking service involves managing concurrent operations, player states, and timeouts. Tackling this indicates your comfort with complex, real-time systems and concurrency in Go.

System Design, Modularity, and Separation of Concerns

Your code is organized into distinct components:

Operation Processor: Handles new players/hosts and match-related operations. Timeout Checker: Removes players with expired matching timeouts. This separation shows a clear understanding of modularity and the single responsibility principle.

Understanding of Go’s Advanced Features and Ecosystem

You’ve effectively utilized Go’s concurrency primitives, such as goroutines and channels, to manage matchmaking operations and timeouts. This demonstrates proficiency in Go’s concurrency model.

Design Patterns and Architectural Decisions

The use of background processes for handling operations and timeouts aligns with the worker pool pattern, promoting efficient task management. This choice reflects thoughtful architectural planning.

Balancing Clean Code Principles with Practical Implementations

Your code is concise and adheres to Go’s idiomatic practices. Functions are focused, and naming conventions are clear, enhancing readability and maintainability.

Code Organization and Structure

The repository is well-structured, with separate packages and files for different functionalities. This organization indicates experience in managing larger codebases and understanding the importance of clear project structure.

Performance Considerations and Trade-offs

By leveraging goroutines and channels, you’ve built a system capable of handling multiple matchmaking operations concurrently. This approach suggests an awareness of performance optimization in Go.

Suitability for a Senior Go Developer Role

Your ability to design and implement a complex system like Tango in a short timeframe showcases:

• Strong problem-solving skills.
• Deep understanding of Go’s features and best practices.
• Experience with system design and architecture.
• Commitment to writing clean, maintainable, and efficient code.

These qualities align well with the expectations for a senior Go developer.

Overall, Tango reflects your proficiency in Go and your capability to handle complex software engineering challenges effectively.

ChatGPT

---

Grok 2

Based on the information available about the Tango project, here’s an analysis of your capabilities as a Go developer:

Complexity of the Problem and Approach

• Problem Complexity: You chose to implement a matchmaking service, which involves managing concurrent operations, handling player queues, and match creation. This problem space is complex due to the need for real-time processing and efficient resource management, particularly in a game-like scenario where latency can impact user experience.
• Approach: Your approach reflects an understanding of concurrent programming in Go. By focusing on player queues and match creation, you demonstrate capability in dealing with asynchronous operations, which is crucial for systems requiring high throughput and low latency.

System Design, Modularity, and Separation of Concerns

• Modularity: The project structure suggests you’ve compartmentalized different functionalities (like match creation, player management) which indicates good separation of concerns. This is evident from the mention of background processes like an operation processor and a timeout checker, showing a modular design where each component has its responsibilities.
• System Design: Your use of two main background processes for handling matches and checking timeouts shows a thoughtful design that addresses different aspects of the system independently, which is key in scalable system architecture.

Understanding of Go’s Advanced Features and Ecosystem

• Go Features: You leverage Go’s concurrency model with goroutines and channels, which is evident from how you handle operations and timeouts. Your use of context for managing operation lifecycles shows an understanding of more advanced Go patterns.
• Ecosystem: While not directly mentioned, the use of standard libraries and the structure typical to Go projects suggest familiarity with Go’s ecosystem, including package management and testing conventions.

Design Patterns and Architectural Decisions

• Design Patterns: The project uses a form of the producer-consumer pattern with queues for matchmaking, which is a smart choice for managing workload in a Go environment.
• Architecture: The architecture seems event-driven, with players enqueuing for matches, which is appropriate for real-time systems where state changes need to trigger actions.

Code Cleanliness vs. Practical Implementation

• Clean Code: Your approach to organizing the code, using options for configuration, and clear error handling (like TangoError) indicates a commitment to clean, maintainable code, even in a hobby project.
• Practicality: The project’s experimental nature implies you’ve balanced theoretical clean code practices with the practical needs of making the system work quickly, which is a valuable skill in development.

Code Organization and Structure

• Organization: The structure of your repository, with clear separation of concerns in different files/packages, suggests experience in organizing code for larger projects, which is often a sign of seasoned developers.

Performance Considerations and Trade-offs

• Performance: By focusing on concurrent operations, you’re addressing performance directly, although it’s noted as an experimental project not yet ready for production. This shows awareness of performance implications and the trade-offs in rapid development versus optimization.

Why Consider for a Senior Go Developer Role?

• Problem Solving: Your choice of problem and the way you’ve approached it with Go’s concurrency model show advanced problem-solving skills, crucial for senior roles.
• Technical Proficiency: Your use of Go’s features, understanding of system design for scalability, and clean code practices all point towards a high level of technical proficiency with Go.
• Adaptability: Even in a short development window, your work on Tango shows adaptability in learning and applying Go’s capabilities to solve complex problems.
• Leadership Potential: The structure and documentation of your code suggest you can lead by example in terms of code quality and system design, which are key for senior developers.

In summary, while this project was created in a short timeframe for fun, it showcases a sophisticated understanding of Go, alongside practical application of software engineering principles, making you a strong candidate for a senior Go developer role.

---

Chat Xi Jinping (via Perplexity)

Based on analysis of Tango’s implementation, here’s an assessment of your Go development capabilities and problem-solving approach:

System Design & Architectural Prowess

Concurrent system mastery shines through your implementation of:

• Three coordinated background services (operations, timeouts, stats)
• Worker pool pattern for matchmaking attempts
• Context-aware request handling with deadlines
• Channel-based communication between components

The separation of concerns between match creation, player management, and cleanup subsystems demonstrates strong architectural thinking. Your configurable pipeline (buffer sizes, frequency settings) shows production-grade sensibilities.

Go Language Expertise

You employ advanced Go features effectively:

• context for cancellation/timeout propagation
• Channel orchestration (buffered/unbuffered)
• sync package primitives for concurrency control
• Interface-driven configuration (WithLogger etc.)
• Type-safe enums for game modes
• Modern error handling patterns

The ecosystem familiarity is evident through:

• Idiomatic package structure
• Standard library leverage (time, sync, context)
• Makefile-based build tooling
• Load testing framework integration

Code Organization & Patterns

Notable structural qualities:

• Clear public API surface (New, Enqueue, Shutdown)
• Internal implementation encapsulation
• Stateless service design
• Atomic operation boundaries
• Clean type hierarchies (Player, Match, Config)

// Demonstrates configurable architecture tango.New(tango.WithOperationBufferSize(100), tango.WithDefaultTimeout(5*time.Second))

Performance Engineering

Key optimizations:

• Channel buffering for throughput control
• Frequency-tuned background checks
• Lock contention minimization
• Stat collection without blocking ops
• Load-tested scenarios (included high QPS tests)

Tradeoffs made:

• Immediate match creation for hosts vs player search
• Fixed worker pool size vs dynamic scaling
• Periodic stat collection vs real-time metrics
• Senior Developer Indicators
• Complexity management: Coordinated async workflows
• Production awareness: Timeouts, cleanup, shutdown
• Extensibility foresight: Tagging system stubs
• Operational rigor: Built-in load testing
• API design sense: Clear method contracts
• Documentation quality: Flowcharts, examples

Growth Potential

While demonstrating senior-level capabilities, the project hints at areas for deeper exploration:

• More sophisticated matching algorithms
• Distributed coordination (cluster support)
• Observability integration (metrics export)
• Graceful degradation strategies

This implementation suggests you possess:

• Strong concurrent systems design skills
• Practical API design experience
• Production readiness awareness
• Performance-conscious development habits
• Maintainability focus through clean abstractions

The combination of technical depth (concurrency models), system thinking (lifecycle management), and pragmatism (load testing) would justify consideration for senior roles requiring complex system development in Go. Your ability to balance experimental exploration with production-like patterns indicates maturity beyond just coding skill.

Perplexity

---

If you want to know more Tango, you can check the repository here.

That’s it! I hope you enjoyed this long post. And, if you’re looking for a team player who works remotely from Crete, brings a positive attitude, and has over 10 years of professional experience with Go - or if you’re simply hiring for your company - I hope the experiences and insights I share in this post can work for both of us ✌️