MDCS Hiring Tips - all you need to know

At one point in time I decided to sit down and write out every possible advice I could think of, that could help you get hired by Microsoft Development Center Serbia (MDCS). I had no clue how many posts would there be so I just kept writing. Turns out I had nine posts in me :)

I would usually share them by telling people to search for #mdcsHiringTips hashtag, but over time I learned that it's quite a hassle to do so. Doubly so given that LinkedIn doesn't really sort posts chronologically. So, over one fine Thursday evening, I had some minutes free and I decided to stitch all posts into one gigantic article. And that's what you are looking at now.

Each headline represents one post I published. And the writing style follows. Do keep in mind that I was publishing one post per few days, so it wasn't "all at once". You've been warned!

P.S. You can find all relevant links at the end (at Part 9). Enjoy!

Part 1

Since we are hiring for quite a number of engineering positions in Microsoft Dev Center Serbia (MDCS), I thought it might be useful to share some first-hand experiences, given that I went through the same process a bit over a year ago. I'm not sure how many posts there will be, but I will make sure that each one uses the same hashtag - hashtag#MDCSHiringTips. What this means is that by clicking on the hashtag, you should be able to see all the messages that I posted (do note that this is the FIRST one).

For starters, I think it makes sense to share where you can find the open positions. You can always find these on LinkedIn Jobs (just search for Microsoft and narrow down to Serbia), on Microsoft Careers Page (again, filter down to Serbia if you're interested in MDCS) or by following people from Microsoft who regularly promote these jobs.

One question that I usually get asked is - "does it really pay out to invest yourself in this journey?" and trust me when I say - YES! It ABSOLUTELY DOES. In every possible aspect. Take my word for it!

Now let's focus on the interview process itself. Keep in mind that your mileage might vary, but for most of the engineering positions the process is more or less similar. Usually it works as follows:

1. Screening call -- you go on a call with a talent acquisition specialist whose purpose is to help you see if MDCS and yourself would be a solid fit. Here you will talk about your past experience(s), what you are looking for, what the expectations are, etc.

2. Codility test -- this is the well-known algo&data structs problem solving thing. You get 3 hours and 4 problems to solve. I will write more about this in the next post.

3. Three or four back-to-back interviews -- this is the last step of the process where you meet with four engineers (ICs and/or Managers) and you usually get one coding problem, one or two system design problems, and one free-form talk where you discuss mutual expectations.

4. Welcome to MDCS! :) The sweetest step of them all where all the hard work and preparation pay out!

Again, I have to emphasize that YOUR MILEAGE MIGHT VARY. You might skip some steps or you might be asked to do something else. This pretty much depends on the position you are applying for and the requirements for that position. So please do use this as a guideline and not as a rule of the thumb!

Finally, does it pay out to do all of this? YES! Trust me, it does. And once you go through it and hopefully get hired, do find me on 3rd floor and let me know how you concluded the same :)

Part 2

Previous post on hashtag#MDCSHiringTips outlined the Interview Process itself. Now I want to shed some light on the dreaded "algo & data structs problems".

Here's the thing -- what keeps amazing me about Microsoft and MDCS in particular is that you get a chance to work on some real heavy engineering problems. The complexity might vary, but the essence is the same -- you are expected to solve (tough) problems.

Which brings me to the essence of being an Engineer and why we hire Software Engineers and not Developers. Being an engineer means that you have a mindset and enthusiasm for tackling problems. Sometimes those problems are more clear and sometimes you need to spend weeks or even months playing with prototypes, reading through documentation, digging through (legacy) code, asking right people right questions and most important of all - being persistent and disciplined to push through. It's a tough but highly rewarding job. But what's really important to understand is that CODING the solution is the EASY part of it. What's hard is finding an optimal way to SOLVE a problem and that really includes number of skills.

I'll quote my dear friend Nikola ?ehovi? here, who put it just perfectly: "People think that Engineering in MDCS is all about taking well-defined and clearly explained tasks from a Kanban or Scrum board, and just delivering the results. And they really get dissapointed once they realize that the best you get is an explanation of a problem and you are absolutely expected to find your way out, regardless of the level you are on". This is really important because one amazing thing about MDCS is that regardless of whether you are entry-level Engineer, or a Senior or Principal, you are expected to know HOW TO SOLVE PROBLEMS. And that involves many techniques where coding is just one small part of them.

