The journey of a self-taught developer

About Nadia Zhuk
Nadia is a software engineer at Intercom, and was previously working at Zendesk. Before, Nadia was an English teacher, and journalist, until she decided to learn programming and enter the tech world.

Read the whole episode "The journey of a self-taught developer" (Transcript)

[00:00:00] Michaela: Hello, and welcome to the Software Engineering Unlocked Podcast. I'm your host, Dr. Mikayla, and today I have the pleasure to talk to Nadia Zhuk.

But before I start, let me tell you about an amazing opportunity that allows you, yes, you, to earn additional income!

Do I have your attention? Yes? Great. So, User Interviews is a company that connects researchers with study participants. And they especially are looking for developers that share their feedback on products.

Share your opinion with top brands such as Spotify, Adobe, Amazon and many more, and get paid. Most studies take less than one hour to participate and pay over $60.

So, sign-up today - It’s free - apply to give feedback for products that interest you, and make a nice side income. Additionally, you help to shape the future of the tools we als use. What’s not to like, right? So, hop over to userinterviews.com

But now back to Nadia. Nadia is a software engineer at Intercom and was previously working at Zendesk.

But not long ago, Nadia was an English teacher, a translator and journalist, until she decided to learn to program and enter the tech industry. Today she shares with me all about he self thought journey and how to successfully build a career as a coder when you're just starting out. So Nadia, I'm really excited that you're here.

Welcome to the show.

[00:01:01] Nadia: Thank you so much. I'm really excited to be, uh, on.

[00:01:04] Michaela: So how long are you now in, in the tech industry? How long are you now a programmer

[00:01:09] Nadia: coder? Yeah. It's been just over four years. And, you know, time really flies . Yeah. So,

[00:01:17] Michaela: um, I, I looked a little bit into a book because you wrote a book about your, your journey into tech, right?

So what you learned on this self-taught, uh, developer journey and, um, it, it starts with, at 25, I decided to learn to program. So what's really behind this story? Why did you decide to, uh, you know, start to program instead of, you know, following your career as an journalist, uh, English teacher? Mm-hmm. And translator.

[00:01:43] Nadia: Yeah. So, um, in my book I talk a lot, a lot, a lot about my background and how I was really non-technical before I started teaching myself to code. And you know, when I say I was nontechnical, I'm not being honest. Uh, you know, modest, uh, I was non-technical. So I was one of those in line people who are afraid of.

Change in the setting on their computer, you know, because they're afraid of breaking their whole machine. So, uh, for me, this change from being a journalist to being a programmer was a really huge transformation. So, um, the decision to switch gears didn't come from a very positive place. So actually, I was working as an editor at an independent news magazine.

Uh, You know, by that time and while we decided to close down the magazine, I kind of was in a very dark place where I didn't really want to continue working as a journalist anymore. I didn't want to be involved in use or politics. I was very disappointed in the whole uh, world, in this whole sphere. So I wanted to do something new and also I was.

Still living back home in Belarus, and I decided to move from Belarus to Poland. So at the same time, I was thinking of what I could be doing once I moved to a new country. So I needed to do something that would be, uh, easily done in a new country where I didn't speak the language, where I didn't know the culture.

So I realized full very quickly that I didn't really have many transferable skills that I could just take with. Go into a country which was, uh, you know, where another language was being spoken. So, um, I thought about different options and honestly I had a lot of resistance, uh, towards the idea of being a programmer, even though it was becoming, uh, You know, pretty obvious to me that this was a career that was wide open to anybody who had the time and the, uh, you know, the energy to learn it.

And I knew that this was probably the best bet for me in terms of starting a new life in a new country. And still I was very reluctant. I had a lot of misconceptions and a lot of stereotypes about being a programmer and. Pretty sure that I would never be able to become a programmer. So, uh, finally I managed to break down my internal resistance.

I started teaching myself to code, uh, bit by bit. It was very difficult. Uh, overall, it took me nine months to go from being completely non-technical to finding my first job in Poland. And at the end of those nine months, I was able to move from Belarus to Poland to start my first developer job, kind of kick my, uh, kick off my new career.

and also my life in the new country. And from then it has just been a very quick progression of events, different jobs. And uh, eventually last year I moved from Poland to London to start my current job. And it is just been such, um, an amazing journey and it's interesting to think of how much changed since then and how many opportunities the technical skills really opened up.

Yeah. And it

[00:04:31] Michaela: sounds like a, an amazing journey. And, um, so what would be interesting to me is, was it all internally? So, um, did you think about like, one day while programming as a career that would allow me, you know, to live the life that I'm dreaming of, you know, like in Poland and with the skills that I have right now?

