# Breaking Down My Google Coding Interview ft. @SajjaadKhader

## Метаданные

- **Канал:** Conner Ardman
- **YouTube:** https://www.youtube.com/watch?v=1qQ3hmXAxL8
- **Источник:** https://ekstraktznaniy.ru/video/31409

## Транскрипт

### Segment 1 (00:00 - 05:00) []

Today we're going to be completing the infinite content loop as I react to a sort of Google style coding interview that I did over on Sajad's channel. I want to sort of walk through what my thought process was during this interview. Sort of how I go about approaching a coding interview question and hopefully I can sort of break some of these things down for you, show some of the mistakes that I made, and that can hopefully help you in your own coding interviews. Okay, let's get started. $194,000 is how much Google pays their new grad software engineers, which by the way, that's crazy to think about. I think when I was in Newrad, my new grad salary was around like 160 and that was salary plus all the other forms of compensation, but that was also back in like 2020. So, of course, things have gone up. It's a crazy amount of money, which also means crazy competition and notoriously difficult interview. So today I'm pulling back the curtain and I'm hosting a mock coding interview with the — Also, can we just take a second to acknowledge how absolutely incredible his editing is. So amazing work to his team, — former Meta software engineer. I picked an actual question that has been used at both Meta and Google for their interviews. And my goal throughout this is for you to really understand how a top 1% software engineer, — I'll be honest, I don't know if I'd call myself a top 1% software engineer, but I appreciate the gas really goes about problem solving. And as you're watching this video, try solving the question on your own. It will be challenging, which is the whole point. When I present the problem, pause the video, attempt a solution, and then come back and see how the XMA software engineer tackles it. And with that being said, let's get into it. Hey Connor, how are you doing today? — Good. How are you? — Good, good. So today we're going to go over a coding interview question. You're going to have about 20 30 minutes. I'm going to paste a problem for you to solve. The most important thing for me, — one note I will say on how this differs from a normal coding interview. A typical coding interview, the question he asked would be a question you'd want to answer in about 20 or 30 minutes. But if you were asked a question that was that easy, you'd probably be given two different questions. So in a meta interview, this would likely be one of two questions you were given for about a 45minut total interview. — Really hear your thought process as you're going through the question. Whether you actually get the right answer or not, I'm more interested about your problem solving. So, — and that also is true. It's of course important and good to get the answer correct. But also sort of equally as important, if not even more important for some interviewers, is how you actually go about solving the problem and your ability to showcase your problem solving skills. Get started. — Yeah, let's do it. — All right, cool. Let me paste the question for you real quick. Given a string s of open parenthesis, closed parenthesis, and lowercase English characters, your task is to remove the minimum number of parentheses in any position so that the resulting parenthesis string is valid and return any valid string. Formally, a parentheses string is valid if and only if it's an empty string, contains only lowercase characters, or it can be written as a b a concatenated with b, where a and b are valid strings. Or it can be written as parentheses a close parentheses where a is a valid string. — So just to clarify if we come below here if we do like this is I would assume valid this is not. So the idea is just same number of opening and closing and then like something like this that would be valid right yes and then does the order matter here? So if we did like this or wait that's still something like this right that's not valid right even though it has the same opening and closing. They're just Yeah. So, one thing I do here, and I do this in most of my interviews, is I ask some clarifying questions to sort of clarify the question they asked me to make sure I understand it. And I'm even going so far as to ask questions that honestly I pretty much know the answer to, right? Like, I understood the idea of what valid parenthesis means. But for one, I want to show the interviewer that that's a thing I'm thinking about and I'm thinking about clarifying the question before I start to solve the question. And two, I just want to make sure that I am correct and I'm not making incorrect assumptions because while it does waste a little bit of time, it takes a minute or two, you could waste a lot more time if you try to solve a question that isn't the question they were actually asking. It's like in different orders. — Mhm. Correct. So to make it clear for you, let me actually paste in an example. In terms of looking for minimum number of parenthesis, uh, as you can see, we effectively based on the input, if you kind of think about it like a dangling parenthesis right here. Yeah, that isn't necessary for the output. And essentially it being a valid parenthesis, there's no opening for this one. — Yeah, that makes sense. So, sort of what I'm thinking is, yeah, like I said, the actual English characters, I think we mostly just ignore and just have to preserve. Uh, and then for the opening and closing prints. Also, for a little bit of context here, I think he cut out in the edit a small bit of the conversation we had in clarifying how exactly this question actually works. So, I think that might be why I said something like I just said or something of that nature. I forget the exact phrasing I use, but that wasn't actually in the video. So, I think there was a small bit of the conversation that