So why is this important? It's important because one good way of testing your problem solving, discipline, asking right questions and being persistent skill is by asking you to do what are usually referred to as "Leetcode" problems. The typical "invert the binary tree" or "reverse linked list" (in)famous problems.

Do we truly care whether you can really invert a binary tree or do all kinds of crazy things withing 45mins? Of course not. Hell you'd be crazy enough not to use Bing, Google or ChatGPT for that.

But what we DO care is whether you are persistent enough to push through from beginning to end, whether you are disciplined enough to keep solving problems even when you keep hitting the wall, how clear are you when communicating your thoughts and trying to brainstorm the solution with the peer and, most importantly - whether you know the basics of Computer Science.

So guess what? That's exactly what is demonstrated with the Leetcode/Hackerrank/Cracking the Coding Interview/whatever the hell is out there kind of problems. Reality of working in Microsoft and MDCS is that you will have to deal with unknowns on a weekly basis. Sometimes even on a daily basis. And you really need to practice that skill if you want to succeed. And hell, you have to love solving problems and puzzles, but hey - who doesn't? :)

Part 3

Third part of hashtag#MDCSHiringTips. As a reminder, you can read previous ones by clicking on the hashtag#MDCSHiringTips hashtag itself. This one will deal with preparation for Algo&Data Structs. problems, usually referred to as LeetCode/Hackerrank/Codility/whatever :)

As I mentioned last time, you will be asked to solve this kind of problems TWICE. Once during the Codility challenge, where you have 3 hours to solve 4 problems, and second time during the four-interviews-over-four-hours step (i.e. the last step of the process). So yes, you need to prepare for this and relying on the fact that you've been coding for years now is not enough. It's not enough because we understand and believe that you know how to do code, but we are more curious if you have what it takes to compete in the big league. And yes, that means - persistence, discipline, courage, verbal and CS skills.

I will share how I prepared and I'll offer some alternatives so you are free to choose your own. In my case, I started with "Cracking the Coding Interview (CTCI)" book, and if you don't have it, I can't recommend enough that you get a PHYSICAL copy of this book. It's not just about the content but rather about having a physical reminder of what you are doing and why you are pushing even when you are on the verge of giving up (which happened for me on a daily basis).

Aside from Algo&DS problems, this book offers incredibly valuable advice on how to prep-up for System Design and Behavioral Interviews, it discussed WHY big tech does these interviews the way it does (i.e. using these kinds of problems), and basically has tons of valuable advice. So, yes, get a physical copy even if you are going to use a PDF version.

I personally started with this book and the most value I extracted from it is gaining understanding of the BREADTH of the problems I needed to focus on. Mind you, I was in the industry for way over 10 years at the point and I honestly forgot about sorting problems, big O, binary trees, linked lists, hashmaps, walking the graphs, etc. So this book gave me understanding of WHAT I need to prepare for. This is IMMENSELY VALUABLE.

Next, I came to a sad realization that I couldn't solve a SINGLE problem from the book, which hits as hard as number of years of experience you have in the industry :) So it hit me quite hard that I couldn't solve even an EASY problem. And guess what - it might hit you the same way as well so don't say I didn't warn you.

With an understanding of WHAT I need to practice I rather soon moved to premium subscription on LeetCode (around 30 bucks per month; serves as a good reminder that if you are spending money you better be practicing as well). I found LeetCode more useful than CTCI book simply because it offered way more interactive way of doing problems and it had some cool stuff like debugger, hints, solutions, forums, etc. So, my advice - get a subscription if you can afford one!

So the first step I recommend is -- understand that Algo&DS problems are A MUST and that you likely have to practice them upfront. Get a physical copy of Cracking the Coding Interview (CTCI) if you can afford one and get a LeetCode subscription (if you can afford it as well).

Go through CTCI book to understand all areas that you need to cover (graphs, lists, sorting, big O, dynamic programming, etc.) and PAY ATTENTION to Behavioral part, how to prepare for interview, how to devise a plan, etc. DO NOT SKIP THIS!

In the next post I will discuss some more how I organized my time to prepare.

Part 4

Fourth part of hashtag#MDCSHiringTips. This time I'll share some practical advice on how to do Algo&DS problems (i.e. Leetcode/Hackerrank/Codility thing).

Here's some very practical advice that I personally followed and found to work:

