We helped write the sequel to "Cracking the Coding Interview". Read 9 chapters for free

Python Interview with a FAANG engineer

Watch someone solve the clone graph problem in an interview with a FAANG engineer and see the feedback their interviewer left them. Explore this problem and others in our library of interview replays.

Interview Summary

Problem type

Clone Graph

Interview question

1) Given a reference of a node in a connected undirected graph. Return a deep copy (clone) of the graph. Each node in the graph contains a value (int) and a list (List[Node]) of its neighbors. 2) Given two sparse vectors, compute their dot product. Implement class SparseVector: - SparseVector(nums) Initializes the object with the vector nums dotProduct(vec) - Compute the dot product between the instance of SparseVector and vec A sparse vector is a vector that has mostly zero values, you should store the sparse vector efficiently and compute the dot product between two SparseVector.

Interview Feedback

Feedback about Ferocious Singularity (the interviewee)

Advance this person to the next round?

Yes

How were their technical skills?

4/4

How was their problem solving ability?

4/4

What about their communication ability?

4/4

TC solved both problems quickly and without bugs, ran through the code and identified bugs and fixed them. Correct complexity analysis for both problems Areas of improvement - Stay focused during dry run, I had to prompt TC to rerun a line of code in which they had a bug, this is not something that would lead to a reject but still worth avoiding in a real interview - Complexity analysis for DFS mentioned O(N) whereas it's actually O(V+E)

Feedback about Admiral Hex (the interviewer)

Would you want to work with this person?

Yes

How excited would you be to work with them?

4/4

How good were the questions?

4/4

How helpful was your interviewer in guiding you to the solution(s)?

4/4

Interview Transcript

Admiral Hex: Alright, great. So this is your interview with interviewing IO, and I'll go through like a simple DSA algorithms question, just logistics on the interview. We'll probably spend the first five minutes doing intros. I have two questions that I want to ask you. We'll see how you get on with the first one and if you have time we can go into the second one as well. And we'll try to leave some time at the end for feedback and any questions you have. I'll also provide you with written feedback after this interview. Does that all sound good?

Ferocious Singularity: Yeah, that sounds great.

Admiral Hex: All right, great. So you can. I can sort of briefly introduce myself. I'm Anshul. I work as a staff ML engineer for share chat in the UK. And before this I was at Meta again as a ML engineer working on ads ranking. And, you know, before that I was based out of India working as a data scientist and as a software engineer in different startups. Yeah, maybe you can introduce yourself.

Ferocious Singularity: Yeah, I worked at Google as an entry level software engineer for almost three years, recently got laid off. Prior to that I got a PhD in essentially medical imaging, bioengineering and nuclear physics was the background, and so decided I didn't want to do academia, found an opening at Google and was able to switch there. Now hoping to stay in software, maybe in the long run switch into ML to utilize my PhD better for now, software engineering.

Admiral Hex: Yeah, sounds great. And can you share like what kind of interviews you're targeting, like Meta or Google?

Ferocious Singularity: Well, right now I don't think Meta is doing e four, so I'm targeting right now Amazon.

Admiral Hex: Okay.

Ferocious Singularity: And then I have a phone screen with Quora and Reddit coming up.

Admiral Hex: Right, great. So I'm not too familiar with specifics of these companies. The coding interview that I'm gonna do today for you is gonna be more in meta style. And I can talk a bit about like my experience with different companies, like how they typically interview, but just sort of keep that in mind a bit so every company has their own nuances. Right. All right. Anyway, we can now get started with the question, if you're ready.

Ferocious Singularity: Sure. Yeah, let's do it.

Admiral Hex: Okay, great. Okay, so this question is going to be really simple to communicate. It's basically like you're given a graph and you have to clone it. I'll just paste the description here. Yeah, so you're given a graph. The tricky part is it's sort of implemented as a custom class, kind of a typical implementation of a graph. So you have a node, each node has a value, and it also has a list of neighbors, which is again a reference to other nodes. Right. So this node is connected and undirected, like the graph is connected and undirected. And you have to return a function that takes the graph and returns a deep copy of the graph.

Ferocious Singularity: Okay.

Admiral Hex: Over to you.

