DEV Community: Noemi Rozpara

A Success Story: I Didn’t Get the Job

Noemi Rozpara — Mon, 06 May 2024 11:03:47 +0000

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!

RxSwift - easy, yet not obvious, tips

Noemi Rozpara — Thu, 21 Jan 2021 14:26:05 +0000

Last few months were for me my personal RxSwift bootcamp. I decided to refactor my app and rewrite a few big protocols to observables. This helped me to view Rx with a fresh eye and catch a few problems. Those might not be obvious for people who do presentations or boot camps or are familiar with this technology for a long time. Some - or all - of the points might be silly for you. But if I will save just one person from being confused, it was worth it! So without a further ado, let’s jump to the list.

Rx is just an array + time

I think this is the most important thing to understand with all your heart. All subjects, relays and operators might seem scary, especially with Rx-hermetic jargon. But simplifying it in your head to a simple collection will help you to understand all concepts easily. For me it was a sudden click. If you want to learn more, official docs are great source and emphasize this concept: https://github.com/ReactiveX/RxSwift/blob/main/Documentation/GettingStarted.md#observables-aka-sequences

Oh, those memories

RxSwift syntax is elegant. But sometimes it makes it harder to spot the moment, when you create strong reference cycles. Also, this issue is ignored by many learning resources. Authors are trying to maintain snippets as clean as possible. It took me a while to get to that by myself.

Problem: we have a strong reference to self inside a callback. And self.disposeBag holds the strong reference to the callback. Finally it’s not getting cleaned up forever.

How to solve it? Always include [weak self] or [unowned self] when you are passing a lambda to subscribe, drive or bind, which includes any reference of self inside. Be cautious for implicit self calls! You don’t need to do that, when you are binding rx property.

Few examples:

No need to do anything for driving or binding to rx attributes:

@IBOutlet var statusLabel: UILabel!

myModel.statusLabel
  .drive(statusLabel.rx.text)
  .disposed(by: disposeBag)

No need to do anything if callback doesn’t include self or it’s weak reference already:

myModel.statusLabel
  .subscribe(onNext: { newLabel in
    print(newLabel)
  })
  .disposed(by: disposeBag)

@IBOutlet weak var statusLabel: UILabel!

myModel.statusLabel
  .subscribe(onNext: { newLabel in
    statusLabel.text = newLabel
  })
  .disposed(by: disposeBag)

Use weak or unowned self when callback includes self:

myModel.statusLabel
  .subscribe(onNext: { [weak self] newLabel in
    guard let self = self else { return }
    self.saveNewLabelSomewhere(value: newLabel)
  })
  .disposed(by: disposeBag)

func saveNewLabelSomewhere(value: String) { … }

Note: you might want to use simplified, pretty syntax:

myModel.statusLabel
  .subscribe(onNext: saveNewLabelSomewhere })
  .disposed(by: disposeBag)

… but that would create the same problem.

Be careful with ViewController lifecycle

What time for binding is the best?

In most tutorials I have seen an example of doing all ViewController setup in ViewDidLoad. It’s comfortable, you do it once, when ViewController is removed from the memory, it will clean up all resources, that’s it. But in reality I noticed 2 things:

Users tend to leave your app running in the background,
Usually you don’t need to compute anything on screens, which are not visible at the moment.

Those observations led me to the conclusion that a much better option is to do all bindings in ViewWillAppear and to clean the disposeBag in ViewWillDisappear. That way you only use resources for what’s needed on the screen, and you explicitly know when the subscription is finished. It helped me to follow the subscription flow in the controllers.

Subscriptions can be accidentally duplicated

Sometimes you will need to subscribe more often than once for the screen - like in viewDidLayoutSubviews. In such a case watch out to not to leave zombie subscriptions behind! Example:

override func viewDidLayoutSubviews() {
  model.uiRelatedStuff
  .subscribe(onNext: {...})
  .disposed(by: disposeBag)
}

What happened is viewDidLayoutSubviews probably was called a few times on screen load. Maybe another few times after the user rotated the screen. But the disposeBag is still alive! The effect is we have few copies of the same subscription. You can expect some bizarre side effects, like duplicated API calls.

Long story short: make sure you subscribe once for every time you need to, it’s not obvious.

Don’t reinvent the wheel

