Media.net and Directi Interview Preparation 2026: Clearing a High DSA Bar

Media.net has a reputation among Indian engineering students as one of the "hard DSA" companies, mentioned in the same breath as trading firms and the stricter rounds at big tech. That reputation is mostly deserved. The good news is that the hardness is predictable: it is concentrated in a well-defined set of algorithmic topics and CS fundamentals, and preparation that targets those topics works. This guide explains the companies, the commonly reported process, the exact level of problem you should be comfortable with, and two fully worked problems at that level.

Interview processes change by year, role and team, and neither company publishes a fixed script. What follows describes widely reported patterns. Confirm the rounds for your role with your recruiter or campus placement cell.

Media.net vs Directi: Who Is Hiring

Directi is an Indian technology group founded in Mumbai in the late 1990s that built businesses in domains, web hosting, communication and advertising. Media.net began inside that group as a contextual advertising business and was sold to an investor consortium in 2016, after which it has operated as its own company. Some Directi-era businesses were sold to other companies over the years, and others continue under the group. The practical takeaway: when you see a job posting, check which entity and product it is for, because teams, locations and interview loops differ.

What Media.net engineers build

Media.net runs an advertising platform: it decides, in milliseconds, which ad to show for a given page and user context, serves it, and records impressions and clicks for billing and optimisation. That domain shapes what engineers work on:

• Ad serving and auctions: low-latency services that select and price ads under strict time budgets.
• Contextual understanding: extracting topics and intent from page content, increasingly with ML and NLP.
• Data pipelines: very high volumes of events (impressions, clicks, conversions) aggregated for reporting and model training.
• Product and frontend: publisher and advertiser dashboards, reporting tools and integrations.

Its main engineering presence in India is reported to be in Mumbai and Bangalore. Directi teams have historically been Mumbai-centred. Location and remote policy can change, so check each posting.

Why the DSA bar is high

Ad tech is algorithm-heavy in a very literal way: ranking, auctions, frequency capping, budget pacing, approximate counting and top-k queries over streams. A company that hires relatively few engineers per year and wants them productive on such problems has a reason to select heavily on problem solving. That is the context for the difficulty, and it is why interviewers care about edge cases and complexity rather than just "does it work on the sample".

The Commonly Reported Interview Process

Candidates report that rounds are often elimination rounds: you get a result after each one. The number of technical rounds varies between two and four, and campus processes may be compressed into a single day. Some loops include a puzzle or a probability question, though that is less consistent than DSA.

Cracking the Online Assessment

The OA is where most candidates are filtered. It is commonly described as harder than the typical HackerRank-style test at service or mid-size product companies: problems that need a non-obvious insight, with large constraints that punish brute force.

Reading constraints to pick the algorithm

The fastest way to find the intended approach in an OA is to read the constraints first. A rough guide, assuming about 10⁸ simple operations per second:

OA tactics that matter

• Read every problem first (two minutes total) and start with the one you are most confident about. Partial scoring, if offered, rewards getting some test cases on every problem.
• Use 64-bit integers by default for sums and products. Overflow is one of the most common reasons a correct idea fails hidden tests.
• Test edge cases yourself: n = 1, all equal elements, maximum values, empty answers, disconnected graphs.
• Fast I/O in C++ (ios::sync_with_stdio(false); cin.tie(nullptr);) and buffered reading in Java. In Python, read all of stdin at once.

Our online assessment tips cover platform-specific gotchas such as hidden test cases and custom input.

The DSA Bar: Topics and Difficulty

Candidates commonly report that interview problems sit at LeetCode medium to hard, and OA problems are often compared to Codeforces Div 2 C/D. The topics that come up most in reports:

If you are building from scratch, follow the top DSA patterns first, then move to competitive programming practice for speed. The distinction that matters: pattern lists get you to medium; contests teach you to find the insight on problems you have not seen.

Worked Problem: Minimum Cost Path With K Free Edges