Um, or is it somebody that you know, that somebody from outside told you, you know, actually programming, you know, would, would make a good

[00:04:57] Nadia: career for. . Mm-hmm. . Yeah. Actually, my husband was the one that really encouraged me to learn to code because he, uh, was, he is also a self-taught programmer, so he encouraged me and he told me that this is something that you can actually learn, that anybody can learn to program if they, you know, put in their time and the effort.

And of course, I also heard a lot of stories from people online who taught themselves to code, and I saw. The skill transformed their lives. But finally enough, I think that I, before that time, I didn't ever consider learning computer science or coding, uh, even though my, um, My brother, uh, has, has been a program professional programmer for all of his life, so almost 20 years now.

And I never really asked him what he did for a living. Nobody really understood it because like my whole family's not non-technical. So, uh, we just knew that he was like, you know, Good with computers, and that's how we knew about him. Uh, so for me, and also I, of course I met people who were involved with computer science, but for me it was always something very foreign.

So I think that a combination of a couple of factors came in, uh, encouragement from my husband, me really being in a place where I didn't know what to do next, and I just wanted to do something that would give me some kind of direction on purpose. Uh, and also something that, Allow me to relocate to another country and start a new life with a job that would be relatively well paid.

And also I knew that there were a lot of opportunities in the world of tech, that those jobs were in demand. I also heard of people really, uh, enjoying the profession and the opportunities that it brings. So, um, there is a lot of different factors. I think that a lot of it was kind of external and.

internal motivation was there as well. Um, yeah. Yeah.

[00:06:40] Michaela: Cool. And so how did you start, like did you go to, um, a search engine and just said like, Programming tutorial , or,

[00:06:49] Nadia: you know, uh, it's, it's nice to remember like what was the first, like, uh, first Google search term, but, uh, I tried a couple of different things.

Uh, I tried, uh, so for the first thing that I tried, uh, was, uh, Website called, uh, try Ruby, which is like a 15 minute tutorial where you can try out the Ruby language. And in general, why did I start with Ruby? Uh, which is not the most popular language and it's not something that most people start with. So I had this friend who actually told me about Ruby, this great programming language.

He said that it does. Meta programming. Uh, I had no idea what it was, but he was like, it's really cool. Then there is also rub rails, which is a framework that is very easy to learn and to, that allows you to build websites very quickly. So I heard this and I was, uh, excited about it at that point, but also I, I think I did the Google search and I looked.

At what was the most popular programming language, right? And it was JavaScript like it is right now. So I actually tried learning JavaScript first before I properly learned Ruby. It was a complete disaster. I couldn't understand anything. Um, I. Went through some tutorials on YouTube, had no idea what they were talking about.

Almost gave up on coding. Uh, thought that maybe I was too stupid to do this. But then luckily I decided to try Ruby and to try this other language and other framework. And this was the moment when I found the tutorial that worked for me that, um, Showed me that there was some hope for me, you know, that I could understand something at least.

And this is when it started. And then I think from there it was easier for me because I, once I understood the basics of programming in rub rails, I was like, okay, now I understand that I need to, you know, also, I did like tutorials for HTML and css, um, on, uh, code Academy and website like this. So I was learning the basics of web development.

Um, and this is how it started. And afterwards, once I underst. There were, you know, there was such in success, there were some several languages. Uh, once I understood the basic words and terminology, I was able to search for more tutorials and for more books. I did a lot of my study actually through books.

Um, and that's how, that's how it went for a while. Then I went into the, you know, job search mode that I built, the type projects and portfolio. Uh, and that was kind of another story, but I don't, I can't say that I had. Organized, uh, curriculum because it was all done by me. I didn't really have like a teacher or somebody who would be guiding me all the time.

So it was mostly self-guided and I think that it worked very well for me, but it was also very difficult. Um, I'm going to lie. Um, but unfortunately I didn't really have any other options at that time. I couldn't afford to bootcamp. I didn't want to go to college, so that was the only option that I had.

And. glad that I kept pushing through . Yeah, it

[00:09:38] Michaela: turned out great. Right. So what's the first job that you then apply? Is it, um, a full, full developer job, or was it like an internship or, um, yeah. What, what kind of job do you, did you feel like you

[00:09:50] Nadia: could handle? Uh, yeah, so I think that like many people, when I was just learning to code, I felt that I wasn't really ready to apply for jobs because objectively I didn't really know that much.

And I'm saying this now because I now know how little I knew at that point. But at that point I didn't really know how, you know, , how poor my knowledge was . And also I was living in Valis and I was kind of, um, I was feeling that, you know, I really need to move, you know, quickly. And there was this. Pressure that I felt, um, that I need to do something quickly and I need to get moving.

