TLDR;


My recent experience of the horrid recruitment process didn’t end up in collaboration, and I’m truly happy about it! The experience taught valuable lessons about communication, setting boundaries, and recognizing red flags in the hiring process.

How It Started


As some of you may know, recently I started looking for a new project. After a few months of my burnout break, I felt ready for a new gig. I posted this Tweet:

Hey folks, I’m back on the market! Do you know of any macOS/iOS projects I could help with? 😊
Must-have: great work culture 🤝
Great to have: part-time (20-32 hrs/week)
Nice to have: multimedia domain, but I’m really open here 🎨

I hoped to boost my search a bit. While I kept browsing social media and work-related platforms, I was aware that I don’t see all possible projects. In case I missed my dream job, I hoped someone would see this Tweet and reach out to me. And it worked!

A PM I know texted me that it was perfect timing. The startup he worked for was considering some additional iOS consulting. We arranged the call so he could share some more details. The role ticked all the boxes: part-time consulting in a multimedia-related project. He also claimed the culture of work was great, and knowing this person, I knew our views in this area were aligned. The company, despite its small size, had no pressure to grow fast. They rather cherished the chance to collaborate closely across the teams. Everyone had some contribution to the roadmap. And instead of setting up deadlines, they just published whatever was production-ready.

The only problem was, the iOS team was noticeably slower than other platform teams. But there was a reasonable explanation for it. iOS was the first supported platform. Unfortunately, the person laying out the foundation of the app was as skilled as toxic. For a while, it was tolerated. But the real problem emerged with the need to expand the engineering team. A new engineer didn’t understand the overly complicated code and didn’t want to work with this person. So the technical founder was made redundant. The new engineer took over the app, and one more developer was hired to help him. After a while, the consequences of the bad start were still there, as the legacy code was slow to develop, especially considering the non-trivial domain.

I got really excited about this opportunity. I had some experience with multimedia. As a person who worked mostly on small projects, I wasn’t afraid to get my hands dirty. And the part-time role would give me a lot of space for my loved ones and hobbies. We agreed I was going to meet the principal engineer. He was going to outline the current shape of the app and the challenges I could help with.

The Promising Meeting


We met a few days later. The engineer — let’s call him Adam — created a good first impression, of being both experienced and communicative. We were happy to find out I could help them indeed. In the past, I have already solved challenges similar to the ones the app was facing. But what mattered to me the most, we were able to discuss these issues in a substantive way. We brainstormed possible solutions, considering both the bright and the downsides of each one. The whole conversation was educational and uplifting.

We agreed on arranging one last call, so I have a chance to meet his collaborator and talk a bit more about the technical details. I wanted to prepare myself, so I specifically asked if the following call will be the classical technical interview. Adam told me to expect just a chat. That was relieving to hear, so I didn’t stress much about the meeting. The only preparation I did was double-checking the docs. Adam mentioned one API they were using. I had a hunch that abusing it might be one of their performance bottlenecks. My suspicion was confirmed by the first paragraph of the docs. I made a note, hoping to share this insight next time we chat.

The Worst Meeting in My Career


When joining the meeting scheduled two days later, I was relaxed and self-confident. I was also excited about meeting my — presumably — future coworker. The other developer — let’s call him Bob — welcomed me in a rather grumpy way. But I ignored it; maybe he just wasn’t in shape. We started with small talk, which was interrupted by Bob in not exactly a smooth way: “Ok, that was the small talk, we can start the questions list”. I got puzzled and asked what list. “A list of the interview questions”. I reminded Adam that I specifically asked about this, and he claimed this meeting wasn’t going to be an interview. He asked me if that was really the case, and if so, it must have been a miscommunication.

I’m allergic to the word “miscommunication”. In most cases, it’s an attempt to say “you got it wrong, get over it, it will be my way”. My question wasn’t too ambiguous. I wasn’t prepared for any generic theoretical questions, especially considering my six months' break from any coding. They apologized and explained that the last time they hired someone without an interview, it turned out this person was hardly capable of coding. This time they wanted to do something, so they Googled some list of questions. And if I didn’t mind, they wanted to give it a shot.

I deeply regret I agreed to proceed. I got a bunch of academic questions, like “what’s the paradigm in Swift”. Sure, every day at work I use protocols. I also have a comparison with other coding languages. Whenever I do something, I make sure to have at least a brief understanding. But since I expected something completely different from this meeting, I missed even the vocabulary. I felt like someone would wake me up in the middle of the night and examine me. I tried to keep it cool, so I decided I was going to reshape this formula a bit more into the conversation. No luck. It didn’t matter if I said an anecdote about this topic from my practical experience or asked them about their experiences instead. Every time after reaching a few sentences, Bob interrupted me: “Ok, cool, on to the next question”.

