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.

Nadia Zhuk shares how to build a career as a self-taught programmer successfully. She learned to program all by herself and changed her career from being an English teacher to a full-stack developer.We also talk about:

[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.