Ferocious Singularity: Okay. So it's an undirected graph. And I start with a, I'm just given a node to start with.

Admiral Hex: Yes, you're given a node in the graph.

Ferocious Singularity: Okay. I mean, my first thought is I could just do Df's, but use a scene or visited set to keep track of the nodes I've seen already. So I don't revisit nodes and reduplicate them.

Admiral Hex: Okay.

Ferocious Singularity: So that should end up with me visiting each node once. So like on time. Yeah, that would be it. I don't think there's any other complexity with that.

Admiral Hex: All right, and what will you do in the bfs?

Ferocious Singularity: So essentially, I'd visit a node like the starting node, and then I would append to the neighbors list. Well, sorry. I'll visit a node, make a copy of that node by creating a new node. And then to that node's neighbor list, I would append each of the neighbors of the original node, a copy of the neighbors of each of the original nodes. So the appending function will append the DF's of each neighbor. Does that make sense? So maybe I should type this out. So go through with start node, create copy with Val for each neighbors. Copy neighbor, DF's neighbor. And then before I even start this, I might also add scene here too in the loop before I do the copying. So something like that.

Admiral Hex: So you're doing depth first search, is it?

Ferocious Singularity: Yeah, I mean, I could also do bfs. In some ways, BFS also makes it kind of clean too. We could do that as well.

Admiral Hex: So here, what is DF's neighbor?

Ferocious Singularity: Oh, so because I'm creating the copy for each of the neighbors in the original node, I'd run the DF's to make the copy of the node and return the copied node.

Admiral Hex: Okay, so can you just walk through how it would work with, let's say, just a simple example. Let's say we have just three nodes and it's like a linked list, right? How would this work?

Ferocious Singularity: So I would, it says node one.

Admiral Hex: Connected to node two. Node two connected to node three. Yeah.

Ferocious Singularity: So like something like this, let's say. Yeah, so copy node one and then just make a copied node and then copy.

Admiral Hex: So copy value one prime or something.

Ferocious Singularity: One prime dot. Neighbors are going to equal DF's for each neighbor. DF's neighbor. And then before this, before this, I would also add like a scene neighbor to make sure I don't copy the neighbor again. So in the example that means I would run since there's only one neighbor. In this case it would be out create one. And then, so then, and then I would create two and then create three. And then it would return three prime as enabler for two prime. And then my final result would return one prime. Does that make sense?

Admiral Hex: Okay, and what if the graph has a cycle? Maybe we can just say that there's a connection from three to one, right.

Ferocious Singularity: So if there's a cycle, it shouldn't repeat because of. I'll also do a check for the. So the code would be like if neighbor not in scene. So I wouldn't run DF's unless it's in my scene set.

Admiral Hex: Okay, go ahead and implement this.

Ferocious Singularity: Copy node node we can do here. Next thing is make the node. So we'll do new node equals this node valid. What was it? Neighbors. I think that's right. Neighbors instead of a, instead of a set, I should do a hash map.

Admiral Hex: Right? And why?

Ferocious Singularity: Because I need to return the, because there's cycles. I need to return the. Yep, yep.

Admiral Hex: Yeah. You don't just need to check that it's visited. You also need the node so that you can update. Yeah.

Ferocious Singularity: And then we could just do node neighbor append and then return. Oh, I called it helper. So for meta, I think you hand test it, right?

Admiral Hex: Yep.

Ferocious Singularity: So let's try, we'll try the first case we have up here. So our first node would go through, it would create a new node with value one, no neighbor yet. You would add this node to key in the hash map from node and neighbors. If not in scene. Scene. We create this neighbor helper neighbor. So we run this again with two and then run this again with three. So that would be, so I have this new node three, it has millimeters. So we would have an empty neighbor list right now. And then it will return three, and then it will return two and then return one. So I think it works here. But there's no cycle right now. If there was a cycle for three, one, it would just return scene in neighborhood, which would be the new node. So I think that's fine as well. Do I think this works?

Admiral Hex: Right? What's the time complexity and space complexity?

Ferocious Singularity: Time complexity would be on because I'm visiting each node once. So n being the number of nodes, space complexity would also be on, because I am keeping a scene hash map and I'm assuming the new nodes as output shouldn't be considered.