RxSwift library provides us with many special types, or traits. You need a warranty that call will happen from the main thread? You need to share effects? Before you write another few lines of code, check first if you could use a special type created for that purpose! I won’t be describing all of them here, check the docs:
https://github.com/ReactiveX/RxSwift/blob/main/Documentation/Traits.md
https://github.com/ReactiveX/RxSwift/blob/main/Documentation/Subjects.md

On the other hand, don’t use BehaviorSubject everywhere now - make sure a simpler type wouldn’t do. Sometimes less is more :)

Yes, you should test that, too

I must admit: writing tests isn't my favorite part of the job. But I found out testing Rx is simpler than I thought!

The easiest way to think of it for me is: you test the Rx element by observing like you would do normally. You just use fake the subscriber. And what you are actually testing is a collection of events emitted (value + time).

The example:

import XCTest
import RxSwift
import RxTest
@testable import MyFancyApp

class PLPCoordinatorContentModelTests: XCTestCase {

var scheduler: TestScheduler!
var disposeBag: DisposeBag!

override func setUp() {
scheduler = TestScheduler(initialClock: 0)
  disposeBag = DisposeBag()
  super.tearDown()
}

override func tearDown() {
  // simply reassigning new DisposeBag does the job 
  // as the old one is cleaned up
  disposeBag = DisposeBag()
  super.tearDown()
}

func testStatusLabelObservable() {
  let model = MyViewModel()

  // create observer of the expected events value type
  let testableLabelObserver = scheduler.createObserver(String.self) 

  model.titleObservable.subscribe(onNext: { (newStatus) in
  // just pass the value to the fake observer
    testableTitleObserver.onNext(title)
  }).disposed(by: disposeBag)

  // schedule action which would normally trigger the observable 
  // (see note below the snippet)
  scheduler.scheduleAt(10) {
    model.searchFor(query: “Kittens”)
  }
  // more events if you need, then
  scheduler.start()

  // define what you expect to happen
  let expectedEvents: [Recorded<Event<String>>] = [
  .next(0, "Inital Label Value"),
  .next(10, "Found Some Kittens!")
  ]

  // and check!
  XCTAssertEqual(subscriber.events, expectedEvents)
  }
}

Note about scheduling events: you also can do this in bulk if you need more events than one:

scheduler.createColdObservable(
  [
    .next(10, “Kittens”),
    .next(20, nil),
    .next(30, “Puppies”)
  ]
)
.bind(to: model.query)
.disposed(by: disposeBag)

scheduler.start()

let expectedEvents: [Recorded<Event<String>>] = [
  .next(0, "Inital Label Value"),
  .next(10, "Found Some Kittens!")
  .next(20, "Search cleared")
  .next(30, "Found Some Puppies!")
]

That’s it! You could describe flow above as:

Create test scheduler which will handle events
Create fake observable
Subscribe fake observable to actual value you want to test
Schedule some events
Run scheduler
Compare produced events to the expected ones

Worth noting - scheduler works on virtual time, which means all operations will be executed right away. The values provided (like 10, 20 in examples above) are used to check the order and match to clock “ticks”.

Brilliant resources about testing RxSwift are here:
https://www.raywenderlich.com/7408-testing-your-rxswift-code
https://www.raywenderlich.com/books/rxswift-reactive-programming-with-swift/v4.0/chapters/16-testing-with-rxtest#toc-chapter-020

Rx all the things!

… not. When you will feel comfortable with reactive concepts, you might feel an urge to refactor all the code to Rx. Of course, it’s nice and tidy. But it has few downsides: it’s hard to debug and you need to think about the time and memory. Also - equally important - not everyone is comfortable with that. So if your team is not ready, then it might be a good idea to hold on.

When and where to use it then? There are no silver bullets. If you have a simple component, like a TableView cell, then observables can be an overkill. But if you have a screen on which every time status changes you need to manually update 10 UI elements, then observing can be a charm. Also you can always apply RxSwift to one module of your app and decide upon further development.

After all, doing those small decisions and maneuvering between endless technical solutions is the most difficult and beautiful part of a developer's job.

Summary

I hope the list above is helpful to some of you. Let me know if I made any mistake! Also can you think of some other non-obvious RxSwift gotchas? Leave that in comment below :)

Effective business VS flu season

Noemi Rozpara — Tue, 03 Mar 2020 12:38:18 +0000

I decided to use the hassle surrounding the new virus to tackle a problem that has existed at least since I got my first job: how to resolve the conflict between business goals and health during flu season.

Important note

