Video Notes
One of the best ways to get better at coding interviews is to learn from other people's mistakes. That's why in this video, I'm going to be doing a tear down of a mock interview recording from interviewing.io. Let's go ahead and get into it.
00:00:18 Interview interaction
00:00:44 Sam: All right. So before we get into the sample solution here, as we go through this, I want you to pause the video as we go and think about what you would do here. So your interviewer just explained to you the question; he's given you a couple examples. What is the next step that you should take?
00:01:04 Interview Interaction
00:02:06 Sam: So the first thing that our interviewee did is he started by writing a helper function. And this feels a little bit random. Helper functions are good. They're a really good thing for us to use in our mock interviews, but is this really the best place for us to start? This is something that we can figure out later. And now he kind of got this out of the way and he's still trying to figure out, okay, what am I even doing in the first place?
A better place for our interviewee to start would have been to go through the inputs and outputs, as well as a couple examples of the problem. We're given this example where we can see that our input is a list of strings, but we don't really know what the format of our output is. And we haven't defined that. Our interviewer just said it should be some format. So I'd really like to clarify more what that means so that we can get more clarity around what it is exactly that we're doing.
00:02:57 Interview Interaction
00:03:21 Sam: Okay, so there you see, he just asked our interviewer what the input was and when he got an answer to it, he was like, oh, so that's a totally different problem than what I thought it was. He spent all this time kind of in his head thinking about what is the solution that I'm going for here. And now he has to start over again because he didn't start with those inputs first.
So this is where really understanding the question that you're being asked, and really understanding what it is that you need to do, is so, so important.
00:03:49 Interview Interaction
00:04:17 Sam: Yeah, so that's a really good clarification there. It just shows that he's understanding what the problem is that's being asked.
00:04:24 Interview Interaction
00:05:28 Sam: So at this point, one of the things that I would be thinking about doing is coming up with some sort of brute force solution to this problem.
At this stage, it's not about coming up with an optimal solution, but in terms of a brute force solution to this problem, it's not super complicated. We just need to do something where we're going to split up everything into what are our strings, what are our directories and files, and then figure out how to combine them.
So I would be probably, in an ideal world, drawing this out, even though this is virtual and it's on whatever platform this is, I would be thinking about drawing something out and explaining what I'm doing or working through an example and understanding how that works. Because right now we have no idea what our interviewee is thinking.
We have no idea what he's thinking. It's like the gears are turning in his head. So at least I'd want him to say, Hey, let me think about this for a moment, rather than just going radio silent.
00:06:30 Interview Interaction
00:07:29 Sam: Yeah. So again, I think that I would prefer him to figure out what functions that he's going to need as he's actually writing the solution. Right now he's kind of spewing out a lot of helper functions. And me as the interviewer, or this as the interviewer, is not clear on why he's doing this or what exactly he needs.
So it would be really helpful, I think, to map out what is it that I'm trying to do first, at least at a high level. And then we can figure out, okay, what helper functions am I going to need to do that? What would make my life easier rather than saying, okay, let me put, let me map out a bunch of helper functions and then somehow figure out how to match them together later.
00:08:07 Interview Interaction
00:08:13 Sam: And there: “I don't know if I'm going to need to use that or not.” So he's wasting time writing something that he doesn't know if he's going to need to use
00:08:25 Interview Interaction
00:11:47 Sam: So one thing that I'm noticing here that you definitely want to think about in your interview – and we'll see how he actually does with this – but you really want to think ahead.
And what I mean by this is that a lot of times in interviews, people end up in a situation where they were making a decision on the fly. They were like, okay, this is going to work for this, but they don't actually think ahead to that next thing. So my immediate thought with this is that he's creating this standalone function that is going to print out a series of a directory hierarchy.
But what happens when you have multiple files in that hierarchy? How is that actually going to be represented here? And I think there are some solutions to this, but it would be good to be thinking about this now, because if let's say in this example, he had assets/html/a.html and assets/html/b.html.
Is he going to pass that whole string both times in which he's printing that whole hierarchy again, is he going to pass all those files inside as like a sub list, which would be an interesting way to get around this, but that's going to add more complexity to the code.
It's something that would be good to be thinking about at this stage, because he's going to have to deal with this later. And that's not really something that you want to be doing once you get to the coding part of the problem.
Like a lot of times people end up in this situation where they came up with a solution and then they start coding it up and they realize, oh, I didn't think ahead to this other scenario. And then it becomes much harder to deal with, versus if you deal with that at the beginning in how you are structuring your approach to the problem.
00:13:24 Interview Interaction
00:15:00 Sam: So here, he's identifying this same problem that we talked about. And it was an interesting, different problem that I hadn't even thought of that our interviewee came up with, which is that you could have a directory that contains another directory and also a file. And so that is something that we have to deal with as well.
00:15:21 Interview Interaction
00:16:33 Sam: Yeah. So this, I think makes a lot of sense. What the interviewer is saying is that parsing it into some sort of data structure, basically with any sort of file system, we essentially have a recursive data structure. Essentially functions like a tree where you have the directories and then you have the sub-directories and then the sub-directories at that and sub files and whatever.
Now, I think that's probably a good approach here that I would recommend that our interviewee take. One thing that you should keep in mind is that if you are presenting a solution and your interviewer says something like what our interviewer said here, which is that I've never seen an approach like this before.
And then that probably means one of two things or one of three things, actually one is that you really do have some novel approach and it's going to work great. That is okay if you're very confident in your solution, but more likely it's one of the other two things, which is one, this is a suboptimal approach. It's a suboptimal approach and it would be better to at least take a step back and think, am I going in the right direction.
Zoom out for a second and say, are there other ways I could be approaching this problem that would be more helpful? And then three, the other possibility is that you're just explaining it in a very bad way or a very unclear way to your interviewer.
It's possible that you are doing the thing that they have seen before, but you're just explaining it or, or approaching it in a very weird way that they're not familiar with. So in a case like that, it would be good to take a step back, make sure that you really are doing what makes sense; consider other possible approaches.
And then if you still really think that you're going the right way, try re-explaining your full approach to your interviewer and see if they understand it. And if that makes sense to them.
00:18:20 Interview Interaction
00:18:43 Sam: Yet again, our interviewee is kind of jumping into coding without really fleshing out the solution. It's so much better if you can take the time to flesh out like this is my full solution end to end and then code it up.
The coding part of your interview should basically be a translation job. You should be translating your thoughts into code, your structured solution into code. You shouldn't be trying to figure out what to do while you are coding the problem, because that's where you run into issues where you didn't think things through properly, or you didn't fully understand the solution. And then you end up coding something that's not the right approach.
00:19:31 Interview Interaction
00:20:58 Sam: So I know I sound like a little bit of a broken record here, but I would love for him to actually map out broadly, like, here's what's going to happen first. Doesn't have to be full pseudo-code; it doesn't have to be everything that's going on, but before figuring out exactly what goes in that function, just do like comments: Okay, first we're going to do this general thing.
Then next we're going to do this general thing. And then you have that structure. You can literally fill the code into the blocks there and map out the whole thing. And again, just it's going to help them to really understand exactly what he's doing before he starts coding it up.
00:21:32 Interview Interaction
00:21:41 Sam: Now, see, this is better where he used the functions first before defining them. Notice how he had to delete all the functions that he defined before, because they weren't relevant to his solution after all that, because he started with those helper functions first.
Now, in a case like this, he has that helper function defined. And so it's going to be a lot… or he has that like main function defined so he can define the helper functions very clearly saying like, first I'm going to do this. Then I'm going to do that.
00:22:09 Interview Interaction
00:25:28 Sam: Yeah, it is hard to say what we want exactly. It would be really good to get very clear on what each of these functions are doing. There's a lot of, kind of iterating on the code. And again, this is where being clear on what it is that I'm trying to do, and then coding it up is going to be so much more helpful because right now we don't really know what it is that we're passing into this function.
What exactly does this function do? We have a function named add node to tree, but is that function adding a single node? Is it adding a path? If it's adding a path, are we defining what the path is that that node has to go into? What happens if that path doesn't already exist? There are a lot of open questions here where it would be really good if we could define that first and then code up something that does exactly that.
00:26:18 Interview Interaction
00:28:58 Sam: Yeah, I think we're getting to the point now where it's like, I'm all for helper functions, but we have so many helper functions now, it's getting really hard to keep track of everything that's going on.
And so this again comes back to – and I'm going to keep saying it – but it's planning out what you're going to do before you do it. And then making sure that things are and then like with Python, for example, if we want to print something, if we want to have a pass in like the depth that we are in the tree, we could just use that as an optional parameter, or like a default parameter in our main function. We don't need to write a whole separate function here.
So yes, that's a minor detail, but we're just adding, I mean, this is, what, the sixth or seventh function that is taking us to solve this problem, which is this whole problem. Yes. It's nice to have a couple of helper functions, but I would, I mean, I haven't done the math on this, but I'd say maybe four. Four would be a good number. Beyond four, it starts to get really complicated. And it's like, can we just do this in one?
00:30:06 Interview Interaction
00:30:17 Sam: This is also something where he could store those in the indent or the depth in the node of the tree too. There are a lot of different ways that he could do this.
So one is that he could track that function, but two, if he planned ahead and he knew that you needed those indents, he could just say, okay, in those nodes, when I construct the tree, I'm going to add a depth parameter or I'm going to add a depth, a value as well to each node. So that way he just does this pre-order traversal and then print it out based on the depth and the value of the node.
00:30:54 Interview Interaction
00:32:42 Sam: This might be a minor detail. And it sounded like this guy might not be a Python developer as his primary role, but it's bothering me that he's going to be printing everything out on separate lines.
This is something where a formatting string and just putting it all into one would be so much better. And this is also something, honestly, there's no reason that he can't just Google that.
Yes, he should ask his interviewer first. He could say something like, do you mind if I look this up real quick or, before his interviewer said that he didn't really care too much.
And it's, I'm not sure that they're even going to get time to run this anyway, but he could just put something that he thinks is going to work or put some helper function for this, but the way that it's going to be right now, it's going to have spaces on one line then dashes on the next line. Then the name on the next line, which kind of defeats the purpose of the formatting that we have here, because it's like if you have spaces on that line, on that first line, and those are on the line by itself, you're not actually getting indentation that way.
00:33:42 Interview Interaction
00:37:45 Sam: So part of getting lost in the details here too, is, again, a result of we've been jumping around between different functions. And so if you are going to define a helper function, you need to very clearly define what is the behavior of that helper function going to be,
because you're going to come back to this later; you're going to review it and you're going to solve it at a different point. And so you need to know exactly what it is that you're solving, or you're going to run into problems like this right now.
I don't honestly remember exactly what this function was supposed to do. I remember what I think it should do, but that may not be exactly the way that he's using it or the way that he's implementing it. And so even if he did have time to finish the code here, I'm guessing it would take a lot of time to debug everything just because we don't know exactly what's going on.
We know exactly what these different functions are doing. And so it's really, really key that we take the time to just be clear. If you have clarity on what you're doing, then the coding part is relatively easy. It's not trivial. I know it's not trivial, but the coding part is going to be so much easier if you know exactly what you're doing.
00:38:59 Interview Interaction
00:40:42 Sam: Okay. So we'll stop here. I'll link to this video below, in case you want to check out the interviewer's feedback for yourself, because there's about 10, 15 minutes of his feedback. That's probably worth taking a listen to.
As we watch this, hopefully there are a couple of things specific that you took away from this. One, again, being really clear on what it is that you're doing before you do it is so, so key. If you're clear on what it is that you're going to do, then coding becomes a translation job. It's translating that conceptual algorithm into code. With things like tree traversals, that's really that fundamental data structure knowledge that you need to know for your interviews.
Generally with this interview, I would say that he did decently but not great. There was a lot of time at the beginning where he was playing around with different solutions that weren't really optimal for this interview. And he took the time to go down these paths that weren't the right path.
If he had just been more organized in his thought process and really focused on what is the goal and where am I trying to get to and made sure that he wasn't going down some rabbit hole that wasn't going to pan out, that would have been really helpful. Taking that step to zoom out and think about, okay, does this data structure, does this input data match some data structure that I'm familiar with that I could use? That's also a really valuable technique that he could have used here.