Admiral Hex: It's a general graph. Are you really visiting each node once? If you're visiting each node once, do you need a hashmap?

Ferocious Singularity: Sorry, what was that?

Admiral Hex: So why would you need a hashmap if you're only visiting each node once?

Ferocious Singularity: I guess I'm visiting each neighbor once. But the hashmap I thought is to be able to return the created node to usually keep track of the created nodes for if there's cycles or things like that.

Admiral Hex: Okay, let me ask this in another way. For a generic graph with, let's say, maximum number of edges.

Ferocious Singularity: I see how many times, sorry to cut you off. So I think you're implying that it should be number of nodes plus number of edges, right?

Admiral Hex: Yes.

Ferocious Singularity: Yeah.

Admiral Hex: Okay. Can you just write that down?

Ferocious Singularity: Yeah.

Admiral Hex: Like the time and space complexity as a comment.

Ferocious Singularity: So we'll do v plus e for vertexes and ages edges for time complexity, and then o by n for space excluding output. Or I guess this would be to be consistent.

Admiral Hex: Right? Yep, that sounds good. I'm just going to type the next question here. Um, so not sure if you might have already seen this question. It's quite a common one, but yeah, still good practice. So let's say we are given two sparse vectors and we want to compute the dot product. So we have to implement a class called sparse vector where you give it the vector and it sort of initializes the object. And this class also has a dot product function where you can give it another sparse vector and it will compute the dot product between these two sparse vectors. And just for clarity, like a sparse vector is a vector that has mostly zero values. So the idea behind this question is you should find some representation to store the sparse vector efficiently, and that also allows you to compute the dot product efficiently.

Ferocious Singularity: Okay, so I guess, how large are these sparse vectors? Why, I ask, is mostly like, what if I just keep the coordinate of each point? So it'd be three, I guess, integers the value value and then like rc for each point. But obviously if it's.

Admiral Hex: They'Re like, it's a one dimensional thing, right? These are vectors, they're not matrix.

Ferocious Singularity: Oh yeah, sorry. It's a vector. You're right. So it would just be, yeah, then it would just be valued by index, right?

Admiral Hex: Right.

Ferocious Singularity: If it's sparse enough, even though it's two points, if it's very sparse then all you need to do is.

Admiral Hex: Do.

Ferocious Singularity: Like a hash map. Index equals valve.

Admiral Hex: Right. And then how would you, and then.

Ferocious Singularity: The product would just be, for you would just loop through the indexes in the hash map. It would be zero if there's not a matching index on the other vector. And so you could just take either one of the hash maps, loop through the elements, and then multiply it by the corresponding index in the second vector.

Admiral Hex: Right.

Ferocious Singularity: Should I write that out?

Admiral Hex: What's the time complexity of this approach?

Ferocious Singularity: Converting the vectors to a hashmap would take on time with n being the number of elements for each vector. And then the dot product would be o n as well. Assuming the vector is not actually sparse, that'll be like the minimum of the number of elements with values other than zero in the vector. All right, between. So for creating sparse vector, o n, element product will be. We could do min v one, v two.

Admiral Hex: What is the possible drawback of using a hash map?

Ferocious Singularity: The one that immediately comes to mind right now is just, if it's less than 50% sparse, I'll be using more memory this way.

Admiral Hex: How will you use more? Okay, because your memory size is the number of keys. Right?

Ferocious Singularity: Yeah. And so I'm essentially storing two.

Admiral Hex: Um, it's a really sparse, uh, vector, like hugely high dimensional, and it's very sparse.

Ferocious Singularity: Okay.

Admiral Hex: So, yeah, yeah.

Ferocious Singularity: Then if it's truly sparse, then that shouldn't be an issue.

Admiral Hex: Um, the space is not an issue, but, um, what is the time complexity of a lookup in a hash map?

Ferocious Singularity: Oh, one.

Admiral Hex: Is it really, how is that achieved?

Ferocious Singularity: How is that achieved?

Admiral Hex: Like, is it really always open in practice?

Ferocious Singularity: My understanding is yes, but maybe not.

Admiral Hex: Yeah, like, okay, when, when you say maybe not, like, what do you know what can cause it to not be over?