- Set a timer to 30minutes. If you can't get to a solution within that time-frame, you are better of looking into the solution, evaluating what you missed and why and moving on. There's a reasoning behind it - you will be expected to do more or less the same during the interview, so don't waste time if you can't get to solution. Practice the timeboxing, take a short break and move on to the next problem. You'll get better next time!

- Practice saying your thoughts out loud. The thing is that the interviewer can't really know what's going through your head and all they see is silence. This calls for many problems, but one of them being the fact that they can't even assist you because they don't know what you are thinking about. My advice - practice VOCALIZING your thoughts and speaking loudly on what you are thinking about. It might sound crazy, and people around you might think you are crazy, but hey - it pays off!

- The more you do the better you get. Trust me. You will get better. You might fail at some problems today and tomorrow but in 7 days you will develop some new neural paths and that problem will be a breeze. Repetitio est mater studiorum.

- Own the language of your choice. You get to choose in which programming language you want to do these problems and there's a vast range of them. Go and check Codility to see what is offered. But thing to remember is - make sure that you know the basics by heart, because if you get confused on how to write a for-loop or how to access elements in array, you will doom yourself. It's not that interviewers care that much, but trust me - it takes mental toll on yourself and you will lose your ground. Hence make sure you know the basics of your language BY HEART. PRACTICE!

- Practice speaking in English. Solid chunk of interview will be in English, so it's better to prepare upfront by speaking it. Speak your thoughts in English. Practice "your story" in English. Practice communicating your problem-solving thoughts in English. It gets easier!

- Interviewer knows you are nervous. And that's OK. Don't feel bad about feeling anxious. Everyone knows how badly you want to nail this and it's totally OK to be nervous. Just make sure not to get blocked and best way to avoid it is to practice upfront as much as possible :)

So, in a nutshell - timeboxing, vocalizing your thoughts (in English) and practice, practice, practice!

Part 5

Fifth part of hashtag#MDCSHiringTips. Last time I discussed how to prepare for Algo&DS problems, and today I'd like to discuss the topic of how to stay motivated and to keep doing it, even when it gets to the verge of give-up. As a reminder, you can always click on hashtag#MDCSHiringTips hashtag to see previous posts.

So, the most common question of all - how do I stay motivated to keep grinding Leetcode/Codility/Hackerrank/Cracking the Coding Interview (CTCI) book? And the answer might dissapoint you - you don't :) Objectively speaking, and definitely from a first-hand experience, there's simply NO way to keep yourself motivated for prolonged periods of time; doubly so when you keep hitting the walls and not even being able to solve what you nailed last week (which happens more often than people think).

My advice? Forget about staying motivated about doing it, because if motivation is your primary driver - you will likely give up before achieving anything (kudos to the exceptional cases, though!).

So how do you do it? You do it by using a motivation as a SPARK to start doing it, but then you rely on building DISCIPLINE to keep doing it. That's the proper way for most (including myself).

What you want to do is build a routine and than stick to it. Day in and day out. And when you lose the motivation (it comes and goes and then comes again!) you want to rely on the fact that it's just part of your day to do it.

In my case, my routine was as follows: wake up around 6AM, make a coffee, sit down for 30-40mins to do ONE Leetcode problem, go to gym and then go to work. So it was literally PART of my morning routine and I just forced myself to stick to it. Eventually you build a habit.

The trick is to keep it simple. And I kept it simple by constraining myself to one Leetcode problem per day. I'd do more on weekends, sure, but the routine was - one problem per day and that's about it. Mind you, if I had additional time after work or whatever, I'd do some more, but ONE problem a day was what kept the trouble away.

The reason why it works is because it becomes part of your day. Just like going to uni or work is. You just HAVE TO do it before you do anything else. And eventually it becomes easier because your mind get used to it.

Do keep in mind that there will come a time when you will get in serious doubt. There'll be a time when you will NOT feel like doing it. There will be a time when you will feel like "why the hell am I wasting my time on this. I'm stupid enough and there's simply no point and I should focus on something that works for me instead of wasting days on this crap". There'll be all kinds of doubts and your brain will try to force you to do EVERYTHING in order to give up the practice. And that's where the routine and discipline have to come into play :)

Obviously, I'm writing this from a perspective of a guy with a full-time engineering management job, a wife and eventually a kid on the way, so I had to constrain my time. If you can afford more -- great for you! But DO NOT, and I repeat DO NOT skip today and plan on doing double tomorrow. That will NEVER work over the longer periods of time.

