Demandbase SDE Intern Interview Experience (On-Campus) | 2026

Company: Demandbase
Role: Software Engineering Intern (with PPO)
Type: On-Campus
Result: No Offer

Background

Got shortlisted for Demandbase's on-campus hiring process through our placement cell. Sharing this experience so others can prepare better. The process was well-structured and spread across multiple stages.

Stage 1: Written Assessment (Offline — Pen & Paper)

This was an offline written test with a sectional cut-off, so clearing every section independently was mandatory — not just overall marks.

Structure:

• 20 MCQs covering CS Fundamentals and DSA
• 1 Coding Problem

MCQ Topics Covered:

• Data Structures (time complexities, properties)
• OOP concepts
• OS basics
• DBMS fundamentals
• Output prediction and code tracing

Coding Problem:

The coding problem was based on Multi-Source BFS — a graph traversal problem where you initialize BFS from multiple source nodes simultaneously. If you know the classic "Rotting Oranges" pattern, this felt very similar conceptually. Clean BFS implementation with a queue was the expected approach.

Tip: The sectional cut-off is the real filter here. Don't ignore MCQs thinking coding will save you. Both sections matter independently.

Outcome: Around 25 students were shortlisted for further rounds.

Stage 2: Round 1 — Technical Interview (Offline, In-Person)

This round was conducted in-person and lasted approximately 1 hour 30 minutes. The interviewer started with a brief self-introduction and a quick resume discussion before moving to the technical portion via a shared Google Doc.

DSA Problem

The problem was conceptually similar to LeetCode — Parallel Courses III (LC #2050).

For those unfamiliar — it involves finding the minimum number of months needed to complete all courses given prerequisites and durations. The core concepts tested were:

• Topological Sort (Kahn's Algorithm / BFS approach)
• Dynamic Programming on DAG
• Longest path in a directed acyclic graph

The interviewer gave around 30-35 minutes for this. After completing the solution and walking through the approach, they seemed satisfied and moved on.

Key insight: Verbalize your approach before coding. The interviewer wants to see your thinking, not just the final code.

SQL Problem

A SQL problem was given with specific tables and fields defined. The problem itself was straightforward — involving JOINs and aggregation. Tables and schema were provided clearly so there was no ambiguity.

Topics tested: JOIN operations, GROUP BY, aggregate functions.

Code Refactoring Problem (OOP Based)

A piece of code was shared and the task was to improve it using OOP principles. Importantly, the interviewer did not expect actual rewritten code — only a clear approach and explanation of:

• What problems exist in the current code
• Which OOP principles apply (SRP, DRY, abstraction, encapsulation etc.)
• How you would restructure it and why

This was more of a design thinking question than a coding question.

Outcome: Shortlisted for Round 2. Approximately 12-13 students moved forward.

Stage 3: Round 2 — Technical Interview (Online)

This round was conducted online and also lasted approximately 1 hour 30 minutes. Started with brief introductions followed by a deep dive into projects mentioned on the resume.

Project Discussion

The interviewer went into significant depth on the projects — not surface level questions. Expect questions like:

• Why did you choose this architecture?
• What were the bottlenecks and how did you handle them?
• How would you scale this?
• What would you do differently now?

Be prepared to defend every line on your resume genuinely.

System Design — Low Level Design (LLD)

The design problem was:

Design a Multi-Floor Parking System

Discussion covered:

• Identifying entities — ParkingLot, Floor, Slot, Vehicle, Ticket
• Class relationships and responsibilities
• How to handle different vehicle types
• Slot allocation strategy
• OOP principles applied throughout

The interviewer was more interested in the thought process and design decisions than a perfect solution. Asking clarifying questions before designing was well received.

AI-Assisted Coding Discussion

An interesting section that I haven't seen mentioned in many other experiences. The interviewer asked:

• How do you use AI tools in your development workflow?
• How would you use AI-assisted coding going forward as an engineer?
• Specific questions around AI mentioned in the resume

Given the role focuses on AI-powered product development, this section carries real weight. Having genuine hands-on experience with AI tools and being able to articulate how you use them meaningfully — not just "I use ChatGPT sometimes" — makes a significant difference here.

Result announced after 2 days — No Offer.

Key Takeaways for Future Candidates

On the Written Test:

• Sectional cut-off means both MCQ and coding must be cleared independently
• Multi-source BFS is worth knowing — initialize queue with all sources simultaneously
• CS fundamentals MCQs are not trivial — revise OS, DBMS, OOP, basic networking

On DSA Round:

• Graph + DP combination problems are fair game — Parallel Courses III level difficulty
• Always state your approach before writing code
• SQL questions are straightforward but need to be clean and correct

On LLD Round:

• Parking lot, elevator, cab booking — practice these classic LLD problems
• Interviewers care about your reasoning behind design choices more than perfect code
• Know SOLID principles and be able to apply them in discussion

On AI Round:

• This is becoming a standard part of product company interviews
• Surface-level answers won't cut it — have real examples of using AI in projects
• Know how to prompt effectively and how to verify AI-generated output

On Projects:

• If it's on your resume, you should be able to defend it deeply
• Architecture decisions, trade-offs, scaling considerations — all fair game

All the best. The process itself teaches you more than the outcome.