What is a Principal Engineer at Microsoft?
With Dejan Dundjerski, Principal Software Engineer.
The Microsoft Development Center in Belgrade (MDCS) recently marked its 20th anniversary. Two decades of building systems that run at a global scale, from Azure SQL to AI-powered troubleshooting platforms.
Dejan Dunjerski is one of those who built the MDCS into what it is today. He’s a Principal Software Engineer who successfully replatformed Azure SQL Managed Instance without customers noticing, while scaling the service by a factor of 10.
Before that, he created an AI expert system for troubleshooting millions of databases, back when no one in academia had researched the problem.
This interview breaks down how he thinks about problems, makes architectural decisions, and what actually separates senior engineers from principal ones.
In particular, we will talk about:
Who is Dejan. From building his first program in high school to selling electronic logbooks, the path wasn’t linear.
What is his career journey. Three pivotal projects at Microsoft: building the first open-source database in Azure SQL, creating an AI troubleshooting system that had not been researched, and replatforming a live service with 10 times the growth.
What were the biggest challenges in advancing to Principal Engineer. POCs, research in uncharted territory, and managing dependencies that don’t respect your timeline. The technical challenges that force you to negotiate, influence, and solve problems no one else figured out.
What separates a senior from a principal engineer. Seniors identify problems and propose solutions. Principals implement them and get others to join.
How to balance technical depth and breadth. Know the details of what you own. Windows codebase analysis, log mining, and dashboard patterns that help you focus. Breadth matters, but depth in your domain prevents surprises.
How to make proper architectural decisions. Start with the simplest solution, then figure out what needs to change and where. Workarounds compound.
What early challenges shape system design. Building an OS from scratch at the university, designing for 8 billion users before having any, and implementing open-source databases in Azure SQL. Each one forced a different kind of thinking.
How Dejan's problem-solving evolved over time. Still chasing simplicity and making changes at the right level. The difference now: planning beyond sprints and avoiding short-term workarounds when dependencies slip. Sometimes, helping the dependency team delivers faster than waiting.
How does he manage productivity with multiple responsibilities. Don’t procrastinate on 30-second tasks. Block time for deep focus.
How does he stay current with AI. Understand the essence of new technology, then use it for its intended purpose. LLMs are a library you can query; no need to read every book.
So, let’s dive in.
Zero Trust for AI: Securing MCP Servers eBook (Sponsored)
MCP servers are becoming critical components in AI architectures, but they are creating a fundamental new risk that traditional security controls weren’t designed to address.
Left unsecured, they’re a centralized point of failure for data governance.
This eBook will show you how to secure MCP servers properly, using externalized, fine-grained authorization. Inside the ebook, you will find:
How MCP servers fit into your broader risk management and compliance framework
Why MCP servers break the traditional chain of identity in enterprise systems
How role-based access control fails in dynamic AI environments
Real incidents from Asana and Supabase that demonstrate these risks
The externalized authorization architecture (PEP/PDP) that enables Zero Trust for AI systems
Get the practical blueprint to secure MCP servers before they become your biggest liability.
1. Who is Dejan?
Who am I? That is a question I also ask myself from time to time 😀. I was born in Belgrade in 1987 as the third child in my family (I have two older sisters). I had the privilege to learn a lot from my family (sisters, parents, and grandparents).
Being surrounded by engineers and professors, and having my sisters' patience to take their little brother to see the world, was essential to who I am today.
In the meantime, I have completed my studies at Mathematical Grammar School and earned a PhD in the School of Electrical Engineering. Very keen on sailing and skiing, and passionate about photography.
Most recently, I have become a husband and father, so in all the free time I can get, I am trying to pass the family tradition and knowledge to the young ones :)
2. What is your career journey?
I built the first program in the 2nd grade of high school. I have also successfully sold electronic logbooks for airplanes to several companies on a few occasions.
From that day to this, I have been focused on problem-solving and understanding the essence of the problem.
During my tenure at Microsoft, I have consistently been driven by a hunger for knowledge and a desire to accomplish tasks effectively. When you are done with one thing, there will be another from which you can learn even more.
I must admit that I have had a very interesting ride within MSFT so far. From the early days of the Azure SQL team in Serbia, where I had the opportunity to build the proof of concept for the first open-source database in Azure SQL, to creating an AI-powered expert system for troubleshooting millions of databases, I have been involved in significant projects.
Over the last five years, I have been responsible for the entire Azure SQL Managed Instance platform, where we successfully replatformed the compute, networking, and storage layers without customers noticing the change, while achieving a 10x increase in service growth in parallel. Tons and tons of learning.
The role of Principal Engineer is just a title. What is more important is the mindset. Focusing on the problem and its essence, trying to find creative solutions, and having a 'get-the-stuff-done' mentality is what has brought me to where I am now.
3. What were some of the biggest challenges you faced while advancing to a Principal Engineer position?
I had three big challenges:
First, I had the opportunity to build the POC in 2015. of the Azure MySQL service on the Azure SQL platform. In two months, I have gained a comprehensive understanding of the entire Azure SQL architecture, from the connectivity, provisioning, and data plane perspectives.
Second, building an AI expert system for DB troubleshooting that, at the time, no one in the world (even in academia) had researched. This was challenging from the perspective of what we should do, and the usual approach of building a small POC to achieve value didn’t work well. For this one, we had to conduct extensive research in both related and unrelated fields to make progress.
Third, again, the non-technical challenge is running a generally available service, performing a replatforming effort with numerous dependencies, where, for each and every dependency, you cannot rely on the timeline that partner teams provide to you. Here I had to learn how to negotiate, ask for support, go with the flow, etc :)
Whether these three learnings brought me to the Principal level position, I don’t know, but these were the challenges that, if I hadn’t solved, I wouldn’t be where I am today.
4. What’s the most important difference between senior and principal engineers?
It is the scope and the desire to lead and change the stuff. When you encounter a problem, the mindset of a senior engineer is to share the problem and propose a solution, while a person with a principal-level mindset will identify the problem, devise solutions, and attempt to implement one.
As part of this process, the leading aspect is evident in practice when the person asks others to join the party and starts influencing the larger group of people (more than 10) in a formal or informal manner.
Additionally, a Principal Engineer must possess strong communication and presentation skills. Usually, people have full context in their minds; however, very few are good at transferring that context to others.
For success and advancement in a career, understanding the other side and finding ways to explain and present your ideas to others so that they can understand you is essential.
So, for the principal level is important:
Focus on the tech and building the right pieces at the right level of the tech stack,
Focus on the essence of the problem and not on the form,
Don’t give up easily
5. How should Principal Engineers balance technical depth and breadth?
Both breadth and depth are important; it certainly depends on the project you are working on. There is no silver bullet. However, what is very important is that for the area you own or are responsible for, you need to be aware of all those small details. The devil is usually in the details, and those details will bite you, so better for you to know about them proactively.
To illustrate, on one of the projects, before making a decision, I examined the Windows codebase and determined how Windows containers work. This understanding helped me influence my team and other teams.
When I realized that this approach could speed us up and that it worked, I continued using it every time I was unsure about something.
Other useful practices include data science analysis of the logs. Alternatively, when discussing the service, dashboards provide a broad view, helping you focus on and investigate the depth of the most important aspects.
6. How do you make architectural decisions in complex projects?
Simplicity is the king! I start by searching for the simplest possible solution and then examining what we need to change and at what level to achieve it.
That approach helps avoid the usual pitfall where we start from what we have now and how we can slightly modify it, and then, after the third iteration, you end up with a 10 times more complex code/architecture/system that no one knows how to deal with.
Instead, it is better to understand what the problem is, where the best possible place to solve it is, and why it cannot be solved immediately (if it cannot be solved there).
Although it may seem easier and faster to create a workaround, with a bit of extra effort, making a change in the right place or resolving the blocker that prevented you from making a change will definitely pay off.
7. What early-career technical challenge shaped your system-design approach?
There are a few projects that helped me understand the system design and architecture. First of all, at the faculty, we had a class where we had to develop an operating system from scratch, which helped me understand why, on certain occasions, a sandglass spins while you are doing something with your machine.
Then I attempted to build a simple game, imagining that the entire world would play it (8 billion users), and I tried to put the necessary architecture in place.
As I mentioned, I was one of two individuals tasked with implementing an open-source database in the existing Azure SQL architecture, which motivated me to learn the details down to the lowest level.
At a later stage, I read two books on System Design Interview and Designing Data-Intensive Applications, which helped me understand that all the knowledge I had acquired over the years is actually described in those books in a very detailed way.
8. How has your technical problem-solving evolved since your senior engineer days?
Not that much; I used to strive for simplicity and make changes at the right level. One change that is evident is that I now make plans for a longer period, rather than just for a single sprint.
It is quite often that teams and individuals optimize for the short term and 6-month sprints. On one of the projects, since the dependency was not ready at the time, we opted for a short-term implementation that was more complex.
Since the dependency was not delivered on time, we ended up with a more complex solution than we would have had if we had accounted for the delay or just planned a longer delivery.
Hence, I am avoiding workarounds as much as possible and striving to offer help to the dependency teams and the delivery in their code base, if that will expedite the end-to-end story.
9. How do you manage your day-to-day productivity, given multiple responsibilities?
Do not procrastinate! Whatever can be done in under 30 seconds, do it immediately.
Yes, that can bring a lot of distraction, but then you have to dedicate a certain period of time to focusing on just a few very important topics or decisions that you need to make. I have also tended to spend some time working on things that are important but not critical in terms of time.
Also, when motivated, I do not quit that easily, and I am willing to push things through till the very end. When it comes to practices, meditation has helped me achieve superb focus on certain things.
Sailing, another hobby I truly enjoy, helped me build endurance and taught me that in life, sometimes when there are strong winds, it's best to lower your sails and wait for the storm to pass.
10. How do you stay current with rapid technological advancements, such as AI?
Things may be evolving at a rapid pace; however, a basic set of problems that needs a solution remains. I tend to understand the essence of the new technology and how it works in practice. Then I am using these new tools for their intended purpose.
For example, I have been approaching LLMs as one big library that is being read by the models; hence, I do not need to lend the book and read it one by one, but I have a single book that I can ask any type of question I might need.
On a day-to-day basis, I use it for basic tasks and to remind myself of certain topics in a more efficient manner.
11. Do you have any recommended learning resources to share with us?
Here are a few books I can recommend:
Designing Data-Intensive Applications, Martin Kleppmann (O’Reilly, 2017): patterns for reliability, scalability, and consistency.
System Design Interview, Alex Xu (ByteByteGo, 2020): concise system patterns and trade-offs for interviews.
Leadership and Self-Deception. The Arbinger Institute (Berrett-Koehler, 2015)- Mindset shifts for leading engineers.
The Mom Test, Rob Fitzpatrick (2013): Extracting Honest Signals from Customer Conversations.
Thinking, Fast and Slow, Daniel Kahneman (FSG, 2011): biases and heuristics that shape decisions.
Zero to One, Peter Thiel with Blake Masters (Crown Business, 2014): monopoly design and contrarian bets.
Sapiens, Yuval Noah Harari (Harper, 2015): long-view context for products and behavior.
Milan here again. Thank you, Dejan, for your time and a great overview of the Principal Engineer role at Microsoft.
➡️ Here you can read my full review of the book “Designing Data-Intensive Applications”.
More ways I can help you:
📚 The Ultimate .NET Bundle 2025 🆕. 500+ pages distilled from 30 real projects show you how to own modern C#, ASP.NET Core, patterns, and the whole .NET ecosystem. You also get 200+ interview Q&As, a C# cheat sheet, and bonus guides on middleware and best practices to improve your career and land new .NET roles. Join 1,000+ engineers.
📦 Premium Resume Package 🆕. Built from over 300 interviews, this system enables you to craft a clear, job-ready resume quickly and efficiently. You get ATS-friendly templates (summary, project-based, and more), a cover letter, AI prompts, and bonus guides on writing resumes and prepping LinkedIn. Join 500+ people.
📄 Resume Reality Check. Get a CTO-level teardown of your CV and LinkedIn profile. I flag what stands out, fix what drags, and show you how hiring managers judge you in 30 seconds. Join 100+ people.
📢 LinkedIn Content Creator Masterclass. I share the system that grew my tech following to over 100,000 in 6 months (now over 255,000), covering audience targeting, algorithm triggers, and a repeatable writing framework. Leave with a 90-day content plan that turns expertise into daily growth. Join 1,000+ creators.
✨ Join My Patreon Community and My Shop. Unlock every book, template, and future drop, plus early access, behind-the-scenes notes, and priority requests. Your support enables me to continue writing in-depth articles at no cost. Join 2,000+ insiders.
🤝 1:1 Coaching. Book a focused session to crush your biggest engineering or leadership roadblock. I’ll map next steps, share battle-tested playbooks, and hold you accountable. Join 100+ coachees.
Want to advertise in Tech World With Milan? 📰
If your company is interested in reaching an audience of founders, executives, and decision-makers, you may want to consider advertising with us.
Love Tech World With Milan Newsletter? Tell your friends and get rewards.
We are now close to 50k subscribers (thank you!). Share it with your friends by using the button below to get benefits (my books and resources).
Excellnt interview! The distinction between senior and principal engineers - identifying problems vs. implementing solutions and bringing others along - is key. The emphasis on simplicity in architectural decisions resonates deeply, especially the point about avoiding workarounds that compound complexity over time.