And I think that this kind of pressure really motivated me to ignore my imposter syndrome a little bit and become more confident. So I felt that I wasn't ready to apply, but I also know that nobody feels ready to start applying for their first job. So I just started applying. At first I had those ideas about like a dream job, a dream city in Poland where I wanted to leave.

I quickly saw that this was a little bit delusional because nobody would even talk to me. Um, yeah. Cause I was a foreigner. I didn't have, uh, any experience. I didn't really know much. So people were just, uh, replying very politely that I should first get commercial experience and then go back to them.

Yeah. Which was like, okay. But how, how can I do that? . Oh yeah, . But then I changed my strategy. I decided that I need to be creative. I need to start a plan to places where nobody wanted to work instead of places where everybody wanted to work . So I, I started looking for no, like, no name, job boards, and. Like cheaper job boards, not fancy ones.

Uh, for companies that were smaller, they didn't really have much of a website, like small web development studios, uh, located in small towns in Poland. And uh, those jobs were really much more open, uh, to outsiders, I would say. And there was less competition. People started replying back to me. Some employers were very interested in me.

Some were like, we will help you with your visa process and all of it. So it. Change of sim. Um, and then eventually I talked to a couple of companies. I sometimes people ask me like, what was their first interview process like? But there wasn't much of a process because not that many companies were interested to interview me at that point.

So, and then eventually I found a company, they were looking for an intern. In Warsaw, and they said that I passed the interview and they said, okay, you can come over for a one month in, uh, internship. There were no promises made. They weren't like a formal like job offer or anything like that. So it was very, uh, you know, uh, It was, in a way, it was a little bit risky because I was moving to another country for just one month internship without any guarantees.

But for me, I felt that my intuition was that it's right move. So I decided to take, uh, to take this offer, came to Warsaw past the internship, and then I was offered kind of a full-time position and it was a full stack development and rub rails and uh, JavaScript. So that's how it started. Uh, yeah.

[00:12:42] Michaela: Yeah. So sometimes you have to take your chances, right?

[00:12:46] Nadia: Yeah, cool. Yeah, exactly. I remember that. Sorry. Yeah. No, no, go ahead. Yeah, yeah. I remember that afterwards, one of my colleagues who is a Polish, uh, native, they asked me, why weren't you scared to take this offer without any guarantees? There was no like relocation package or anything like that. I just. Took my bags and took the train

So, um, I said that, I was like, I didn't know. I didn't feel that it was that risky. But I think that to a lot of people, it seems like a future risk. But I would say that if you are just starting out, you, sometimes you need to take the risk. And if you are getting an offer to work, maybe you should take the risk because you never know when next offer will come you.

[00:13:23] Michaela: Yeah. Yeah. Yeah. And I mean, I think you also drop up properly a little bit, and now you are in London, right? Working for Intercoms. Yeah. And now you are working for one of the companies where people want to work, right? . So, yes. Um, was that, was that your plan where you're like secretly syncing, like, oh yeah.

So this is the entry level job and then I have some experience and then I'm obviously improving my chances for the next time I'm applying and people will be more interested in working. .

[00:13:51] Nadia: Mm-hmm. , I, I can say that I was like planning that far ahead. I, at that point, I was still interested in getting the experience, the professional experience, working as a developer.

I wanted to see what it was like to be a developer and also to learn to code properly. I still felt that I wasn't really a coder because it was just, Doing my own thing, uh, at home without any cooperation. Yeah. So I was just interested in doing the job. I can't say that I had like any grand plan that, okay, I now have this experience and then I will go work in Google.

I was kind of taking it, uh, one day at a time, really, and I spent quite a lot of time working in my first job for around like nine months I think. Uh, and then, uh, I got gained a lot of experience. I think I learned so much at my first job, like really grateful, uh, for the people who. Took the chance to hire me and, uh, who taught me so much, my colleagues, and it was just an amazing experience in terms of how much you can learn, you know, while you are start working with other developers.

It's, it's just a whole other level. And then afterwards, when I saw that it was kind of time for me to take on another challenge, I started looking for another job, and then it was a very different process, as you said there I had. More interviews to go to than I could, uh, have time to go to. So it, it was a completely different story.

Like I was a completely different person, uh, just a few months after I started working. So, you know, for everybody who's listening to this and who just wants to break into tech, it won't be like, if you're just looking for a first job, it might feel that it's. A very hard process, but afterwards it becomes so much easy, so much easier to change jobs, and this is why you will see a lot of engineers actually change jobs pretty often, uh, because there are a lot of options and people can afford to look for a place that suits them best, I would say.

Yeah.