Ferocious Singularity: Fun sometimes I do not actually.

Admiral Hex: Do. Are you aware of, like, how hash maps will be, like, sort of implemented?

Ferocious Singularity: Essentially, there's a hash function, right? That's pretty much all I know. The only thing I can think of is collisions, maybe.

Admiral Hex: Yeah, yeah. So what happens if there are collisions.

Ferocious Singularity: Then I actually don't know how hash maps resolve collisions, to be honest.

Admiral Hex: What would you do? Like, okay, so you put a hash function right on the value, and then you use that as the address to store the object. Now, the hash function sort of guarantees, like, with a bunch of keys, that all the indexes will be unique, right? But let's say you have a collision now, there's already a value there. What. What's the easiest thing you can do?

Ferocious Singularity: You could make that bucket contain multiple or change your hash function?

Admiral Hex: No, I mean, every hash function will have some collisions. Right. Of course you can choose a really good hash function, but let's say keeping the choice of the hash function constant for a while, we are using the best possible hash function, but, yeah, like you said, there's a collision, so we add in another object there. Right. And, you know, if by, you know, some dumb luck, we have, like, you know, lots of collisions, then those buckets will contain lots of values, and then your lookups won't be o one. They'll be like o in the worst case. Right.

Ferocious Singularity: Okay, I guess we could also.

Admiral Hex: Yeah, sorry. Yeah, just continue. What can we use instead of a.

Ferocious Singularity: Hash, maybe just a straight list with a.

Admiral Hex: Right.

Ferocious Singularity: With index value pairs.

Admiral Hex: Write an example here of how that list would be. Let's say we had like, this kind of vector. Bunch of zeros. Yeah. So how would this be represented?

Ferocious Singularity: So then this would be one. So this is 012345. So we'll do five one. Wouldn't that be it?

Admiral Hex: Right. And then how would you do the dot product computation?

Ferocious Singularity: So let's assume we have second matrix one. I'll do like seven one. My first thought is you could start with first matrix and then just do binary search for the index and the second matrix.

Admiral Hex: Okay, what is the time complexity of that?

Ferocious Singularity: Then you get n log. Well, not n log n. You get log n for each search times each.

Admiral Hex: Like n login.

Ferocious Singularity: Right.

Admiral Hex: So, like, if you say n is the size of the reduced list, it's n login, right?

Ferocious Singularity: Yeah.

Admiral Hex: Yeah. So can you deduce that.

Ferocious Singularity: Technically these things will both? I guess. I guess we could change it to like, minus n one n two, where n one and n two are the lengths of the two. If you do a pointer in each, you check the value like zero. You would iterate through this matrix until you hit zero or past zero or hit the end. So, like here I'm looking for zero. I find zero right away. So these match, and then I go here at five, I could just resume where I was before, because I know zero was the last element. If this zero isn't here, the last element this would stop on would be seven. So I could iterate so that I can go through each of the matrixes in n one n two time.

Admiral Hex: Can you implement that?

Ferocious Singularity: No. So first I think I'll just do class parse as lowercase. Or I guess it's already a vector. Right, sparks? Vector is already a class.

Admiral Hex: Yeah. Maybe, you know, you can implement the construct or something with you know.

Ferocious Singularity: So.

Admiral Hex: Like num, I've copied the java example so that you can just translate into python. So constructing and take nums. Yeah.

Ferocious Singularity: Oh, I see. So then we take nums here, and then self dot. I'll just call it compressed equals list I comma num for I nums. Num. I think that's all I need. If nothing called I equals, if v two.com, press j is greater than compress I. Um, shoot, all these means zeros. 0100. Okay, so if v two is greater than that, then we just increase this, else j plus equals one. I think that's all there is. So if less than this value, keep incrementing j, and then if it's v two is greater than self.com, press we increment. I, I think that works, at least conceptually. I'd like to test it though. Ah, so we could do v one equals sparse vector this. Oh, we're supposed to hand test it. Right. Okay, let me hand test it then. So this would come down to. So 0151.

Admiral Hex: How would you get that zero, the misrepresentation from your function? Can we just walk through the statement that you've written?