Good thing is that this will help you build discipline for solving other kinds of problems in the future. And yes, it does pay out. Trust me. And whenever you start doubting the process - trust me. It will work out. It always does :)

Part 6

Sixth part of hashtag#MDCSHiringTips. Last time I discussed how to keep yourself motivated to keep grinding Algo&DS problems. This time I will start discussing how to prepare for System Design Interview(s).

Keep in mind that your mileage might vary and whether you do get a System Design interview and what you will be asked is really dependant on the position and seniority that you are applying for.

So how to prepare for System Design Interview? I will share the materials that I've used and hints that I've found useful.

Let's start with resources:

- There's a GitHub repo called "system-design-primer" which goes into a breadth of the matter and outlines the important things you need to be aware of. Use it as a reference to understand WHAT there is and to plan how to tackle the preparation problem.

- "System Design Interview" by Alex Xu is another gem of a resource for which I suggest getting a physical copy! It really nicely combines both the breadth of the problems and goes into solid depth of each. I purchased vol. 1 but I think both volumes are amazing resources! Make sure to go through the whole book AT LEAST ONCE!

- "Designing Data Intensive Applications" by Martin Kleppmann, usually called DDIA, is for system design the same thing that "Introduction to Algorithms" is for DS&Algo stuff. It's literally THE BOOK that I wholeheartedly recommend EVERYONE to read at least once in their career (I did couple of reads already and am doing yet another re-read as part of MDCS Book Club). ABSOLUTELY get a physical copy. Don't even think twice.

- "How We've Scaled Dropbox" is an amazing YouTube vide on how DropBox was created and later scaled. I can't recommend this video enough in order to understand how stuff works in real life (hint: probably different than you expected!).

- Quastor is an amazing newsletter that you should have subscribed to yesterday. They go into incredible depths of all kinds of real-life architectures, break them down into consumable chunks and then offer actual links to go read more if you care. I can't recommend it enough.

- Tech Blogs of big and popular companies -- just pick your favorite company and search for its Tech Blog. Almost all of them have it and you can really read some great stuff on how they designed things at massive scale, what challenges they faced and what were some lessons that were learned.

- MIT 6.824 YouTube channel - basically lectures from MIT on Distributed Systems. Simply doesn't get better than attending MIT classes so nothing more to add here :)

And that's about it that I could remember and that I used. Next time I'll discuss a bit more on what to expect, how to prepare, etc. but for now - check the resources, add them to your backlog and plan for planning how to tackle the preparation problem.

P.S. Word of caution: it's great if you are designing (massive) distributed systems at scale on a daily basis. Really amazing and will absolutely come as GREAT help. But do keep in mind that we have tendency to get used to what we are doing and often forget there are alternative ways (and problems) out there. So at least get familiar with BREADTH of the problem and if you already have depth - KUDOS. I'm saying this from first-hand experience. Consider yourself warned :D

Part 7

Seventh part of hashtag#MDCSHiringTips. Last time I discussed list of resources useful to prepare for System Design Interview, and today I'll discuss some practical tips & tricks on how to actually prepare (from first-hand experience). As usual, click on hashtag#MDCSHiringTips hashtag to find all previous posts.

One important thing regarding System Design prep. is that if you're doing it in silence (i.e. by just reading or watching) you're doing it wrong. Simple as that.

The proper way to actually prepare for Sys. Design interview is to find a problem (e.g. "Design Instagram" or "Design Dropbox"; check previous post on list of resources) and then start discussing it by either WRITING, TALKING or DRAWING. Whatever you find most comfortable, obviously.

Some of the resources that I recommend, in no specific order:

- Use a whiteboard if you have one and if it's physically accessible. Stand next to it and start drawing and talking and/or writing your thoughts.

- Use a pen & paper and again - start drawing those squares, rectangles and lines that connect them. Make sure to speak and/or write as you go, if it's doable, obviously.

- Use an online tool like draw dot io and practice there. Get comfortable with it. And again - speak/write as you go!

The thing with System Design interview is that you will most likely want to SHOW instead of just telling. So I recommend getting comfortable with some tools (I personally used draw(.)io during the interview).

Another important aspect of System Design tasks is that they are intentionally vague and lots of it is open for discussion. So interviewer will expect you to ask clarifying questions and make sure you are both clear on what the requirement is.

These questions are also usually open-ended which means that there is no right or wrong. There are multiple ways to tackle the problem and hand and you want to ensure that you are on the same line with interviewer before you start designing.