[00:15:35] Michaela: And so you were talking about it, you learned so much. So how did you learn? Did, did they do code reviews, for example, in your first job? Or how did you, did you do mm-hmm. care programming or how, how did their learning take place in that first

[00:15:46] Nadia: job? Yeah. . So yeah, it was a small company, so we didn't have like a formal concept of a body as we have right now, like in bigger companies where there is somebody who is like attached to you for your first few weeks and who is responsible for helping you on board.

So there was a person who was helping me, uh, but I would say that it wasn't like as formal roles as, uh, it is in bigger companies. Startups and smaller companies are much more agile in this respect. But there was somebody who was helping me, so we did a lot of para programming together. Uh, we also did code review, so I was learning, so this was the first time when I learned about what code review was like, how, um, GitHub collaboration looks like.

So there was a lot of learning, uh, in that respect, I would say so. So this was the first time when. Like seeing like merge conflicts and things like that. So that was pretty, um, incredible. But yeah, I think that in all of the companies where I've worked, code reviews have been a part of the development process.

Like, um, yeah, at Wish Place, like you could only merge something if it has been through code review. Uh, so I think that from the very beginning I had become used to. You know, sound engineering practices and, uh, knowledge sharing within, you know, uh, within the group of engineers. So, um, yeah, I think that you can learn quite a lot while prep programming and code reviews.

This is such great, uh, processes. And also I was doing a lot of self-study, so after work mm-hmm. , I would, I would watch tutorials, I would. Continual reading books. So the first five months, I would say of my first job, it was just learning nonstop. So weekends I would also code and afterwards I would code like all the time.

So it was very intense. Um, and, uh, yeah, but like I could feel that my knowledge was expanding every day, especially I think things like testing. Uh, I, I would say that I'll learn much more about tests while working on a real, uh, production app than I would at. . Yeah. Kind of understanding the value of task, I think, uh, was brought very, was made very clear to me while I started working as a professional programmer.

Mm-hmm. .

[00:17:50] Michaela: And so, uh, you touched a little bit on, um, engineering practices. So what about Intercom? What are the engineering practices there? And, um, they are probably, you know, what's the philosophy? Is it like mm-hmm. , um, High quality or, um, is it moving fast and breaking things a little bit more like Facebook?

So, so what's the philosophy there? Mm-hmm. . And what are the engineering practices that you, that you have at

[00:18:14] Nadia: Intercom? . Yeah. I would say that Intercom has very interesting engineering practices and something that, um, I needed to kind of get used to a little bit. So the philosophy is a lot about shipping fast, but also shipping safe.

Mm-hmm. . So, um, a lot of work has been done on building this culture of everybody trying to ship fast to learn. So the idea that we have is that the only place where your. Meets the infrastructure and meets the real customers is production. So there is only so much that you can learn with, uh, tests and like pre-production environments like staging.

So production is the place where the real stuff happens and the. Goal here is to ship as often and as fast as possible so that we can learn as fast as possible and we can iterate on the feedback from customers. And then if something is wrong, we can roll back and, um, fix it or improve it. So this is something, so a lot of work has been done so that this it, it works very organically and very quickly.

You get used to this and then you don't really notice. Fast you actually ship and how fast the value comes from your code to the customers. So, um, but as I said, a lot of work from different teams is being done so that this happens so organically and without any friction. I would say that a lot of work is done on the infrastructure so that it's very easy and quick to ship.

So it takes around like 12 or 15 minutes, I think 12 minutes to ship your code to production, uh, depending on, you know, various specs, but it's very. Then there is also a lot of instrumentation around how you can roll back the changes if you know if something goes wrong. There is culture of being responsible for what you ship.

So like if you need to ship something and you need to, you know, live work in five minutes, you just don't do it. You wait until next morning because you don't really want somebody who doesn't know anything about your code to be responsible to decide whether this needs to be rolled back or not. So things like that.

And also I would say that one of the most, um, amazing things that we use at Intercom is the concept of feature flex. So, which is this feature that allows you to. , um, release something to a production, for instance, like a new feature, and then, um, make it available to only a subset of customers, uh, who have this feature flag turned on.

Then you can learn from the customers what's working for them, what's not working for them, and then you can change it or fix it or, you know. , roll it back completely. And then once you are sure that this is what you want to happen for all the users, you can just flip on the feature flag for all the users.

But then you can always, uh, turn it off and it's done with just one click, which is something that I think really helps people to make decisions very quickly. And it kind of creates this, it removes the sphere, you know, from shipping to production, you know that there is always this FALive mechanism. If something's wrong, you can just throw it back or you can just turn it off.

Mm-hmm. and. . I think that this is one of the secrets to how we are able to ship so quickly, but also ship safe. .