This is representative of the "known algorithm with a twist" style. Problem: a directed weighted graph with n nodes and m edges. You may make at most k edges free (cost 0). Find the minimum cost from node 0 to node n − 1. Constraints: n ≤ 10⁴, m ≤ 5·10⁴, k ≤ 10.

Finding the approach

Plain Dijkstra fails because the cheapest path depends on how many free edges you have left. The insight is state expansion: the state is (node, free edges used). From state (u, j), an edge u→v with weight w leads to (v, j) at cost w, or to (v, j+1) at cost 0 if j < k. Now it is plain Dijkstra on a graph with n·(k+1) states and m·(k+1)·2 transitions. Complexity: O((n + m)·k·log(n·k)), roughly 10⁶ heap operations here, which is fast.

#include <bits/stdc++.h>
using namespace std;

long long minCostWithFreeEdges(int n, vector<array<int,3>>& edges, int k) {
    vector<vector<pair<int,int>>> adj(n);
    for (auto& e : edges) adj[e[0]].push_back({e[1], e[2]});

    const long long INF = LLONG_MAX;
    vector<vector<long long>> dist(n, vector<long long>(k + 1, INF));
    // (cost, node, used)
    typedef tuple<long long,int,int> State;
    priority_queue<State, vector<State>, greater<State>> pq;
    dist[0][0] = 0;
    pq.push(make_tuple(0LL, 0, 0));

    while (!pq.empty()) {
        long long d; int u, j;
        tie(d, u, j) = pq.top(); pq.pop();
        if (d > dist[u][j]) continue;            // stale entry
        for (auto& e : adj[u]) {
            int v = e.first, w = e.second;
            if (d + w < dist[v][j]) {            // pay for the edge
                dist[v][j] = d + w;
                pq.push(make_tuple(dist[v][j], v, j));
            }
            if (j < k && d < dist[v][j + 1]) {   // use a free edge
                dist[v][j + 1] = d;
                pq.push(make_tuple(d, v, j + 1));
            }
        }
    }
    long long best = *min_element(dist[n - 1].begin(), dist[n - 1].end());
    return best == INF ? -1 : best;
}

int main() {
    vector<array<int,3>> edges = {{0,1,5},{1,3,10},{0,2,2},{2,3,20}};
    cout << minCostWithFreeEdges(4, edges, 1) << "\n"; // 2
}

import heapq

def min_cost_with_free_edges(n, edges, k):
    adj = [[] for _ in range(n)]
    for u, v, w in edges:
        adj[u].append((v, w))
    INF = float("inf")
    dist = [[INF] * (k + 1) for _ in range(n)]
    dist[0][0] = 0
    pq = [(0, 0, 0)]  # cost, node, used
    while pq:
        d, u, j = heapq.heappop(pq)
        if d > dist[u][j]:
            continue
        for v, w in adj[u]:
            if d + w < dist[v][j]:
                dist[v][j] = d + w
                heapq.heappush(pq, (d + w, v, j))
            if j < k and d < dist[v][j + 1]:
                dist[v][j + 1] = d
                heapq.heappush(pq, (d, v, j + 1))
    best = min(dist[n - 1])
    return -1 if best == INF else best

print(min_cost_with_free_edges(4, [(0,1,5),(1,3,10),(0,2,2),(2,3,20)], 1))  # 2

Dry run

Graph: 0→1 (5), 1→3 (10), 0→2 (2), 2→3 (20), k = 1. Start (0, used 0) at cost 0. Relaxing its edges gives (1,0)=5, (1,1)=0, (2,0)=2, (2,1)=0. Pop (1,1) at cost 0: edge 1→3 can only be paid (no free edges left), so (3,1)=10. Pop (2,1) at 0: 2→3 paid would cost 20, which does not beat 10. Pop (2,0) at 2: paying 2→3 gives (3,0)=22; using the free edge gives (3,1)=min(10, 2)=2. Pop (3,1) at 2; node 3 has no outgoing edges. Pop (1,0) at 5: paying 1→3 gives (3,0)=min(22, 15)=15, and the free edge gives (3,1)=5, which does not beat 2. The answer is min(dist[3]) = min(15, 2) = 2: take 0→2 for 2, then make the expensive 2→3 edge free. Note that the greedy "make the largest edge on the shortest path free" would fail on other inputs; the state expansion is what makes it correct.

