Interview adjacency list graph problems in C++: proper graph implementation
I'll be honest: if you've completed a task in 20 minutes during an interview, I'll probably forgive a lot. I'd assume you made a lot of assumptions about the compilation environment, and you may or may not have had access to reference materials, and that your code is basically as close to pseudocode as it is to actual code. Anyone who can't at least give you that benefit of the doubt is probably someone you don't want to work for.

Given that, there are a few things I'd recommend working on.

Naming

They say that naming things is one of the hardest things in computer science. (And not just computer science - biology has a hold field of taxonomy that classifies and names things. It's hard work!) Looking at your code, it's not immediately obvious to me what the difference between a directed and a directed_node is. They both declare a list of things they're adjacent to, but one has an m_t member and an iterator.

Also, what is m_t? It looks like you're using m_ to represent member variables. That's not my favorite way of doing things, but it makes sense and is a common way of naming things, so I wouldn't ding you for it. But m_t tells me nothing beyond that it's a member of the struct. Is t in this case just an instance of T? I'd prefer something generic like value or data over t, if that's the case. But if you can clarify with a better name than any of those, all the better.

Information Hiding

It's often a good idea to hide the details of how something works from the code which calls it. That allows you to swap out something with the same interface but a different implementation. Given that, I'm wondering why all your member variables are public in directed_node and directed? You probably don't want code outside of the struct changing those values out from underneath you. So make them protected or private.

Simplify

I don't know if this is possible, but you've used std::shared_ptr&lt;directed_node&lt;T&gt; in several places. Would it be possible to define it as a type? You'd probably have to do it twice - once in directed_node and once in directed, which feels wrong. Maybe it's not worth it. Likewise, you've defined adjacency_t twice but with the same definition (assuming that you use the same type for your directed_node and directed). That feels weird, but maybe it's unavoidable? Certainly, I wouldn't ding you for doing this in only 20 minutes. But in a real project, I'd expect to have a code review where we would figure out some way of simplifying that, if possible.