[00:21:23] Michaela: And so, uh, one, one thing is feature flags, right? So it rollbacks feature flags, which help you undo or test out something for maybe couple of people and so on. But, um, do you have also monitoring in place what kind of software?

And is it, is this something that, uh, developer also goes and, you know, has, is it your, Responsibility to go and look at the monitoring software and maybe you have some observability software also in place. Um, and, and are you, you know, are you responsible for looking at that?

[00:21:54] Nadia: Uh, yeah, I would say that, uh, there is quite a lot of the, you know, uh, engineers whose, uh, primary focus is actually to improve the state of observability that we have at the company.

So the, so that the instrumentation observability is always kind of top of mind, but also it's the responsibility of each engineer to observe, um, metrics and dashboards. Uh, and those tools, you know, there are various tools I think that, um, that. every company has has their own, and also they change sometimes when needs change.

But I think the tools are changed. But the idea here is that if you ship something, it's your responsibility to monitor dashboards and to make sure that your change didn't really break something really seriously. Um, so this is definitely something that is important, but also there is, uh, you know, there is on call, um, and um, a lot of, I think that the culture is also very important that people understand.

incidents happen and things can break, and there is a lot of alarms been done to remove the fear, uh, from shipping to production. And I think that generally it's, uh, . It's a great way to encourage engineers to ship fast and kind of to ship value, especially if there is, you know, if there is a bug, for instance, and the customer submits a buck report.

If you know that there is a culture of shipping very fast and it's very easy, you can just go open your editor. You can. find a, you can make a fix to this box and you can just ship it in auto production. And then like 30 minutes later, you message the customer saying that it's been fixed. And it just creates such an amazing experience for the customers, uh, in, in contrast to some other, you know, uh, companies where it might take you days, for instance, three months to fix Yeah.

Three months. Yeah. So, and it, it creates a very different, um, yeah. Environment, I think for engineers, but also, clients as well. Yeah. Yeah,

[00:23:46] Michaela: that's true. So you mentioned the body concept. Is that something that you have at Intercom? Do you have some peer programming going on? Do you have code reviews? Mm-hmm.

how does collaboration look like?

[00:23:57] Nadia: Uh, yeah. We do have a concept of a buddy. So if you join as an engineer, you will have a buddy like your mentor attached to you for your first. However many week settings will come. So the buddy is somebody who will guide you through your onboarding project. So we kind of want to help people feel as comfortable as possible, as quickly as possible, and to start shipping value to production also very quickly.

So, um, it's, I like this concept so much because the goal of the body is actually for. Uh, few weeks is their primary goal is actually to support you. And this makes such a huge difference because if you don't have somebody who is kind of attached to you, then you might feel uncomfortable asking somebody questions because you know that your questions, they, uh, take this person away from their goals and their junior work.

But in the case of having a buddy, this person is there to help you. So it, it shifts your mindset so much. And, um, I have been a buddy as well for new engineers and I had a buddy when I joined as well. And, uh, for me personally, when I was a buddy myself, uh, I made it super clear that, you know, I told my mentee that, you know, I am there for you.

I'm available. Please message me whenever you need any kind of help. And we did a lot of, uh, pair programming together. Uh, we always do code review. So I think that code reviews is also a big part of learning, um, for engineers to observe how others do things, and we don't really have any. Um, so basically everybody is encouraged to code review, to do code reviews for other engineers and to review open pool requests.

So a lot of collaboration happens there. So for me, code reviews are something that is very natural and a great part of learning, uh, about the company, but also learning about engineering. . Cool. Yeah.

[00:25:48] Michaela: So, when you talked about, um, you know, programming, being a buddy and, uh, reaching out to each other, are you doing that all remotely or is it, do you have the culture of going into the office?

Are people coming from different places? Are you distributed or how does that work?

[00:26:06] Nadia: Um, yeah, so initially when I joined, I think it was mostly, yeah, it was mostly remotely. Um, then the office kind of opened up more and I started coming into the office to, um, Just trying to think what it was like. Yeah. I actually started coming to the office pretty often to pair program with my buddy back then.

Uh, and it made a huge difference. I would say that we, at first we tried pair programing remotely, but. because, um, intranet speeds in London aren't always, uh, great amazingly enough. So the upload speeds, they aren't always, uh, up to the standards. So the screen sharing and para programing remotely wasn't really working.

And I think that not everybody enjoys doing it remotely. So, uh, sometimes you can feel that there is like this weird, like, I don't know, tension and it's just not very productive. And there is frustration, you know, when you're trying to explain something and you see that you're not able to do it remotely.

Doesn't make it for a good experience. So I started going to the office and I started pair programming with my body in person. And I would say that this was, um, a game changer because we were able to pair program on the same computer, just like we had, you know, each of us had, I think our own keyboard and mouse, or maybe we shared one, I don't remember.