### Segment 2 (05:00 - 10:00) [5:00]

actually got cut out just to keep the video nice and quick. Yeah, I did make sure to clarify that first. is a opening parenthesis always has to come before closing, right? So if we sort of iterate through a string, we have like the three letters that we're ignoring and then we have an opening parenthesy which is good. And had we had a closing parenthesis there, we just remove it because at this point we've seen no opening parenthesis, so no need for it. And I think this is a very good way to think about problems as you're going through them and before you get into the actual coding is to say okay if we go through this very simply sort of as a human what exactly are we going to be doing and what are sort of some of the basic cases that we know we need to do something right in this case okay if we see a closing parenthesis and we haven't seen an opening one yet we know we need to remove that because we just cannot have that and similarly we know if we see an English letter that has nothing to do with the output right those all just stay so those are something that doesn't really matter at all and we can just ignore them. And sort of mentioning these things are going to help you get closer to that solution as well as show the interviewer that you understand the solution and that you're thinking through it in sort of small steps. And there's no way that could possibly be part of a valid string. And then if we see an opening parenthesis, we can kind of just keep track of uh sort of like a we could do like a count. So say like at this point if we see an opening parenthesis we know okay we've seen one then we see another or we see a t we can just ignore that we see another opening parenthesis so at this point we have two and then we see a closing parenthesis that sort of undoes an opening so now we have like one sort of dangling opening if you will and then — another closing so now we have no dangling openings and then we get this last closing so we'd have to remove it because there's no corresponding opening um I think the edge case where just counting might not work though is if the opposite was true. So if the actual issue was so say we had and also I think this is a good way to think about problems to come up with a solution that honestly while I was saying this I already knew it was sort of the naive solution in my head. I'm pretty sure at this point I'd sort of figured out most of the final solution I wanted to get to. But I think it's still good to walk through a very basic solution and then from that basic solution say okay this is where this basic solution doesn't work. Whether it be a time complexity thing or whether it be an edge case that it just actually doesn't work. And here's how we can get from that basic solution to the better solution. And that's not going to work for every coding interview question ever. But it is something I like to do. And it also just helps myself before I go to write the code to sort of rationalize my thoughts. Make sure I understand what I'm going to be doing as well as make sure that the interviewer understands that I'm considering different possibilities and that I've sort of narrowed it down based on some kind of criteria like this. Um, now we need to remove our opening parenthesis. And if all we did was we got to the end and we're like, oh, count is one or two, we don't know what to actually remove. Um, so rather than just a count, I think we have to keep track of like the indices of our parenthesis. So I think what I want to do is essentially iterate through the string, ignore all of the English characters. If we get an opening parenthesis, keep track of it. Um, I suppose we need the last opening parenthesis corresponds like the next closing parenthesis. So it's sort of like a stack type of structure, I suppose. um to keep track of the last one we got. So we get the index of the last opening parenthesis we saw and then the index of the next one and then once we get to a closing parenthesis we say okay that went with whatever the index was of the one we just saw. So remove that from the uh stack and then if at any point if we see a closing parenthesis that and the stack is empty, we remove the closing parenthesis. There's no corresponding opening parenthesis. And if we get to the end of the string and we have extra opening parentheses, we go back through that stack and remove those from the string. Does that sort of make sense? — So effectively are you you're storing the indices of opening parentheses on stacks? — Yes. — Okay. So yeah, I think generally this approach I'm taking of making sure that I have a complete solution and it's fully understood by me and the interviewer before I write even a single line of code. Well, it might seem like a waste of time. Here you can see I've already used up 4 minutes. You won't have a literal timer like this in most interviews, but I've used up four minutes of like the 20 that I guess he allotted me. And that might seem bad, but I think the further and further you get into your career, the more code you write, the more you'll start to realize that the code is simply writing down the implementation that you already came up with. So once you get to the point of understanding it, writing the code should be fairly quick, even if you do make some mistakes along the way. And additionally, he gave me sort of a virtual whiteboard I could use. I used an iPad for this. So if you have a whiteboard, if you have some virtual whiteboard, whatever it might be, it's usually good to walk through some