Follow-ups interviewers ask

• "What if k is up to 10⁴?" The state space explodes; discuss whether the problem structure allows a different formulation, and be honest about limits.
• "Edges can be discounted by half instead of made free?" Same state expansion, different transition cost.
• "Return the path, not just the cost?" Store a parent pointer per state.

Worked Problem: Design a Data Structure in O(1)

Data structure design questions test whether you can combine primitives. A classic in the ad-tech spirit: design a structure that supports inc(key), dec(key), getMaxKey() and getMinKey(), all in O(1) (LeetCode 432, All O'one Data Structure). Think of keys as ad IDs and counts as clicks in a window.

The design: a doubly linked list of buckets ordered by count, each bucket holding the set of keys with that count, plus a hash map from key to its bucket. Incrementing moves a key to the next bucket (creating it if the next bucket's count is not count+1), and empty buckets are removed. The head bucket has the minimum count, the tail has the maximum.

class Bucket:
    __slots__ = ("count", "keys", "prev", "next")
    def __init__(self, count):
        self.count, self.keys = count, set()
        self.prev = self.next = None

class AllOne:
    def __init__(self):
        self.head, self.tail = Bucket(0), Bucket(0)   # sentinels
        self.head.next, self.tail.prev = self.tail, self.head
        self.where = {}                                # key -> Bucket

    def _insert_after(self, node, count):
        b = Bucket(count)
        b.prev, b.next = node, node.next
        node.next.prev = b
        node.next = b
        return b

    def _remove(self, b):
        b.prev.next, b.next.prev = b.next, b.prev

    def inc(self, key):
        cur = self.where.get(key, self.head)
        nxt = cur.next
        if nxt is self.tail or nxt.count != cur.count + 1:
            nxt = self._insert_after(cur, cur.count + 1)
        nxt.keys.add(key)
        self.where[key] = nxt
        if cur is not self.head:
            cur.keys.discard(key)
            if not cur.keys:
                self._remove(cur)

    def dec(self, key):
        cur = self.where.get(key)
        if cur is None:
            return
        if cur.count == 1:
            del self.where[key]
        else:
            prv = cur.prev
            if prv is self.head or prv.count != cur.count - 1:
                prv = self._insert_after(cur.prev, cur.count - 1)
            prv.keys.add(key)
            self.where[key] = prv
        cur.keys.discard(key)
        if not cur.keys:
            self._remove(cur)

    def getMaxKey(self):
        return "" if self.tail.prev is self.head else next(iter(self.tail.prev.keys))

    def getMinKey(self):
        return "" if self.head.next is self.tail else next(iter(self.head.next.keys))

a = AllOne()
for k in ["ad1", "ad1", "ad2"]:
    a.inc(k)
print(a.getMaxKey(), a.getMinKey())  # ad1 ad2

What interviewers grade here: you explain why a heap is not enough (O(log n), and decrement requires arbitrary updates), you handle sentinel nodes to avoid null checks, and you remove empty buckets so min and max stay O(1). The LRU cache walkthrough uses the same linked-list-plus-map skeleton and is good warm-up practice.

CS Fundamentals: OS, DBMS, Networking

Freshers in particular report questions on core subjects between DSA problems. These are usually conceptual and probe understanding rather than textbook definitions.

Operating systems

• Process vs thread; what is shared and what is not; cost of a context switch.
• Virtual memory, paging, page faults, TLB, and what thrashing is.
• Deadlock conditions and how to prevent one in a concrete lock ordering example.
• Mutex vs semaphore; producer-consumer with a bounded buffer.

DBMS

• Indexes: why a B+ tree, when an index hurts writes, composite index column order.
• Transactions, isolation levels and the anomalies they prevent.
• Normalisation trade-offs, and when you would denormalise for read performance.

Networking

• What happens when you type a URL: DNS, TCP handshake, TLS, HTTP, caching.
• TCP vs UDP; flow control vs congestion control.
• HTTP/1.1 keep-alive vs HTTP/2 multiplexing; why that matters for ad-serving latency.

The OS interview questions and computer networks questions guides are good revision lists. Answer with mechanisms: "a TLB miss means a page-table walk, which is several memory accesses, so working sets that exceed TLB reach get slower" is far better than "TLB is a cache".

System Design for Experienced Candidates

Experienced hires commonly report a design round. Given the domain, ad-tech-shaped prompts are natural to practise:

• Ad click aggregation: count clicks per ad per minute at very high volume, handle late events and deduplicate. Our ad click aggregation design covers this end to end.
• Ad serving under a latency budget: candidate retrieval, filtering (targeting, frequency caps, budget), ranking and auction in tens of milliseconds. Discuss caching, precomputation and timeouts with fallbacks.
• Budget pacing: spread an advertiser's daily budget across the day without overspending when many servers serve in parallel. Discuss local token allocations synchronised periodically with a central counter.
• Top-k trending: heavy hitters over a sliding window with Count-Min Sketch plus a heap; see top-k trending design.

Show the math. For example, if a service handles 100,000 ad requests per second and each logs a 500-byte event, that is 50 MB/s, or about 4.3 TB per day before compression. That number decides whether you need partitioned streaming, how long you retain raw data and how you aggregate.

Salary: Approximate 2026 Ranges

The figures below are approximate 2026 ranges from public sources such as AmbitionBox, Glassdoor and levels.fyi; they vary by team, role and negotiation, and self-reported data is noisy.

Headline campus numbers often include first-year-only components. Separate recurring fixed pay from one-time items before comparing offers; the offer letter guide walks through it line by line.

An Eight-Week Preparation Plan

This plan assumes you can already solve most LeetCode easy problems and some mediums. It aims to make you reliable on medium-hard problems in 30–40 minutes each.

1. Weeks 1–2: graphs. BFS, multi-source BFS, 0-1 BFS, Dijkstra with state expansion, topo sort, DSU. 30 problems. Write Dijkstra from memory in your language daily until it takes under five minutes.
2. Weeks 3–4: DP. 1D/2D, knapsack variants, LIS, interval DP, DP on trees, bitmask DP. 35 problems. For each, write the state definition in one sentence before coding.
3. Week 5: binary search and greedy. Binary search on answer, sorting-based greedy, heaps, interval scheduling. 25 problems.
4. Week 6: data structure design and windows. LRU, LFU, All O'one, time-based store, sliding window with counts. 15 problems plus implementation drills.
5. Week 7: contests and fundamentals. Two live or virtual contests per week; daily 45 minutes on OS, DBMS, networking.
6. Week 8: simulation. Three full mock OAs (2–3 problems, 90 minutes) and three mock interviews where someone changes constraints mid-problem.

Keep an error log: for every problem you fail, write the one-line insight you missed. Re-read the log weekly. In mock interviews I see that candidates who track missed insights improve much faster than those who only count problems solved.

How to Behave in the Interview Room

• Start with brute force, out loud, in one sentence. Then improve. Interviewers want to see the path, and a stated brute force guarantees you have something.
• State complexity before coding and confirm it fits the constraints.
• Write production-quality code: meaningful names, helper functions, no dead code. Hard-DSA interviewers still read your code.
• Test with your own examples, including an edge case, before saying you are done. Finding your own bug is a positive signal; the interviewer finding it is not.
• When stuck, say what you have tried. Hints are normal at this bar. Using a hint well is better than silence.
• Prepare for "why Media.net" or "why Directi". Mention the problem domain (ad tech, latency, scale) rather than the package.

If you are applying to several high-bar companies, the same preparation transfers directly to D. E. Shaw and similar firms. Build the graph and DP muscle first, keep fundamentals warm, and confirm the exact loop with your recruiter before you walk in.

Frequently Asked Questions

Pranjal Jain

Ex-Microsoft SDE · IIT Kanpur · Founder of Prepflix. Helps engineers crack startup and product company interviews across India.