But there was one screen and we were together. So it was much easier, easier. And then afterwards, uh, there was a combination of that. Uh, lately we've mostly been. doing para programming remotely. Um, we have this, uh, I think it's, it's kind of a hybrid approach so that for most of the week people are remote and then, uh, they come to the office in London for, uh, like one or two times a week.

Um, most people are, people are based in London, so, um, it's, uh, , it's relatively easy, although commute in London is never easy. . Yeah. Um, but yeah, um, that's the how we try to do like team days when, uh, all of us gather in the office and work together and it's good. It's very good for collaboration and team bonding.

So yeah, that's how we approach it. Yeah.

[00:28:11] Michaela: Cool. And so do you work, um, as a peer developer team or do you have like squads where, you know, pro uh, product manager is there as well? A product owner maybe? Mm-hmm. , you know, a tester QA people. How is, you know, what, what's the setup of your team? .

[00:28:27] Nadia: Yeah, so our team is, uh, consists of software engineers who, like everybody on the team is full stack, so we don't have the distinction into front end or back end.

So everybody's expected to be able to kind of do the backend work and front end work on the same day. Uh, and then we also have a product designer who is on our team, uh, product manager attached to our team and an engineering manager. So our team kind of delivers features. Together, we don't have a dedicated uh, QA engineer.

Programmers are expected to QA their own code and write automated tests for all of the code. I think there is a lot of like a strong culture of testing. Like you can't really ship anything to production without writing tests. Mm-hmm. , for instance, you know, if, if there is a bug and you ship a bug fix, you do need to write tests that would catch that back because otherwise it doesn't really make much of a.

uh, my sense because mm-hmm. , this is just a quick, quick fix and we kind of want to encourage more tests that would potentially. Catch those box in the future. That's how, that's how it works. And yeah, having a dedicated pro product manager and dedicated product designer makes working very easy. I think that also the different thing about, uh, Intercom is that the title that engineers have is actually not software engineer, but product engineer.

And I think that, uh, the emphasis here is that as an engineer you should be also involved in discussions with product managers and designers. And there is a. Uh, autonomy when it comes to building features. Uh, so it's not, it's, it's not, you know, the process where like the designer says that's the way it has to be and the product manager says, you have to do it this way.

There is still kind of, we are also asked our opinion and we are also expected to bring. Forth ideas to, you know, when it comes to building products, uh, because we also interact with customers through being on call and we observe how, um, not directly with customers, but through customer support, uh, agents, we see which problems people have, uh, using the product and what works for them, what doesn't work for them.

I think this also informs our thinking in a way so that software engineers also. some input. So, um, it's, it's a role that is, I think, a little bit different than software engineering roles can be at other companies.

[00:30:48] Michaela: Yeah. And so what about metrics and measurements? So I would like to know, do you know, are you aware of some metrics that, you know, um, measure, for example, performance?

Or do you have like performance reviews? Do you have like KPIs that you have to achieve? Mm-hmm. ? How, how does that all look like? What is successful? When are your successful engineer at inter.

[00:31:11] Nadia: Yeah. Uh, I think that it's a, it's a pretty similar standard process to a lot of companies of a bigger size. So we have Proformer reviews, uh, twice a year, every six month.

And they're, uh, um, since this is a bigger company, they're a very. Specific requirements and expectations at each engineering level. So there are different competencies around which you are measured. So there are competencies around like execution, uh, meaning how fast you can ship code, how efficient you are, and how much value you can bring.

But also there are other things like communication, uh, leadership strategy. And so how you are able to teach others, help others. Also, how you're able to, um, kind of participate in plannings. Um, bringing forth business value. So it's a very, so there are a lot of requirements around different parts of the job, not just, uh, writing code, but also communication, uh, strategy, partnerships and things like that.

So you're measured along all of those different, um, eh, Competences. And in order to be promoted and to go to the next level, you need to, uh, be exceeding expectations of your current level for a certain time. And then once it's clear that you have done it, you can be promoted to the next level. But of course, since, uh, this is a bigger company, all of this has to be documented.

So there is a whole process where you need to show what you have actually achieved during the previous six months. Uh, so that. , it's possible to make sure that everybody is being evaluated fairly and there are no biases and kind of favoritism involved so that you know when somebody from the outside can look at.

Each engineer who is at the same engineering level and be like, okay, it makes sense that they're all at the same level because they are working on approximately the same tasks and the same complexity of tasks. So, um, yeah, that's kind of, that's the process. Uh, it is, uh, well documented. There is a lot of information about what is expected at each level, and once you join your engineering manager, Has a couple of discussions with you where you talk through the documents around engineering levels, what it would take you to be promoted, you create a plan for you for the next six months, um, what you need to do to be promoted, what you need to do to stay at the current level.