### Segment 3 (10:00 - 15:00) [10:00]

example of how your code is actually going to work on that whiteboard just because one, again, it helps you rationalize your own thoughts, but two, it helps to make sure the interviewer actually understands what you're doing. Because even if the interviewer knows the question super well, I can tell you firsthand, giving an interview is actually pretty tough. It's pretty hard sometimes to understand the thought process of the person you're interviewing and to follow along with the code that they're writing if they're not writing the code in the exact way that you intended them to and if they're not communicating that code super well. So, it is super important to make sure that you are communicating that as well as possible. Have opening uh a opening parenthesis b and then we'll have for now let's just do one closing parenthesis. So, we're going to start at the beginning of the array and we're going to say essentially, okay, our parenthesis are at zero currently. So, I'll make like a stack here. And in this stack, we will have currently we've seen a parenthesis at zero. And then we move on. We see an A. We don't do anything with the A. And then we get another opening parenthesis. This one is at index uh two. So, we'll add that to the stack. And then we get the B. We do nothing. And then we have this closing parenthesis. And when we see a closing parenthesis, that means okay, this corresponds to the last opening we just saw, which was at two. So we're going to pop two off of the stack. Also, this works and it's sort of a bit of a JavaScripty representation. But if you are going to showcase a stack in a coding interview on a whiteboard, you should probably draw it vertically. I think it's going to be a better way to showcase it. I don't know why I sort of drew it as an array. It does work, but it's probably not the best way to actually demonstrate your understanding of a stack data structure. Erase this here. And now we're at the end and we still have something in the stack and that's index zero. So that means index zero was an opening parenthesis that had no corresponding closing parenthesis. So that means in our initial string, we just need to remove whatever was at index zero and we should have a correct solution. Um, and sort of the other possible scenario is we get to the end here and we have say two more closing parenthesis. So when we get to this next closing parenthesis that would remove index zero and then we get to the last one and this one we have nothing in the stack. So that means we had the extra closing parenthesis in this case. So in this case we would remove that last one. Does that make sense? — Mhm. Yeah. So what are we looking at for time and space complexities? — Yeah. So we're doing one iteration through the string, right? So we're just going through all the characters. So that's sort of O of N. And then after we do that iteration, we have to iterate through the stack to remove everything from the stack. The removing from the stack is O of whatever the max size of the stack is, which is O of the number of like opening parentheses, but we could call it O of N. If n is the number of characters and all of the characters were in opening parenthesis that would be the size of the stack we'd iterate through the whole stack removing from the stack is of one and then let's see so the actual like core part of the algorithm before we do the removal from the stack we iterate through every character uh what do we have to do for every character so if it is an opening parenthesis we push it onto the stack which is going to be of one and if it's a closing parenthesis all we do is remove something from the stack um which is also going to be of one and then the only sort of other edits we do are just like editing a string just removing like one character um which is not going to have any effect. So yeah, I think we should be o time and the stack is our space. So o space as well. I don't think my explanation here was necessarily the best. That said, I do think this is an important learning point on how to answer the question of time and space complexity because I've seen a lot of interviews. I've been in interviews where the answer that's given is oh it's going to be Oven and Oven time Oven space and maybe they even say Oven where N is the number of characters but it is much better to showcase that you actually thought about it and to show that thinking okay so we're iterating through all of the characters so that is ON its own right we're going through in different characters and then for each character what are we going to be doing because if that's O1 then okay it's still O but if for each character we do some work that's also O well now we're doing in work in time. So that's going to be n * n or n ^ 2. And to just sort of think through what exactly is happening at each step in the algorithm is a very good way to approach time complexity rather than just saying oh this is going to be oven. Right? So in this moment I was pretty sure this is going to come out of as o. It's just sort of one of those algorithms that I've seen something similar and I know this is probably going to be an oven algorithm. That said, it's important to actually walk through that with your interviewer to make sure that they're following along with you and to showcase