Remote work has its pros and cons. I graduated from an economics university, so I understand business needs. The content below considers both company objectives and developers' well-being.

Why do we even talk about this?

The topic might sound trivial or obvious. Yet, I believe everyone has been in a situation where they woke up feeling unwell but decided to go to work anyway. The excuses can be quite creative: "I have an important meeting today," "What if I need my sick leave days more in the future?" or "I didn’t perform my best last week; my boss will be angry." This list can go on indefinitely.

This type of thinking is familiar to me, but I believe it is a shortsighted approach. When you feel unwell right after getting out of bed, your coworkers will likely suggest going home after a few hours. Perhaps a better solution is to stay in bed. If you're well enough, take some vitamins and a blanket and try to work remotely. However, it may also be the case that you cannot do even that. In such a situation, be honest with your team and your customers. Putting immense pressure on yourself when you're really unable to deliver results won’t help your health or the project. Sometimes, it's better to ask someone else to step in, especially if something needs urgent attention. Also, don’t worry about all the possible sick leave days you might need in the future. Face the truth: with this approach, you're likely to use none until the end of the year.

Another crucial point is that health is everyone's responsibility. If you have a business meeting with a customer, will sneezing constantly help you maintain a good impression of your company? If someone catches the flu a few days later, you could be the one to blame. The same goes for your coworkers.

But I really need to go to the office

As I write this, nothing comes to mind as a good reason to be in the office while sick. But life is full of surprises, isn't it? If you must be sick in the office, take every possible precaution to mitigate the risk of spreading the illness or worsening your health.

During my trip to Asia, I had the opportunity to observe their culture. In Europe, we're bombarded with images of people wearing masks on the streets. In reality, people wear single-use masks primarily when they feel unwell. This way, they reduce the risk of making others sick when sneezing or talking. Unfortunately, I haven't noticed this habit in Poland. So, I want to encourage you: wear a sanitary mask in public places every time you feel sick. You'll be grateful if your neighbors and coworkers do the same.

Last but definitely not least, I urge you to wash your hands. I don’t mean the 0.000001-second splash of water that I sometimes hear, which terrifies me. Every time you leave the restroom, put something in the recycling bin, clean up, or come indoors – wash your hands. This practice can prevent you from getting sick while touching your face and keeps bacteria from spreading on various surfaces.

But business is business!

You just read how I encourage people to stay home, but it’s equally true that all company members are responsible for the success and achievement of business goals. So, how can we find a compromise between these two?

Take care of the remote work culture.
If you don't set any rules for remote work and treat remote days as exceptions, it is likely to result in mistakes that could harm the business. Even if your company operates in a field where remote work is challenging, you'll need to prepare for that possibility. Improving your communication flow is essential. Encourage coworkers to keep files organized and in a known location. Always confirm important decisions in writing (this has saved my life a million times). Consider the overall project management flow and identify areas for improvement. Ensure that there are no "information gaps" (e.g., does it happen that someone was supposed to relay information but failed to do so? Was any important info lost?).
Risk of making sick more coworkers than already are is not worth it.
Feeling frustrated because a customer is pressuring you while a team member is sick is pointless. Even if that person tries to work, they likely won't be effective anyway. Furthermore, you risk temporarily losing more team members, multiplying the problem.
Happy worker is efficient worker.
Maintaining good relationships with your coworkers makes it easier to manage projects and achieve success. If someone is grateful and happy, they will do their best to compensate for any inconveniences.
Know your team.
Sometimes, some employees take sick leave often just to avoid responsibilities. If you notice that a team member is absent more frequently than others, it might indicate an underlying issue. Pressuring that person to come to the office may just worsen the situation. Instead, try to identify the real problem and work on a solution together.
Customers are also human :)
While there are situations where significant amounts of money depend on project success or deadlines, we often imagine customers being angry with us. In reality, customers are human beings too; they may catch the flu and will likely understand your situation. Postponing a deadline by three days will probably be easier to manage than making a coworker unhappy or possibly making your customer sick (as discussed earlier regarding meetings).

We have just one health

In my opinion, human well-being should be our top priority. Personal health impacts all areas of our lives, including business. It is not feasible to push our bodies to the limit and expect to succeed. All the thoughts mentioned above apply to mental well-being as well.

Wrap up

Forcing yourself or others to work can often do more harm than good.
Explore the possibilities of remote work.
If you must be in the office, wear a sanitary mask and maintain top-notch hygiene.