Citadel Intern Software Engineer Interview Experience — A Course Schedule Variant That Didn't Quite Run

This was for a 2027 summer internship, interviewing in the summer before my junior year.

The first 15 minutes were self-introduction plus resume questions. The resume question was pretty vague — the interviewer only asked one question, but it actually bundled two things together: my most technically challenging experience, and whether I had a feature that directly helped with product commercialization. I answered the two parts separately and told two different stories.

All the remaining time went to coding. The coding question was almost identical to "Course Schedule," except instead of returning a boolean, you return all the nodes after a topological sort, and each node's data type is a String. Roughly the problem was:

Given a tasks hashmap where the key is a task and the value is that task's dependencies, find any valid ordering of the tasks.

Input example: {
"Task1": ["Task0"],
"Task3": ["Task0", "Task1", "Task2"],
"Task2": ["Task0"]
}
A valid output: ["Task0", "Task2", "Task1", "Task3"]
An invalid output: ["Task0", "Task1", "Task3", "Task2"]
public static List solution(Map<String, List<String>> tasks) { ... }

I roughly walked the interviewer through my approach using topological sort / Kahn's algorithm, then asked if it sounded right and whether I could go ahead and write it. The logic was fine once I wrote it, but when I ran it I wasted some time changing the function call because I couldn't modify the input parameter. Eventually the interviewer asked if there was a way to do it without changing the input, so I simplified the function — from keeping track of indegree strings to just keeping track of indegree counts. In the end it still didn't run successfully — I hit a null pointer bug. Since I was out of time, I asked him whether he wanted me to debug it or just answer follow-ups, and he said follow-ups were fine too.

Follow-up questions:

How would you modify this if you needed to know whether all the tasks could actually be completed? → Compare the length of the returned list to the length of the input.

What's the time complexity, and how do you get it? → O(V+E), because every node gets visited once, and every edge gets looked at once and then removed.

At the end they gave me about 5 minutes to ask questions.

By the way, this interviewer actually typed out the test cases by hand — I thought he'd have them typed up in advance and just paste them in. That wasted some time...