Ferocious Singularity: You're saying, so this is my starting vector.

Admiral Hex: Right. And then what's the list comparison?

Ferocious Singularity: Initialization of this?

Admiral Hex: Yeah. Can you just walk through that?

Ferocious Singularity: Walk through this?

Admiral Hex: Yep.

Ferocious Singularity: Yeah, if, there we go.

Admiral Hex: Yeah, now it would give that, okay. Yeah, I think this works. What's the time and space complexity? I've already mentioned it's n one, n two. All right, now we have some time. I think at this stage it would be a pass for the meta interview, but we have some time. If you want, we can do another follow up. That's up to you. Or we can discuss the feedback.

Ferocious Singularity: What do you think is more valuable? I guess for me, where I feel weak is communication, probably.

Admiral Hex: I think we can do one more follow up. Typically you would not get this since you've already done like two questions in 45 minutes, which is like really good. But let's do a, let's do a follow up. All right. Now the same problem, but now you're dealing with like 2d matrices.

Ferocious Singularity: I see. So I think this was how I was approaching it before. Maybe so we can compress it the same way, but it might not be as straightforward in terms of the dot product now. So let me see if we do, our data structure is now our row column value, although definitely compress it, it becomes how do we multiply efficiently? I mean, I think we could do the same concept. We would first try to match the row if the rows, if we, so if we have v one and has something like one, comma one, comma one two, comma one, and then b two would be zero comma one, comma one. And that looks like we have two comma two, comma three. I think we would first search for mastering rows using similar algorithm above, then search for matching column. Other optimizations we could do if we don't, I don't know how large these matrix is, but if it's really large, we might have to go the first step based on our earlier discussion, if we don't think our collision likelihood is.

Admiral Hex: Nothing changes in 2d, right. It's the same trade offs and everything, right?

Ferocious Singularity: Yeah. Then in that case then I think it would be, I could do like a row by column kind of based search method. So first.

Admiral Hex: Maybe you should think about like okay, how does matrix multiplication actually work?

Ferocious Singularity: Dot products are different.

Admiral Hex: Right? Maybe you can just example matrix and just think about like how does the, how does the multiplication actually work?

Ferocious Singularity: Yeah. Okay, so maybe I'll use a dot trim. So we have like a 0123 and then product, it's a row by column. So that means first we have to check if our rows match the column. So it would be a multiplying with this one, it would be like a two by three matrix. So it would be like, so something like that. And then you perform vector multiplication between this row and this column, right. So we can factor multiplication, we can reuse this dot products concept, right. As long as we store it properly.

Admiral Hex: Right. It's just that you'll need to create like the sparse vector representations properly and then you can just reuse them.

Ferocious Singularity: Right. It, yes. So I have, yeah.

Admiral Hex: I mean, it's up to you whether you want to implement this in case you're feeling tired. It's okay. This is just a extended follow up, I think.

Ferocious Singularity: Yeah, I like the problem. I don't know if I want to be able to code it in time and get feedback or not, but yeah.

Admiral Hex: So I think proceed like, I think it's just that you just need to sort of transpose the second metrics, convert the rows into columns. That's it. And then you can just reuse the above implementation. So usually like if you get the second question for meta, if you do really well on the first thing that you did and implement it really quickly, they will give you this follow up and then, you know, you don't have to completely implement it. Usually you know, they'll ask you like two questions in 45 minutes. With the implementation and time complexity. And, you know, the questions are fairly standard. So, like, these two are pretty good examples of questions. I think the first one, the main trick was, Eliza, that you can. You need to use a hash map, right? And I usually, when I used to interview, I used to give both of these questions together because in the first one, the trick is actually you using a hash map. And in the second one, the trick is actually not using a hash because, like, the reason is a bit subtle, but it's related to collisions. Also related to, like, you know, hash maps are actually difficult to implement.

Ferocious Singularity: You.