### Segment 4 (15:00 - 20:00) [15:00]

that you actually understand how time complexity works and you're not just regurgitating some information because you've seen the problem before or seen something similar, whatever it might be. But really, the stack's maximum size is the number of opening parentheses, which is likely much smaller than the size of a string, but obviously it depends on what input we get. — Yeah, we could get like an edge case, right? So — yeah, — would love to see it in code. — Cool. Let's do it. — All right. So, uh, what coding language are you going to use? — Uh, let's use JavaScript if that's okay. — All right. Sweet. — So, I'll come down here, say function, and let's say remove extra pins or something like that. Also, on the point of using JavaScript, sometimes people say, "Oh, you should always use Python or whatever it might be. " If you know Python well enough, I would sort of agree Python is probably the best language for coding interviews. That said, interviews for you is going to be the language that you know best. And for me personally, I just don't know Python that well. Like I know it well enough. I can write Python, but I need to look up the syntax here and there and I just don't know it perfectly. Whereas JavaScript, I feel confident that I can write out idiomatic JavaScript using the correct syntax on my first attempt and I'm not going to have to look anything up or anything like that. So just for me personally is the language that's going to be fastest. Even if it's not necessarily the language that is the best choice for everybody and it's definitely not the best choice. If you were somebody who knew absolutely everything about everything in every language, then Python's probably the best choice just because it's the least verbose. It tends to work the best for coding interviews. But in my case, I just know JavaScript best. So it's what I chose to use that. And is this just going to take in just the string? Correct. — Yes, just the string input. Yeah. — All right. Cool. Okay. So, the first thing we want to do is iterate through the string. It might make sense. I think it's going to be easier if the string is an array just to actually handle it. Just an array of characters, which sort of the same thing. Uh, I just think it's going to be easier code-wise. So, let's actually do that. So, let's say const uh I'll just call it array is going to be equal to str. split. And we'll just split on the empty string, which is going to give us an array of the characters in the string. Also, things like this are sort of little hacks, if you will, to make the code easier to write. And you can do these things in coding interviews. Probably isn't something I needed to do. There's probably a way to do this without doing that. But it made the code easier for me to write. And those little things, if they're not affecting the time and space complexity, can be a good thing to do, but also it can also be good to mention to your interviewer, which I didn't do here, that, hey, doing this does technically slow things down a little bit. But personally, I think it's a good trade-off for this particular case because it's not going to affect the overall time complexity and it's going to make the code much easier to write and much easier to read and easier to maintain and all of that. And then we're going to need that stack. So let's say const stack. In JavaScript, we just use arrays for stacks. Love that. And then what we want to do is iterate through our string. Or really, we can just essentially iterate through the array. So let's say let's give this a better name. Say characters, I guess. Okay. So let's I suppose we probably need just a let's just use a traditional for loop. It would probably be easier. So I probably should have just used a for each loop here. I don't know. I mean I do know my reasoning here was I wanted to avoid issues with that concurrent modification during the for each loop. But in hindsight had I thought about it a little bit better. We weren't going to have that issue. So we would have been able to use a for each loop instead of the for loop. it would have looked cleaner and I would have been able to solve this without that concurrent modification issue. But using a traditional loop is fine. It just isn't particularly idiomatic JavaScript. And if I'm an interviewer and I see somebody say, I want to use JavaScript, that's the language I know best, I'm like, great, go use JavaScript. But then if they start writing JavaScript code that's not idiomatic JavaScript like this is, then I'm like, wait, if this is the language you know best and you don't even know the language that well, like what do you know? So be very careful with the language you choose to use and with making sure that you are following the conventions of that language. Let I equal zero. I is less than chars. length and I ++ for each character. What do we want to do? So if the character is a letter, we're doing nothing. If the character is an opening parenthesis, we are adding to the stack. And if it's a closing parenthesis, we are removing from the stack. So let's say if chars at i. So if chars at i is a opening parenthesis. Yeah, that's right. All right. So if it is an opening parenthesis, we want to say stack. push and we need the actual index. So we'll have our stack be just i. I think something I should have done here is add some comments to say sort of what these different cases were to say if we have an opening parenthesis this is what we're doing closing normal

