Microsoft 2026 Intern Interview | Microsoft Internship | Real Questions

Overall structure

Two rounds, 45 minutes each, with a 15-minute break. Both of mine followed a similar structure:

Time	Content
First 15 minutes	Behavioral
About 20 minutes	Coding
Last 5 minutes	My questions

After comparing notes with friends, though, Microsoft's process isn't very templated — interviewers' styles vary a lot. Some downplay or skip behavioral entirely; others keep adding follow-ups during coding and stretch it out.

Behavioral: collaboration and ownership, no technical deep dive

Behavioral was low pressure — nothing like Amazon's repeated digging — but still prepare a few complete stories. The questions centered on collaboration, handling conflict and ownership, without diving into technical details.

Coding style: verbal requirements + discussion

Both questions were fairly open-ended. Neither interviewer pasted a full problem statement into HackerRank; they described the requirements verbally and added constraints and features as we talked — more like a small design + implementation discussion.

Round 1: File path manager (data structure design from interface constraints)

Problem

Implement a simple file path manager with these core operations:

• addPath(path): create a path, making sure the hierarchy is valid and that an existing path isn't created again
• getParent(path): return a path's parent path

The problem isn't complicated, but the interviewer cared more about how you model the path structure and how you handle invalid input and edge cases efficiently.

Approach

Build it around a tree: each node keeps a HashMap of its children, and you parse the path level by level from the root.

The interviewer kept confirming details along the way:

• If an intermediate directory doesn't exist, should creation be allowed?
• What should a duplicate add return?
• Is the overall time complexity proportional to the path depth?

It didn't feel like a test of whether you know the problem — it was about whether you can think the constraints through and explain the design clearly.

Reference implementation

This follows the conventions "the parent must already exist" and "a duplicate add returns False" — confirm these rules with your interviewer first:

class PathManager:
    def __init__(self):
        self.root = {}                        # each node: {child name: child node}

    @staticmethod
    def _split(path):
        """'/a/b' -> ['a', 'b']; returns None if invalid"""
        if not path or not path.startswith("/") or path == "/":
            return None
        parts = path[1:].split("/")
        return parts if all(parts) else None  # reject '//' and a trailing '/'

    def add_path(self, path):
        parts = self._split(path)
        if parts is None:
            return False
        node = self.root
        for name in parts[:-1]:               # intermediate directories must already exist
            if name not in node:
                return False
            node = node[name]
        if parts[-1] in node:                 # already exists; don't create it again
            return False
        node[parts[-1]] = {}
        return True

    def exists(self, path):
        parts = self._split(path)
        node = self.root
        for name in parts or []:
            if name not in node:
                return False
            node = node[name]
        return parts is not None

    def get_parent(self, path):
        """Returns the parent path; a top-level path's parent is '/'; None if the path doesn't exist"""
        if not self.exists(path):
            return None
        parent = path.rsplit("/", 1)[0]
        return parent or "/"

Complexity: both add_path and get_parent are O(d), where d is the path depth.

After I finished, the interviewer didn't ask me to run tests — we quickly went over corner cases and complexity, then moved to Q&A.

Round 2: Message subscription system (state changes + queries)

Problem

A message subscription system that needs:

• subscribe(user, topic)
• unsubscribe(user, topic)
• query(topic): return every user currently subscribed to a topic

It looks simple, but the interviewer kept adding conditions:

• A user may subscribe more than once
• How to handle unsubscribing from a subscription that doesn't exist
• How to keep query efficient

Approach

The core is a bidirectional mapping: topic → users makes query fast, and user → topics supports reverse lookups by user. This round clearly emphasized data consistency and state changes: both maps must be updated together so they never disagree.

The interviewer also followed up on the implementation:

• What if we later need to look up a user's subscriptions?
• As data grows, how do you trade off memory against performance?

It felt like a small system design that evolves step by step.

Reference implementation

from collections import defaultdict

class PubSub:
    def __init__(self):
        self.subscribers = defaultdict(set)   # topic -> users
        self.topics = defaultdict(set)        # user -> topics (reverse lookup by user)

    def subscribe(self, user, topic):
        """Duplicate subscriptions return False and leave the state unchanged"""
        if user in self.subscribers[topic]:
            return False
        self.subscribers[topic].add(user)
        self.topics[user].add(topic)
        return True

    def unsubscribe(self, user, topic):
        """Unsubscribing from a non-existent subscription returns False instead of raising"""
        if user not in self.subscribers.get(topic, ()):
            return False
        self.subscribers[topic].discard(user)
        self.topics[user].discard(topic)
        if not self.subscribers[topic]:       # drop empty sets so memory doesn't keep growing
            del self.subscribers[topic]
        if not self.topics[user]:
            del self.topics[user]
        return True

    def query(self, topic):
        return set(self.subscribers.get(topic, ()))

    def topics_of(self, user):
        return set(self.topics.get(user, ()))

Follow-up ideas: both maps support O(1) add/remove, and query is O(number of subscribers). At scale, a popular topic might have millions of subscribers, so paginate query results; if memory runs short, move the maps into external storage (e.g. Redis sets) sharded by topic; if you only need subscriber counts, maintain a counter instead of returning the whole set.

The Q&A in this round ran especially long — from teamwork and past projects to which kinds of business problems I enjoy — and we went about 5 minutes over.

Overall impressions

• This was centralized hiring for a large org; headcount seems plentiful, and team placement isn't decided yet.
• Microsoft's coding is more like "verbal requirements + a discussion-driven mini design": clarify the constraints and explain the model before coding — that matters more than jumping straight in.
• Behavioral doesn't dig into technical details, but have collaboration, conflict and ownership stories ready.