Admiral Hex: Know, in practice because, like, you need dynamic memory allocation and stuff. Right, right. Or, you know, you have to take, like, module on the hash function, which increases the collisions. So why have all that complexity when you can just go with the simple approach which you can implement with, like, contiguous memory? If you wanted to do, like, a really low level implementation, you could just have, like, an array, right. And could be like, could even be like a linked list. It doesn't have to be a dynamic array, right. So, like, if you want to do a really low level implementation on any device, it would work very well. And that's why this implementation is better than the hash map. And then 2d case is more about, like, just, you know, like, can you translate the maths into, like, actual code and then handle all the edge cases properly, even though it's. There are not many edge cases, so it's not, like, really complex coding wise either. Yeah. So I think you did pretty well on both these questions. It would definitely be a pass on my end. The only thing I would say is, you know, just when you're doing the dry run, I noticed that, you know, you were sighing a bit before doing that. I can understand it that, you know, it's kind of irritating to have to do that, but, you know, it's always better if you find a bug yourself. Like, I think I didn't have to prompt you a lot to find the bug in the second implementation, but, yeah, just be sort of mindful about that a bit. Right. You know, I understand that, you know, it's sometimes a bit frustrating to have to do that, but, you know, for the interviews, you have to kind of, you know, be in the right zone, you know?

Ferocious Singularity: Yeah.

Admiral Hex: Like, be prepared to do whatever it takes. You know, that's mostly what, like, that's part of what they're testing with these interviews. Like, do you actually want to work there? Will you actually put in the work to, you know, like, show sort of your best side in a way. So, I mean, it's a minor nit. It's definitely not something that would count as any negative feedback to you in the interviewer's feedback, they would definitely pass you. And, you know, you can miss things, but, you know, it's always better. Like once you write a code, you know, sometimes you do miss small things like that. And if you do, like a really thorough dry run, it's very easy to find those bugs.

Ferocious Singularity: Yes. Yeah.

Admiral Hex: I think for me there's another bug on, let's say line 100 where your eyes less than length, but j is, goes up to the length for some reason.

Ferocious Singularity: Oh, yeah.

Admiral Hex: Yeah. I mean, these kind of typos happen, right. And if you do a really. And they're not deal breakers, but, you know, if you like, it depends on the question. So for this question, there are not many edge cases, right. So no one cares. But if there are edge cases and if the interview is evaluating on your ability to actually figure out those edge cases and then you miss one in the implementation or something, right. Then it could be a problem. But usually interviews will, you know, bug you at least a couple of times to try to find it, right. Like if you, if you have a bug in your code which they have spotted and you have not spotted, they'll ask you to try run again or try run it with another edge case. Right. But then sometimes, you know, you might not realize it if you don't try run properly. Right. And, yeah, so it's always better. Like, I mean, you are pretty well prepared. The first question you implemented was without any bugs, even the second one. Like, you realize the two pointer approach pretty fast. Implementation was also pretty good. Right. Like, it's pretty neat and everything. So, like, you know, just be slightly more careful and you won't commit any. Like, just, you know, understand that, you know, whenever you're doing interviews in a stressful situation, you will make mistakes, right. So when you're actually checking it, be very, very careful and be very thorough. And that way you'll avoid these mistakes. And also, that's one of the things we look for as interviewers is that how well do you test things? And if you're able to actually find a bug while testing, that's seen as a positive yourself without the interview having to prompt. So just once you're done with the implementation, dry run it on your own. Don't wait for them to prompt you. Like, take charge of the interview. Say, okay, I'm done with implementation, I'll try run it now and only say you're done. When you know you've done the dry run and you're absolutely sure that everything is correct, then say that, okay, this should work. Okay, that's just like a minor point. Okay, anything else you want to ask me about?

Ferocious Singularity: So some of the stuff I found I've struggled with, it might not apply to meta because I feel like the meta questions are pretty well sparse. But for some companies, or well parsed, I should say. But some companies, I find that the questions are very ambiguous, especially if it's something like more like object oriented design problems. I don't know if you've encountered those, but it might, I guess Amazon might do that too. But it'll be something like, one of the questions I got was like, design a parking system. And so the first step they'll give you, well, like the requirements of a parking spot. And then the second question I got was like, design a parking lot. But then figuring out, well, how do I, what are the ways that someone wants me to implement or utilize a parking spot for the parking lot? Like parsing those kind of requirements quickly. Is there any tricks you have for gathering requirements? Yep.