### Segment 5 (20:00 - 25:00) [20:00]

character this is what we're doing I think that would have made this easier to follow as I'm writing the code and you'll see in a moment I do make some mistakes here and it would have prevented those mistakes had I been doing that — really quick uh why did you put a triple equal sign and not a double equal sign — yeah so in JavaScript double equal sign is equality in terms of it's loose equality. So triple equals is going to be equality with the type and the value whereas double equals is equality of just the value. So for example we had like five double equals the string of five in JavaScript land that's true but if you do triple equals it's false. — So — gotcha. Yeah. — Okay. Cool. — Fun JavaScript things. All right. So if we have an opening parenthesis, we'll just push onto our stack the index. Else if we have a closing parenthesis, so if chars at i is a closing parenthesis, then what do we want to do in this case? If it is closing, we want to see do we have something in the stack? If we do, we want to remove that corresponding element from the stack. say like yes this was valid and part of our string and if it's not we just need to remove this closing parenthesis from our output. Let's say if uh stack. length is greater than zero then we will do stack. pop. One thing to note also is if your code starts to look like this where I've got a function inside the function I've got a loop inside the loop I've got an if check inside the else if of the if check I've got another if check. You're starting to find like all this nesting. There's probably a better way to be doing it. And I probably should have recognized in this moment that there's probably a better way to be doing that to write it cleaner to make it easier to read because this is getting very hard to read. And I know as an interviewer maybe he's just way better than me. He's definitely way smarter than I am. Maybe he's able to follow this. But I as an interviewer would have a hard time following this if somebody was doing this because it's sort of hard to fully understand what exactly somebody's doing with all this nesting and to understand what the purposes of all of these different nested blocks if there's not comments or something like that. Otherwise, we need to actually remove this from the output. So, what is removing from the output actually mean? Um, I suppose we could just build up a like result string. That might be the easiest way to do this rather than trying to edit the one we already have. Uh yeah, I think that's probably going to be easiest to make sure we're not like concurrently modifying this array and doing something weird. I probably should have thought about this a little bit more before I just jumped to a way to do it. You'll see in a moment that I decided to change up the solution and how I did this. Didn't really think too much about this. I just sort of started coding, realized, oh, I need something for the output. So I was like, okay, I'll create some like result string and that'll work. And I mean that probably could work, but I find very quickly that that's not the best way to do it. And had I just sat there for a second and said, "Hey, I need to think for a second. " And you can do that with an interviewer, you can say, "Hey, can you give me like 30 seconds just to sort of think about this and process this? " Had I done that, I would have thought about this and been like, "Okay, this isn't the right way to do this. " But I didn't do that. And I just sort of immediately chose the first solution that came to mind, which is typically not the best thing to do. So let's say let's output equal an empty string. And here we'll do Yeah. So if the if we had a closing parenthesis, we just don't do anything or we remove from the uh stack, but we're not adding to the string. Otherwise, we want to actually add this uh closing parenthesis into our output. So we can say output plus equals chars at i. And the same would be true with the opening parenthesis. So these we're going to actually add to our output. Also along the lines of confusing code, confusing things to do during interviews, and just bad code quality. If you find yourself literally taking a line of code, copying it, and pasting it somewhere else to exist in two places, probably not great. Doesn't mean it's always bad. a problem, but it's a thing to think about. Often times that means you're probably not doing this in the cleanest way possible. And it's a little redundant to have this in multiple places, but do it this way for now. And then otherwise, so if we didn't have any parenthesis, we have just a English character and those we just ignore. So we can say else we'll also add those to the output. Output plus equals chars at i as well. Okay. After this loop is complete, what we should have is an output string where we have removed any dangling closing parentheses essentially because those are the ones that we were here and we skipped adding them to the output essentially. Um, but we still have the potential for dangling opening parenthesis. So what we need to say is essentially while the uh stack. length is greater than zero. So while we still

### Segment 6 (25:00 - 30:00) [25:00]