And then you check in with this document, uh, every once in a while preparing for the performance interview. Mm-hmm. and yeah, that's, that's how it works. More or less. So. So have you

[00:33:42] Michaela: been through that process again and have you been promoted? , how did that

[00:33:46] Nadia: work? Um, yeah, for me, I've been through one of the process, um, haven't been promoted yet, uh, but yeah, uh, the process was pretty straightforward.

I would say. I was, uh, I'm kind of used to this process from my previous job as well. Um, yeah, it's just, uh, you prepare a document, basically talking about your achievements and um, kind of what others about the growth.

[00:34:09] Michaela: Do other people like your colleagues also, is it like this 3, 360. Uh, degree or however it's called

We,

[00:34:18] Nadia: we, we do, we do feedbacks for each other. So before performance review, you uh, get feedbacks from your colleagues and you also write feedbacks for them. So the concept is kind of called they always on feedback so that you are always encouraged to ask for feedback and to give feedback. So for instance, if you see somebody doing really well at, you know, in some project you are encouraged to just drop.

Feedback. You don't need to wait until the next performance of cycle to do that. And then all this feedback is gathered in a special, you know, uh, feedback system. And then once you're preparing for your primary to, you pull that, um, feedback from that system to your performance of your document. And it kind of creates this.

Um, so the idea here is that there is a story, uh, of you. So for instance, you joined the company and. Um, you need to tell the story of like what happened since you joined, so how you onboarded, then the project that you delivered, what you learned, how you grew, and things like that. And there is a story from where you came from and kind of where you are right now and also what you plan to do in the common, uh, six months or so.

So, uh, yeah, this document is kind of your story. looking at it, you should be able to see whether you are measure your meeting expectations at your current level. Maybe you are not meeting some of them, maybe you are exceeding some of them. And then, um, you know, there are decisions that are made like who's promoted, who is not promoted, but the they, those are kind of complex and also not something that I'm involved with.

Um, but yeah, that's more or less how it works. . Yeah.

[00:35:47] Michaela: And so how do you like, like London? So you have been now, uh, you have been moving to Poland, now you're in London. So you have seen different countries, different cities. Yeah. Um, how do you like

[00:35:57] Nadia: it so far? Um, I was a little bit scared of moving here because I had never been to London before I moved here, which sounds pretty crazy, but, um, I just never really got a chance to come here for various reasons.

First, the Visa was very hard to get. Then there was the pandemic and then, um, and then basically I decided to relocate and that chose London. So, um, I was scared that I. I would hate it. Uh, but basically enough, like I'd never had a day where I was regretting the decision to come here. So, so far it was difficult at first to get used to it because it's such a huge city and I had never lived, you know, in a huge city like this.

The distances and the whole rhythm of life, I think, um, Is very different from what I used to, but mostly the scale of the city I think was pretty shocking. Like when you think that, and the joke in London is that no matter where you are and no matter where you need to go, it always takes at least 45 minutes.

And it's, it's true. Like even if you are in the city center and you need to get to another place in the city center, somehow it takes 45 minutes. It's. It's magic. So it is difficult, but also I think that the energy that you feel here is really great. So for anybody who has never experienced life in the big city, I would, I really recommend coming to leaving a place like London because there is so much opportunities in terms of work, entertainment, people that you can meet.

Uh, there are so many different cultures here. So for instance, me being from Eastern Europe, I don't really feel like. Foreigner or somebody who's like super different from everybody else because everybody here is an immigrant. You don't feel, um, like the other, you know, like you do some countries where there are not that many immigrants.

Um, and it's very easy to feel at home and comfortable here. Um, it also is fairly, it's much safer. I feel much safer here than I thought I would. So, so far I really enjoyed and also the experience of working in a very international. For me has been very transformative. It has been challenging, um, working with people from all over the world.

Like my team has people from all over the world, from Argentina to China, to France, to Sweden, and it's all involved. One team. We have a couple of British people to be fair. Uh, so , it has been, you know, a learning experience for me, uh, getting to know cultures and how they interact in work settings. It has been one of the most, I think, eye-opening things so far.

[00:38:26] Michaela: Yeah. I think this would be a, a complete, uh, other episode that we could have just on, uh, cultural experience. Maybe we should do that. Uh, and really dig, dig a little bit deeper into, into what you think about it. And I don't know if you are aware of, um, the book, the Cultural Map from, uh,

[00:38:43] Nadia: from Mayer? Yes.

Yeah. If you, if you