They are also fun to do! Unlike Algo&DS stuff, these kinds of problems are actually quite amusing and very practical and you are highly likely to encounter them at one point or another. Make sure to enjoy them as you go!

Finally, as I said before, ENSURE to timebox yourself to 30-35mins per problem! This is how long you will have during the interview anyway so you really want to avoid going into the depths, spending hours evaluating whether to use Relational or Document DB. And obviously - COMMUNICATION is crucial!

Good luck! :)

Part 8

Eigth part of hashtag#MDCSHiringTips and today I'd like to focus on the question that at least some of you likely have -- "is it really worth to go through all the interview preparation hassle? And if yes - why?". The short answer is - YES, ABSOLUTELY. And I will elaborate on the WHY part.

There really are multiple things at play here which, if you observe in union and not as separate pieces of info, start painting a bigger and realistic picture.

For one, if you start opening random profiles of people who work at Microsoft, what you will soon learn is that so many people spend 10, 20, 30 or even 40 years working here. What you also eventually learn is that many people come and go -- they decide to leave after period of time, but they eventually come back. What's more, if you focus on people working in Microsoft Dev Center Serbia (MDCS), what you will observe is that many people start fresh out of college and stick around for quite a while.

Why is that? Well, it's because there are so many 'hidden' benefits that are not obvious at first glance, but they gather to form a beatiful interplay of reasons on why people just stick around.

For one, and I can't emphasize this enough - Microsoft (just like other Big Tech companies) is a place where you can stay Individual Contributor (i.e. IC; i.e. a Software Engineer) throughout your whole career. What's more - there's a career ladder to support you in that. What this means is that if you never want to engage in Leadership or Management waters - that's totally fine. You can progress towards Senior, Principal, Partner and eventually Distinguished Eng. levels while still focusing on code and not people management. This is a MASSIVE and ye quite overlooked benefit - no one will force you to move to management once you reach Senior level.

Second - you can EXPERIMENT with various positions. You can always move to Engineering Management track, or Program Management Track or whatever the heck is all out there. There are options to move back&forth and it's definitely nothing that anyone would a bat an eye on. Just go and check various profiles here on LinkedIn and you'll see what I'm saying.

Third - there are SO MANY completely different areas which you can work in. Areas which are as different as different companies are. Like, and I'm talking just about a few things that I'm aware of, but in MDCS you can work on Databases, you can work on Microsoft Fabric, you can work on Service Fabric, you can work in plethora of different teams in Office area, you can work in Math-related departments, you can work in Media Group focusing on Audio and Video, ... the list obviously goes on. The point is - if you want to try something completely new - well, there's likely an opportunity to do so. And again, it's totally fine to move back&forth.

Fourth - the work-life balance and the job security are just, well, incredible. Well, as much as they could be, but way better than anywhere else as we've seen.

Fifth - being surrounded by extremely smart people whom you know that pushed as hard as you did to actually join is a huge satisfaction.

Sixth - Networking opportunities are just incredible. The sheer size of the company and number of unique people that you get to meet is just insane. Opportunities keep presenting themselves.

And last but not least - having "Microsoft" on your resume is, by itself, and incredible thing.

Obviously, I could talk forever about this, but my point is - there are SO MANY things that make it worthwhile to join. So if you are wondering - "will it pay off", trust me, it will.

I guess the summary and gist of what I've been saying is -- what you get as the BIGGEST benefit of all is the OPPORTUNITY. And as you hopefully know, to do anything big or impactful, you need LUCK. And luck, as they say, is when preparation meets opportunity.

So as some of you might have experienced, being great and talented is not always enough. To have your talents shine and your efforts come to fruition, you need place with opportunities. And that, as I said, is the gist of all my blabbings from above :)

Part 9

Ninth and possibly the last part of hashtag#MDCSHiringTips. This time I'll share some people from MDCS that you might want to follow to stay up to date with new career opportunities. I'll also share some useful links.

For starters, here is an unordered list of people who occasionally write about open positions in MDCS: Drazen Sumic, Strahinja Rodic, Sasa Popovic, Jovan Stupar, Nemanja Vukosavljevi?, Nikola Puzovic, Andreja Ilic.

Here's a link to Microsoft's Careers page: https://lnkd.in/d3N8KH4f

And as usual - to see all previous posts related to this topic - click on hashtag#MDCSHiringTips hashtag ;)

Good luck and hope to see you here!