have some of these dangling opening parentheses, we just want to go remove them. So — we need to remove them at the index that they were here. But I suppose that index is different than the index in our output, right? — Mhm. — All right. So actually what I want to do is let's get rid of this output thing. And instead of doing that, all right, so this is also, I think, a mistake I made. Not necessarily the process of getting rid of it. I think that's good. I needed to get rid of it. Like I said, it was a bad decision, but what I think was a poor way to do it is what I just did where I started deleting it before explaining what I wanted to do instead. So when you start deleting code, it's very confusing from the interviewer perspective. Even if in my head I know what I'm doing, from his perspective, it's hard to tell what exactly is happening because all I've done is deleted code. I didn't really say why I'm deleting it or what I'm going to replace it with. So, I should have discussed those things first and then gone back to actually delete it so that he understands what I'm doing. If any point you're writing code, whether it be adding code or removing code, and your interviewer doesn't know what the purpose is of the thing that you're currently doing, that's a problem. You're not communicating well enough. And I think in this sort of moment, I didn't communicate well enough. I also didn't think through enough of what exactly it was I wanted to replace it with. And you'll see that in a second. I should have taken a bit of time to say okay this version is not going to work because of this thing I just thought of let me think about what we can do instead and let me explain rather than just immediately deleting that thing let's say uh whenever we remove so let's get rid of the output stuff so this actually simplify the code a lot anyways we don't need that all right so let's get rid of the output instead when we actually we need remove too Watch. Hold on. Hold on. Let's put it back. We need the part. So, essentially what I want to do is rather than keeping track of this output, we're just going to update the chars array. And when we remove something, I'm just going to put an empty string there. And then at the end, we can just join the chars array back together. And the empty string is going to be ignored. Okay. Does that make sense? — Yeah. — Yeah. All right. So, if we have an opening string or an opening uh parenthesis, we put it in. If we have a closing parenthesis, if there's a valid opening parenthesis, then we want to pop it from the stack and we are keeping it. Otherwise, oh, this was actually backwards before. So otherwise, we need to say chars at i. So this is when we had a closing parenthesis, but we had nothing in the stack. So in this case, I want to say chars at i is going to be equal to an empty string. And then down here, we don't actually need this else anymore. — So, — so that's effective removal from the string. — Yeah. So, this is Yeah. By making it an empty string, in this case, we're just removing it from — Mhm. — it's effectively removing this without changing the length of the characters array. That way, — we when we do this while loop at the bottom, those indices are still the correct indices. — Okay, cool. — All right. So, now all we need to do is say while stack. length length is greater than zero, we can do chars at stack. pop, which will be the next dangling opening parenthesis is going to be equal to an empty string as well. And then the last thing we need to do is join the characters back together as a string. So let's say return the characters join. And join takes in the like delimiter. By default, it's a comma, I believe. So, let's just pass in an empty string so that it just joins them all together. Yeah, I think this should work. — All right, you got a small little syntax issue at line 30. — I don't know how that happened, but also I have noticed that whenever I'm trying to code in a video, in a live stream, or like in a coding interview back when I was doing those, the amount of weird typos you get that you would never get in normal coding is like astronomical. I don't understand how it happens, but it does. Oh, yes. — Yeah, there we go. All right. Um, okay. Uh, I mean, this looks like How did I hit the period? Like, it's there. Nothing else I typed is near there. I don't understand how I how they got there. — All right. To me, do you want to test it out with the sample input output that I pasted up here? — Yeah, for sure. Let's come down below here and say remove Let's log it out, I guess. Hey, console. log remove extra PNS. Let's pass in this string and then I'll just comment these out manually. All right. Run this. Yeah, we get — all right. — We get that. Is that the same? I believe so. We could also if you want do a couple edge cases. So — like if all we had was like — this guy. — Okay. So just remove that. — Yeah. If we had — I I'll just paste a couple inputs outputs at the top for you to test out. You want to try that one? — Yeah. Let me copy that. And this one

### Segment 7 (30:00 - 35:00) [30:00]