[00:38:45] Michaela: see, yeah, you wrote it. Uh, you read it and, um, yeah. Yeah. Did you recognize

[00:38:50] Nadia: some of the. Oh, yes. So actually I also have a YouTube channel. So I actually recorded the video while after I read the book, this book that just blew my mind. When I read it, I started talking to everybody about it.

Like I just annoyed people, uh, with it. Cool. Because I saw, I saw so much truth in it. Yeah.

[00:39:07] Michaela: Yeah. Cool. So I will link, uh, the YouTube channel of yours as well in this episode. Very cool. Thanks. So cool. So my last question that I have for you, which, uh, because I also traveled a lot, um, um, throughout the world, uh, but for me it was.

Hard, the, the, the two people problem. Right? Like you have, you, you said something about the husband, so is your husband mm-hmm. in London. Has he been in Russia? How do you, how do you, you know, um, make it happen that you have, you know, that you're at the same place at the same time with the same visa and both having a job, which I think is not always that easy.

[00:39:41] Nadia: Yeah. Yeah. So, uh, we've been pretty flexible in terms of that and we've been kind of moving together everywhere. I think that once, you know, if you're married, getting the visa sorted is fairly easy. And the UK for instance, is, uh, a country where if you have a visa, then your spouse also gets a visa, which gives them full rights, uh, as you do to work, uh, as well.

So, yeah. It's been kind of mostly, you know, uh, getting adjusted to various circumstances, but I think we are both working from, you know, mostly from home as software engineers kind of doing our own different site projects. So, um, for us I think it, it helps that we're both very, um, Flexible. And also we both had this idea that it would be very cool to live in various places.

You know, that we live in certain location for a couple of years, then we moved to some someplace else. And I think if my husband actually had this idea kind of before, you know, before, um, before I had it, uh, so we are just aligned on this, but I think that it's not. Possible, especially if people have jobs that aren't in software, right?

Yeah, yeah. Software makes it easier. It's true. Yeah. Yeah. I think that like if you're a software engineer, it's easier to find ways to make money online and kind of arrange your life that is not attached to a certain location. But also it helps to be very, um, kind of flexible and being able to get used to new environments quickly.

Not being attached too much to. Location where you grew up? Um, yeah. Um, but it's been, I think, fairly smooth for us. Yeah. Cool,

[00:41:17] Michaela: cool, cool. That sounds super inspiring from a non coder, non-technical person to, you know, a rising stories intercom, uh, I would say, and, um, YouTube and everything. So I think you definitely inspire a lot of people.

So I hope that many, many people listen to this show and, uh, realize that they can also start, you know, their coding career or I think a lot of people that listen to my show are already programmers, but maybe at the beginning of. Their career. So, um, is there something that you can, um, tell, you know, my audience can tell my listeners, um mm-hmm.

something that you learned and that you think would be valuable to, to

[00:41:54] Nadia: them. Yeah, sure. So I think that for somebody who is just, uh, thinking of getting into tech, I would say that uh, it's possible, it might seem that it's too hard and that you are not smart enough, that you are too old. It's not true. Uh, this sphere is so, is permissionless, like anybody can join it.

Uh, provided that you have time and energy to learn it. For people who are already in the industry and just starting out, um, I would say that it might seem, again, overwhelming and challenging. It might seem that it would never get. I can say that it does get easier with time. Um, and uh, it's just that the challenges change.

Like as you grow as a software engineer, you're faced with other challenges, but it still becomes easier once we get more experience. And then, uh, another team that I can share with, Somebody who is either beginning their career in tech or maybe already experienced is that it always helps to find some support and find a mentor.

This is the advice that I now share. So I wish that I found a mentor in tech, uh, in early in my journey. Having somebody who can help you and guide you is just so incredibly helpful. And in general, having support from somebody who's doing the same thing as you are is always valuable and it. Completely transform your whole experience in tech.

Although tech is a challenging place, uh, and can be lonely, but I think that it doesn't really have to be that lonely.

[00:43:13] Michaela: Yeah. Yeah. Cool, cool. Thank you Nadia, so much for being on my show, sharing everything with me. It was very interesting to talk to you and um, yeah. Have a good day.

[00:43:23] Nadia: Thank you so much. Have a good day too.

Bye bye-Bye bye.

[00:43:28] Michaela: This was another episode of the Software Engineering Unlocked Podcast. If you enjoyed the episode, please help me spread the word about the podcast. Send the episode to a friend via email, Twitter, LinkedIn. Well, whatever messaging system you use, or give it a positive review on your favorite podcasting platform such as Spotify or iTunes, this would mean really a lot to me.

So thank you for listening. Don't forget to subscribe and I will talk to you in two weeks. Bye.