Admiral Hex: Right, right. So, yeah, like, as you mentioned, you know, when someone gives you an ambiguous problem, they are mainly looking at your critical thinking skills and your ability to ask good questions, verify the requirements. Right. So, I mean, the key is just to ask questions, right. And I think you have this good instinct where, you know, when I gave you like this graph clone problem, I think not with the first problem as much because, you know, you just jumped into like, I'll do DF's and I'll just solve everything on the fly. But later you realize that you need a map while you were in the middle of the implementation. Right, right. So, but then in the second one, you were a bit more careful and you were like, you know, there's some catch. It can't be this easy. Right. And you know, that instinct is right. The interviewer won't ask you like a very trivial question. There'll be some complexity there. And when they ask you an amigos thing, they're looking for you to ask the questions to unravel the complexity. Right. So if it seems too simple, you're probably missing something. So like, try to find that, which would be like, you know, okay, just try and implement it in your head a bit and see where you get stuck. Right. Maybe that's one tip you could use, like try to find where the ambiguity or the complexity is in the problem. Right. So with the parking lot, usually, you know, it's just a 2d grid at the end of the day. Right? Yeah, but how. So the complexity lies in, how do you actually store it in memory? And a simple thing like storing a 2d array in memory is not that easy depending on the context, right. So if it's like you already know the size of the number of spots and everything, you can just reallocate the memory. But if it needs to represent many different kinds of parking lots, you know, the memory sizes could be very different. Then you can't just allocate like a bunch of memory. Right, for the array.

Ferocious Singularity: Yeah.

Admiral Hex: A lot of these things are, you know, sometimes hidden from programmers by language abstractions, but the problem still exists.

Ferocious Singularity: Right.

Admiral Hex: So you can't get away with using a language abstraction when interviewer wants you to explore that complexity, which is, for example, with the second question here, right? You could say that in terms of time complexity, the hash map approach and the list of tuples approach with two pointers is equivalent, right. It's same time complexity, same space complexity.

Ferocious Singularity: Correct.

Admiral Hex: But, but the difference is like if you are with the second approach, you avoid a lot of complexity around memory management, which is abstracted away from you, but when you actually go ahead and implement it at large scale, you'll hit that problem.

Ferocious Singularity: Right.

Admiral Hex: And that's what they're testing. Right. That. Can you think in that direction?

Ferocious Singularity: Yeah, I mean, I think for me.

Admiral Hex: What the interviewer wants from you, and if you don't realize it yourself, like, just keep asking more questions and, you know, just keep asking for feedback, like, okay, this is what I'm planning. Is this fine? If it's not fine for the interviewer, they'll always give you some hint or some step in the right direction because the interviewer doesn't want you to read their mind. Right. They want you to sort of ask good questions so that they can answer it without revealing the solution. I hope that was helpful for you.

Ferocious Singularity: Yeah, I think so.

Admiral Hex: Yeah. Anything else you wanna discuss?

Ferocious Singularity: No, I think that's all I had.

Admiral Hex: Yeah, I mean, and the last thing I'll say is that, you know, like, you are well prepared. Do you actually have any interviews lined up already?

Ferocious Singularity: Right now I just have the Quora and the Reddit phone screen, but they're less, I don't know if they're leetcode even or not. Like these type of problems or not.

Admiral Hex: Yeah. So you have phone screens, you have no on site interviews booked yet, right?

Ferocious Singularity: No, no on sites yet.

Admiral Hex: Yeah. So, you know, it's, it's a tough market, you know, keep your head up. Just because you're getting rejected in this market sometimes doesn't mean that, you know, there's some problem with you. Right. So, yeah, just keep trying. It's a tough market. You, you prepared Pretty well. I don't think lead code is going to be a reason for you to get rejected, but at the same time, you know, it depends on the day, the performance on the day and the pressure. Right. So just have some confidence. You've done well. If you got a meta on site, you would pass it, so. Yeah. And part of it is luck. You can't do anything much about that. But if you get a chance by now on site, you'll definitely do well.

Ferocious Singularity: Glad to hear it.

Admiral Hex: Yeah. It was great talking to you, and I'll send you the written feedback soon.

Ferocious Singularity: Yeah. Thanks so much. Bye.