we'd expect nothing, right? Yeah. So, we get nothing. You can't even really see it, but yeah. — Um, — okay. And then let's try this one. — Yeah. Copy that. Paste that guy. Maybe. — Yeah. Seems like that's it's working. — Awesome. Well, it looks like you got uh these answers pretty well and it looks like it's pretty efficient. Do you have any further thoughts on this if you were to enhance it by any means or do any other things to it? This is a hard question to answer and it's one that you do get asked a lot in coding interviews. And one way I like to approach this and you'll see I kind of do this here is there's sort of two answers, right? There's the improve code answer and then there is the improved algorithm answer. And often times I don't have an answer to the improve algorithm thing. So if I have thoughts I can sort of say, hey, maybe we could explore these different areas that could potentially improve the algorithm or maybe it just could be a trade-off, right? If we know that the input's going to be one with a lot of parentheses or very few parenthesis, maybe that'll change the way we want to approach things, change the data structures we want to use. But the other thing you can say is just here's how I would improve the actual code quality, how to make it more idiomatic. And things like that are usually pretty obvious and pretty easy to talk about because typically in a coding interview, you're not writing the cleanest code you've ever written. So it's easy to go back and say, "Hey, instead of like this for loop, I would have used a for each loop or something like that. " — Yeah. I mean, I think for one, we could probably clean up just the code in general a little bit. Not necessarily from a time complexity perspective. Uh, but — Mhm. — it is I think there's just like a lot of nesting happening and also just doing this in JavaScript. It's not really this isn't particularly idiomatic JavaScript using like traditional for loops. I think I did that to avoid concurrency concurrently modifying the array when I initially was thinking about it and then we switched to this method of like editing the actual value to like an empty string and because of that this also if it's not clear when I'm talking about concurrently modifying the array essentially what I'm talking about is when you use methods like for each map filter reduce etc. If you're also going to be editing that array and removing things from that array at the same time as iterating through it using one of those functions, it can be a little bit confusing. Although, it can also be confusing using the for loop. So, I don't even know if that was good reasoning. And he sort of just nods his head and agrees, but I don't know that was actually good reasoning. So, make sure you're thinking through the things both that you're doing and you're saying before you do and say those things in an interview. It could be like a for each loop or uh something of that nature. And I think it just like look a little bit cleaner. Uh but yeah, I think that's kind of the main thing in terms of efficiency. I think it's probably at least I can't think of something better. — Yeah. Uh there is one scenario I want to paste for you. So sometimes certain inputs can have two different types of outputs. Now if we actually try this string that I just pasted. So it'll give one of the possible outputs of basically like this first possibility. However, this second output right here is also another valid uh possibility. If you had to do a little bit of deduction, what do you think is the implementation difference? Like just to be clear, you're still accurate in your — Yeah, this is also something I should have asked about in the very beginning is will there always be exactly one correct solution given one input? And the answer with this question is actually no. And granted, it didn't really affect the outcome that I came to, but it would have been a good clarifying question to be asking — response, but what do you think is the difference? — Yeah, I had not even considered the fact that there could be two solutions. So, I'm sort of going left to right here and saying, okay, let's say every opening needs a closing, and if we find a uh closing that had no opening, let's remove that. Presumably, if you went right to left instead in the exact opposite implementation, you would get at times like sort of an opposite result, if that makes sense. — So, you're pushing for the closed and popping for the open. — Yeah. If you did, yeah, if you iterated right to left and then Yeah. — essentially reverse the if checks to do the opposite thing. — Cool. Well, that's about I had for you today. Do you have any questions for me? — No, I appreciate you. I wasn't expecting him to ask that given that this is like a YouTube video, but if you are in an actual coding interview at Google or Facebook or whatever, make sure you always have some questions to ask the interviewer at the end. It's important to seem interested and to have some good conversation and to make the last impression they have of you be a positive one. That is really the best way to go about doing that. So, make sure you have some questions prepared that you want to ask. Taking the time. — Awesome. Cool. Well, I'll talk to you later then. Take care. Bye. You too. And that's all I have in this video as well. So, make sure you go give Sajad a subscribe. I'll have his link down below. And a big thank you to him for having me on his channel. If you do want to see more coding interview content

### Segment 8 (35:00 - 35:00) [35:00]

let me know and maybe I'll make more of these types of videos. Otherwise, I'll see you all in the next