This awkward questioning lasted almost one hour, which was the preserved time slot. Adam thanked me for that part and said we can move on to the more practical part of the meeting: the chat about the multimedia-related issues. I drew the line here (brain, why not earlier?). I said we’re not moving anywhere. Since the beginning of the meeting, I kept answering the questions I didn’t expect, failed miserably chatting with them, and sounded stupid. At that point, I was emotionally drained. I gave them a choice: we could make a break, or schedule another meeting. It took us another half an hour to decide and schedule another meeting.

At the end, I asked them two simple questions:

• Were they any closer to decide if they want to collaborate with me?
• Did the questions helped them to know if I have the skills needed to solve their current issues?

As I expected, both answers were negative.

The whole experience was dreadful to me. Until the end of the day, I had flashbacks from this meeting. I decided to text the PM who reached out to me originally. I briefly described the meeting and he got shocked. He said he knew Bob was a bit introverted, but he had a good opinion about both developers. PM apologized to me, thanked me for my feedback, and said he was going to chat to the Head of Engineering about it.

The Final Meeting


I didn’t hear from anyone until the time of the next scheduled meeting. I hesitated if I should join it or not. I decided to give it a go, hoping it was a one-time mistake, and the project would turn out great. Upon joining, I was surprised by more attendees than what I expected from the invitation. Apparently, the HoE decided to join and lead this meeting. I kept my poker face waiting how this meeting develops. And I was relieved to see the meeting was incomparably better than the previous one. HoE had much better interpersonal and business skills. He led the conversation in the manner which I expected from the previous meeting. He asked me about my experiences, e.g., the most gnarly bugs I managed to solve. He said my first task could be the videos upload and asked about my approach. I sketched how I would tackle this problem, with the issues I would expect on my way. We tried to keep the conversation on a high level, without too many technical details.

Unfortunately, Bob’s vision was different. He kept asking me detailed questions about the specific APIs I would use. I kept repeating that I didn’t know; it would depend on their tech stack and available options. He insisted, so I explicitly said I didn’t think it was the best time to go into such detail. Luckily HoE supported me. We wrapped up this section of the meeting, and it was the time for the questions from the engineering team. Adam asked me about the best performance practices. I reminded myself of the note I took after the first meeting, so I mentioned creating objects once and keeping them around. Once more Bob tried to argue with me claiming it can’t be important. I just told him to read the docs. Geez!

The only thing which kept me on this meeting was the fact I wouldn’t work with these developers on a regular basis. My role would be to spot the issues and fix them independently. Nonetheless, I wanted to establish some opinion about these people, so I had a chance to collaborate with them in the best possible way. We once more reached the end of the time slot for the meeting. But I asked for extra time, so I had the chance to ask them a few questions. To get a grasp of the workflow, I asked them about their casual day at work, who assigns issues, or how do they review code. I didn’t expect any specific answers; I just wanted to get to know them.

At the end, I asked my favorite question: “Did you have any strong disagreements? If so, how did you solve it?”. Bob said he has a good example and actually smiled for the first time (!). He said they couldn’t agree on how to style the UI components, so in his classes he uses one modifier, and in Adam’s classes, Adam uses another one. He seemed proud of what he has said. I hanged for a second, then thanked him for sharing. I added that personally, I would prefer to keep the consistent codebase. It was after the meeting when I realized how bad that answer was. Beginning with the idea that the class is Bob’s or Adam’s. It’s not; the class belongs to the project. And the programmers are the members of the team developing the project. There shouldn’t be that much room for the ego. It became clear to me why the code hasn’t been refactored for such a long time. I remembered that Adam was hired three years ago. That’s quite a long time for the cleanups in the app, which doesn’t have that many features! But this time must have been spent wisely, definitely not on the arguments over syntax.

How It Ended


I texted the PM one more time and shared my thoughts. He said the HoE made similar conclusions, and they were grateful for my questions. Until that day, the whole company was blind to the issues they were having. The iOS team did the doorkeeping, blaming some guy from the past for the slow development pace. They had no idea what to do about it though. The PM sent me a message: “As a friend, I’d say stay away”, and that he doesn’t want to put me in the crossfire.

For a while, I was pretty bitter about this whole process. I had high hopes for this project. Then I got in the ambitious mood, thinking that maybe I can join them after all. I’d drive the process of cleaning up both code and the ways of working. But at the end of the day, I really appreciate the honesty of the PM. I’m sure that’s not the only opportunity around. And my energy is limited, so I’d rather spend it on more fun duties.

Few Takeaways From the Whole Experience:

1. Communication is Key: Clear and honest communication can prevent many problems. Also, sending a written confirmation allows everyone to refresh the memory. I wish I did it!
2. Trust Your Instincts: If something doesn't feel right during the interview process, probably will just get worse later. Be honest with yourself and don’t be afraid to abort the process.
3. Value Your Time and Energy: Your time and energy are limited. Focus on investing them in opportunities that are fulfilling and align with your values. Also, “No” is a valid answer!

Since I can’t undo this energy investment, I appreciate it as an important lesson. Staying optimistic, looking forward to joining my dream team!