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 overlapping intervals 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
Overlapping Intervals
Interview question
1) Given two real closed intervals, determine whether they overlap or not. 2) Given N real closed intervals, determine whether they overlap or not.
Interview Feedback
Feedback about DJ Flamingo (the interviewee)
Advance this person to the next round?
YesHow were their technical skills?
3/4
How was their problem solving ability?
3/4
What about their communication ability?
3/4
What went well - - Clarifications made for both the problems were really good, eg. what does real mean or what does closed mean, what it means for N intervals to overlap etc. - There were no gaps of silence, you always thought out loud, interviewer was always clear in what direction you are thinking, this a very good habit wrt interviews. - Overall code quality is excellent, maybe you can read more about Python Production Readability. - Speed of coding is excellent. - Your thinking ability and problem solving was also very good. What could've been better - - Its good to suggest complexities of the written code oneself, without the interviewer prompting for it. - In general, an interview is being guided more by the interviewee than the interviewer. You are leading it, and you are taking constant yes from the interviewer before proceeding. - Writing good test cases. Make sure you write test cases which include edge cases, thoroughly enough before thinking of possible approaches. It will help to build an approach which thorough and complete. And will also aid in writing code clearly. Interviewer need not give any corrections. - Always try to dry run the code yourself without interviewer asking for it, to make sure you haven't made any logical mistakes in the writing of the code. Interviewer should not be in general pointing any mistakes in the code. Some general Google tips - Always save as much time as possible for the main coding problems, like keep intros short etc. - If the interview starts with an LC easy problem, generally it is just for setting up the scene, don't waste unnecessary time on it, try to wrap up in let's say max 10 minutes. - Code quality does matter, especially for higher levels. - Typically the interviewer may not come with elaborate problem statements or test cases, they expect the candidate to dig these things up - good communication is expected. Find a balance between communicating everything clearly and yet not consuming a lot of time in trivial stuff. - Important topics - Graphs (all algorithms), Trees and Binary Search.
Feedback about Stochastic Storm (the interviewer)
Would you want to work with this person?
YesHow 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
My interviewer gives me very detailed feedback after my question. I really appreciate it. He made me clear aware what I did well, and what I need to improve.
Interview Transcript
Stochastic Storm: So coding round in Google, I hope you know it's 45 minutes.
DJ Flamingo: Okay.
Stochastic Storm: You have gone through the process. In case you are aware of, it's typically 45 minutes. Coding round.
DJ Flamingo: Yes.
Stochastic Storm: So let's assume that some five minutes are intros, et cetera.
DJ Flamingo: Okay.
Stochastic Storm: Or maybe the closing questions. So let's do core 40 minutes of technical part. Okay.
DJ Flamingo: Okay.
Stochastic Storm: That would be a good way to go ahead. So what I do is from the next minute, I will start with a coding problem, and we'll go on for 40 minutes, like core technical way, and then discuss some feedback, how it went at the end. Okay.
DJ Flamingo: Okay. Yeah, sounds good.
Stochastic Storm: All right, let's get started. You have already chosen the language. And here we go. So your question is given two real closed intervals. Determine whether they overlap or not.
DJ Flamingo: Okay. So close interval. And I think my question is just to clarify, what if the start and end is the same. For example, I have an interval of 13, the other is three, five. Do we think they overlap or not?
Stochastic Storm: So that's what I mean by the closed intervals part, right? It means that the boundaries are inclusive.
DJ Flamingo: Okay, cool. And. Okay, I think I got it. And I think I pretty well get what you mean. And I can show you example solution using a whiteboard. Do you prefer that or can just write here?
Stochastic Storm: I mean, typically we may not have that luxury of whiteboard.
DJ Flamingo: Okay, so given two interval, the first thing I will do, I will need to sort them based on the beginning, for example, because after sort, it's easier to compare. And then first step is sort. And then I compare the first interval, first right with second left because it's already sorted. If the first right and second law left, they have an overlap. We know they overlap. Do you think that makes sense?
Stochastic Storm: If first right is greater than. What did you say?
DJ Flamingo: Compare whether first right is greater than second left, greater or equal.
Stochastic Storm: Okay. Yeah, it makes sense. Yes.
DJ Flamingo: Okay, so let me just call it up. So the function we want is, can.
Stochastic Storm: We call left and right, maybe bit differently, start or end?
DJ Flamingo: Yes, start, maybe this start. Do you think this better?
Stochastic Storm: I mean, what do you say? It sounds better, right? In terms of an interval?
DJ Flamingo: Yeah, it sounds better. Okay, so let me just code it up. So the function I'm calling here is compare overlap, and we'll need to take two intervals. Maybe let's just make them interval one, interval two. And assuming each one is a list of two numbers, and we will return whether they overlap or not. And the first thing we will need to do is we'll need to sort the interval. I'm a little bit not maybe. Let me just write my own sort function, because I'm a little bit not familiar with how to sort this. Maybe just if interval one, the starting is smaller or equal than the interval two, interval two start first is interval one and second is interval two. First is interval two, second is interval one. And then we just return the same thing, whether the first end is bigger than second.
Stochastic Storm: Stop.
DJ Flamingo: And do you think this is clearly.
Stochastic Storm: Here, it is clear. I mean, do you want to walk through some examples for the.
DJ Flamingo: Yes, we can do that. For example, let's print example.
Stochastic Storm: No, you can do a dryer.
DJ Flamingo: You need to drive it down here. Right. For example, if we compare interval, since it's close interval zero two, and then in this case, since the interval y, the start is smaller than the interval two, we will assign first to be this zero one and second to be this one three and then we will compare the end of the first and the start of second. And since this is larger than the first part, is larger than second part, we will return. True.
Stochastic Storm: Okay. Yeah, it makes sense. Do you want to take some of the edge cases?
DJ Flamingo: Yes, I think since we have one case on this, maybe let's take a case where the second interval is smaller. For example, let's make it three, five, and this is zero, one. And in this case, the two are not overlapped also. So in this case, since the start of the second is smaller, we will go to the second in the L statement, and then the first will be zero 1, second will be 35, and the end of the first is one, and the beginning of the second is three. And since one is smaller than three here we will return false. Do you think we need a statement where the two are the same? There is an exact overlap, like the example I gave before.
Stochastic Storm: It. If you want, you can go through, but this sounds pretty. Okay, I'm good with this. It should work.
DJ Flamingo: Okay, cool. Then maybe that would need a go through.
Stochastic Storm: You want to talk about maybe diamond space complexities?
DJ Flamingo: Yes, I can do that. THe time complexity of those two algorithms, of this algorithm is one because you sort two numbers and then you do a comparison. And the space complexity here is also in the order of one because you allocate two variables and it's a constant complexity.
Stochastic Storm: Sure, that's good. If you don't have anything else to add, we can move to the next question.
DJ Flamingo: Yes, please. Let's go to the next question.
Stochastic Storm: All right. Now the question is pretty much same, but there is one change of constraint.
DJ Flamingo: Oh, given n closed interval, determine whether they overlap or not. So to clarify, when we say overlap, we mean whether they all overlap or some of them overlap. For example, if there is two of the interval overlap and the rest of interval or not overlap, do we consider this as a true force?
Stochastic Storm: Okay, so let me. Whether they all overlap. So let me give you my understanding. All, but it would be this way. Every interval must overlap with these h one another interval.
DJ Flamingo: Okay, I see. I got it. So it is a pairwise relationship. In this case, I think the basic algorithm we can do is for each interval, for each interval, compare pairwise with all other intervals. Check. And then the final result will be just whether all we can find. We can find parallelized match for all intervals. And this will give a complexity of O, n square because we are comparing for each interval, compare all other intervals.
Stochastic Storm: Yeah, that sounds yes. Okay.
DJ Flamingo: Yes. And then, sorry.
Stochastic Storm: Do you want to code it or maybe talk about complexities.
DJ Flamingo: Yes. Do you think I should code this algorithm? Or we can talk about if there is a better one.
Stochastic Storm: What do you think? You can take the call? Maybe.
DJ Flamingo: Let me think a little bit whether we can have a better one. I have a feeling like if we sort all the intervals and then when we talk about overlap, we don't have to compare each of the pairs. If all intervals are authority, they will make this easier to compare.
Stochastic Storm: Okay.
DJ Flamingo: Because for the, for example, if I have the first interval, like one three, to compare whether there are some interval overlap with this interval, I only need to pick the second one, the next one with the smallest start.
Stochastic Storm: Okay.
DJ Flamingo: And then if there is an overlap, I don't have to worry about if there is overlap. I can, I think I still need to consider the first interval in addition to the second one. Because suppose we have an interval, the first interval could be like one three and then is two. Maybe let me make this is two eight. Then for compare with the third one, we only need to compare this two eight because this one extend longer. And every interval that overlap with the first one must also overlap with second one. But if the first one is two eight and the second one is two four, then when we compare with third one, we need to compare with the first one because we only need to compare with the first one because the first one is the largest. So in this case, I think we can do this in a greedy way. Every time after we compare two interval, we just retain the interval that has the largest end because essentially we just need this end information. So it, do you think that makes sense?
Stochastic Storm: Um, that is making some sense. But can you take a test case where we at least have some four or five intervals and then can you just try to walk through.
DJ Flamingo: Yes, let me just write it. You said I can try to optimize it or test it.
Stochastic Storm: No, just walk through it with a good test case. Just that this is worth.
DJ Flamingo: Okay, yes, I can do that. For example, just give some case here I was zooming since I already sorted so it's, and then we don't have to worry about the, like sort them again. Maybe here I can call it eleven. Okay. In this case we would just need to compare the first and second interval. First compare the first two interval, and then we know the overlap by compare the beginning and the end and the beginning and the start. And after this we only need to take the first one because the first one have a larger end. And then I think this is okay, we compare the first one with the third one we can find. Okay. The third one is still overlap and then we can also compare which end is larger. The first one has a larger end, so we still retain the first one in this case and then we compare. In the search tab, we compare the first one with the third one. We can see the overlap and not the third one, the fourth one. And this one has a larger end. So we need to retain this one. And then it essentially become the case where we compare the last two and we find they still overlap. So the result will be, result will be true. Do you think this makes sense?
Stochastic Storm: Yes, this makes sense. Do you think this is going to work in every possible case?
DJ Flamingo: Let me think. We can play that a little bit. Essentially we just need to consider each of the case here. I think it definitely works when the two interval doesn't overlap where for example, this one is ten, this one.
Stochastic Storm: If.
DJ Flamingo: This one is ten and this one is eleven, then we can quickly determine this is not what we want. And the other case we can. So this should work. The other case we need to concern is, I think we test this an overcap case. We test the case where things is contained, one interval is contained. We test the case where they overlap, but there is no one contain the other.
Stochastic Storm: So.
DJ Flamingo: Yeah, I think it worked. On all cases there is always three case contain an overlap and overlap.
Stochastic Storm: Okay, so you sure?
DJ Flamingo: Can you give me an example where things not work? I think.
Stochastic Storm: Okay, let's think like this.
DJ Flamingo: Okay, so let me do a. Yeah, let's see whether this case will work. Oh, let me back to one step. Since here we are determining whether each interval have overlap with others. Is this going to work? I think it's going to anyway, let me walk through this case. We will first compare this two. This will be one. This is fine. And I'm going to copy this one down. So the next step is we compare one to three, the end on the beginning, eight and three. This is still larger. So this is one, eight and then the thing return is nine and six. And then what we compare is one, eight and 916. And in this case they don't overlap. But I got what you mean. The high level question is we only need to find if we will return true, as long as one of the interval there is a pairwise match, we don't have to match the entire segment. So then since this doesn't match, we need to. But I think the high level algorithm should still work. We can just add a small fix in this case where when these two not overlap, we don't immediately return false. We will just discard the first one and starting to compare the second two. The last part, next part. And then we can find. Okay. They still overlap. So we will still return true. We will return false only when we find interval. It neither matched the interval before it nor matched the interval after it. Do you think that makes sense?
Stochastic Storm: Just to be clear, with respect to one interval you are comparing with particularly that interval which is the largest ending towards the left, right?
DJ Flamingo: Sorry. If I pick the.
Stochastic Storm: Let's say there are some intervals. I one, two, I three, I five.
DJ Flamingo: Yes.
Stochastic Storm: When you are seeing any, in any interval towards the left. You are comparing with largest ending interval, right? Yes, that's the fundamental idea.
DJ Flamingo: What are you doing?
Stochastic Storm: Towards the right.
DJ Flamingo: Okay, I got what you mean. We should also compare things towards right. But I think since things are symmetric, if this interval, the Nth interval has something match with things towards the right. Which means if we first consider that interval at the right. This will match something towards the left with the nth interval. And then for example, in this case, when I consider this 916, initially I will only trying to match the thing in on the left. And then when I found no match, I will take this interval and then trying to match the things on the right of it. Like trying to take this one and consider this one.
Stochastic Storm: That point is understood. What you are trying to say is you will check on the right only when something in the left wasn't overlapping, right? Yes, but if something didn't overlap left, what's your action?
DJ Flamingo: If something didn't overlap, I will make the. I will make the current right node be the left. And then keep trying to match on the right.
Stochastic Storm: That's what my question is. Towards the right you are understanding my main question. Towards the left you are comparing with the largest ending interval towards the right. What are you going to compare with? Till? What level are you going to compare with?
DJ Flamingo: I think if we do this, we should compare with the smallest starting interval. Because.
Stochastic Storm: Exactly.
DJ Flamingo: Magic.
Stochastic Storm: Good. And which is the smallest starting interval?
DJ Flamingo: That one. We should sort it and sort it in the other order and traverse backward.
Stochastic Storm: No.
DJ Flamingo: Okay, you are right. The smallest should be just next one.
Stochastic Storm: Exactly. Perfect. Immediate. Next.
DJ Flamingo: That's it.
Stochastic Storm: There is nothing other to compare on the left. Compare with the largest ending one or the immediate next one. Nothing else. That's it. After this I will only get something bigger. And that will anyways never overlap if it hasn't overlapped with this.
DJ Flamingo: Yes, I agree.
Stochastic Storm: Now this makes sense. I think we are good at time as well. You can go ahead and start coding.
DJ Flamingo: Okay, let me just code this up. So assuming we have a list of intervals, let me just write here. Compare. Overlap. This will be intervals. So I need to assume if there's only one interval. Let me just remove those countercase. If number of interval is smaller, you.
Stochastic Storm: Can assume there are more than two intervals. You can avoid just assume there are more than two intervals.
DJ Flamingo: More than two. Okay. Then we will need to start first or the left interval. Left interval is interval. Let's do it. Check. And then for right interval, in intervals from one. And then we need to compare whether those two overlap. Compare.
Stochastic Storm: Maybe.
DJ Flamingo: Let's call this two interval compare. Overlap. Maybe we'll have a flag has overlap. We essentially define this as maybe cut.
Stochastic Storm: True.
DJ Flamingo: And if the left interval and the right interval have overlap, then if anything doesn't have overlap, I think we should, we should make this as or I think we probably don't really need this one. In the final condition, we return true. And if this one doesn't have overlap, we can return false. And then we also need to compare the wrIter. Exactly. Writer interval. And the way we compare this is we can have an additional index here. So enumerate this one. I. And if I is I plus one is still following in the index intervals. Then we compare with the next right interval. The way we compare this is we compare with the current interval and the intervals I plus one. And then we need to determine which is the next left interval. The way we determine the left interval is we compare which has the end, the larger end. If left interval one has a larger end, we don't need to change it. So we only need to change it when the red interval has a larger end.
Stochastic Storm: Okay, I'm sorry. In case you got any bugs.
DJ Flamingo: Sorry, I didn't hear.
Stochastic Storm: I'm sorry. In case you got any.
DJ Flamingo: Yeah, out of time.
Stochastic Storm: I'm sorry. If you had any background noise.
DJ Flamingo: Do I have any background noise? I don't think so.
Stochastic Storm: I am sorry. In case I am having any background noise from my side.
DJ Flamingo: Okay. There is no background noise. I can't hear you, but there is some glitches when you speak. It's not noise.
Stochastic Storm: Okay, sorry. I am able to hear you clearly in case you have any issues. No worries. You can maybe write and communicate. Yeah, you can go ahead.
DJ Flamingo: There is no. Okay. And I think this is the code based on our discussion. And by the way, thanks for discussing this with me. Do you want me to walk you through this code? Just briefly?
Stochastic Storm: Do you think this is like. Okay, yeah, let's walk through.
DJ Flamingo: Yeah, I haven't sorted the interval. I think I need to sort the intervals. I think it just sorted called intervals Lambda XX using the left part using their start. Or maybe it's this function. Anyway, I think you guard.
Stochastic Storm: Okay.
DJ Flamingo: Yes. Let me walk you through the code. After we sorted the interval, we initiate the left interval and then we loop over all the rest of the intervals. The way we loop rest of the interval. For each of the next interval we will compare with the left interval with the largest ending. And if we found it not overlap, we return false. And then we will also compare the current interval with the interval on its right. And there is some corner case because some interval may not have an interval on the right. We'll compare only if we have the interval. And the final thing we do is we will update this left interval.
Stochastic Storm: Based.
DJ Flamingo: On the ending which one has the largest end. And if all this condition pass, we will return true. If any of the comparison paradigm fail, we will return false.
Stochastic Storm: See, this is where the issue is, right? We don't want to return false just by comparing with the left.
DJ Flamingo: Yeah, sorry, I got what you mean. Yeah, I should overlap. This overlap should be the or like if both are, let's initial this true tool. And if this one. No, if either the things is good, we only return false. If both things are false. How do we do this? You know, it's. I know it's an or operation.
Stochastic Storm: The whole trouble is, because of the edge cases, the first and the last interval has to be probably handled separately and the rest of them can be easily done via an or operation.
DJ Flamingo: Yes.
Stochastic Storm: Or otherwise. If you want to maybe make some customized logic of counting somehow that everyone went through the overlap, that can be something. But overall you get the idea. And I think we are almost at the end of time. So I get your idea. We are just a bit away. Maybe you want to talk about time and space complexity.
DJ Flamingo: Yes, let me just put this one here. Anyway, you get my idea. I was talking.
Stochastic Storm: Yeah.
DJ Flamingo: Okay. The time compact fee is basically you need to sort the array. So that's n operation. And then you go through all this interval. This is just linear. So the high level complexity is on log N and the space complexity is majorly when you will store this array, you will generate a new list. So that's going to be on. And by the way, I still think my previous algorithm is correct, but I agree I'm not able to communicate that. To explain that very clear to you, I think you can compare only to the left, but you will need additional logic if they don't match, you need to change the left.
Stochastic Storm: Yeah, I agree. But you may have to do something more to make sure that eventually it did get considered. But that's all right. We can just conclude. What's your final time and space complexity?
DJ Flamingo: The final time complexity is. Let me write this down. Time complexity is O N log N. Space is. Space is O N. Because you need to sort the intervals.
Stochastic Storm: Yeah, I think space should not be. Owen. Right. You are not using any extra space. Right.
DJ Flamingo: I don't know whether when you sort this generate a new interval, it will.
Stochastic Storm: Okay. All right. We are okay with the time now, so let's stop the technical discussion part and we can share some feedback.
DJ Flamingo: Okay. Thank you so much.
Stochastic Storm: Okay, so I'll write maybe at the top. Let me know if you're able to see. Um. So, yeah, before I say anything, what do you want to say? How do you think? How are the questions? How do we do?
DJ Flamingo: Yeah, I think the first question, I work it out. The second question, I get the hall of a thing, but when I walk through example, I miss one example where you could have two group of interval, and those two group itself, they don't overlap. And when I walk through the code, probably I didn't get this all logic right. This is my problem.
Stochastic Storm: Yeah. So how did you find the questions? The quality of questions?
DJ Flamingo: How did I find which question? The quality?
Stochastic Storm: Yeah. I mean, quality or the difficulty of questions.
DJ Flamingo: I think it's medium. Seem to me. I feel this is something I need to think a little bit, but it's not something is impossible for.
Stochastic Storm: Yeah. Yeah. Makes sense. So, if I be honest, with respect to Google, questions are not hard the way you see lead code, hard questions, they will lie in the difficulty region, mostly of medium, but they'll be a bit tricky. Like, you have to think thoroughly in terms of the test cases, edge cases. That's what they'll test you more upon. In lead code, the hard are just hard because of the data structure being utilized, but it's not necessarily that. And that's the nature of Google problems. The Google problems which they will present, you may not likely get them on the platform of lead code. For example, I'm pretty sure you might have never seen this kind of problem on lead code.
DJ Flamingo: No.
Stochastic Storm: So that's how the nature of Google problems are. So before giving any feedback, I'll just give you general Google tips. First is a very general tip, because you just have 45 minutes. Keep everything else very small, have as much time as possible for your problems. Okay. So if the interview starts with an easy problem. For example, in today's case, the first problem is a very easy problem, right? Understand that this problem is being presented for setting up the scene so that some more relatively difficult problems can be presented, right? Don't waste a lot of time here. Just wrap up as quickly as possible, maybe in less than ten minutes, so that you have more time for the later one. Code quality will matter depending upon your levels, the more higher the level you are applying for, the quality of the code will also matter. That's why I was talking about left, right or start. And you have to make things more and more production ready. Also, this is one very important thing I tell with respect to Google interviews. Typically interviewer may not come with elaborate problem statements or test cases. The way lead code gives you. They expect the candidate to dig these things. You lead this part of communication, how to bring about the problem, how to clarify, how to write down the right test cases, right amount of test cases. For example, in the second case you did think well, but because you didn't think through test cases of all varieties, you couldn't get to the clarity of the algorithm. Probably if you would have got the algorithm right in the first go, you could have easily write the code also properly in the first go.
DJ Flamingo: Right? That's very important. I agree.
Stochastic Storm: So you have to find a balance between how you are communicating everything clearly, yet not consuming time saying very trivial stuff. And the general important topics I have been observing in the recent times are in the domain of graphs and their algorithms, trees, binary search. So that's just for generality. Let's just quickly walk through.
DJ Flamingo: By the way, what are the algorithms in graph like that? First search, Brad, first search, all regular.
Stochastic Storm: Ones, DFS, DFS, short paths, minimum planning trees, or let's say those kind of Data structures, union find, et cetera, disjoint.
DJ Flamingo: Thank you.
Stochastic Storm: Yeah, I think you clarified the problems very well, or even what it means for N intervals to overlap. I have always seen candidates not really understanding what N overlap would mean, and they conclude with something else, code, something else, and later clarify this. So that part was very good.
DJ Flamingo: Yeah, thank you.
Stochastic Storm: This part I really liked was that there were no gaps of Silence. You always thought out very loud. I was always clear, like in what direction you are headed. So that was pretty good. Very good. And continue on that.
DJ Flamingo: Thank you.
Stochastic Storm: Overall code quality is excellent. Maybe you can read more about Python production readability, okay for fine tuning, but otherwise it's pretty good. And speed of coding is excellent. So that's really your strength. It's good. In general, I would say your thinking ability and problem solving was also very good. You could more or less come up with the answer completely on yourself. It's just that because you didn't take the right test case yourself, you just couldn't complete your algorithm in this case.
DJ Flamingo: Right?
Stochastic Storm: Okay, so let me share thoughts from my side. What could have been better?
DJ Flamingo: Okay.
Stochastic Storm: It now this one is a trivial one. That is, it's good to suggest complexities of written code oneself without interviewer counting for it. There is one general thing that I would say. In general, an interview is being guided more by the interviewee than the interviewer. Do you get this point?
DJ Flamingo: No.
Stochastic Storm: Like interviewer will present with you with a problem.
DJ Flamingo: Yes.
Stochastic Storm: You should be clear what all you want to do. You should be clear that, okay, I should think for an approach, I should create test cases. I should write the code now. I should suggest the problem in case something optimal is possible. You are leading it. Okay, you are leading it and you are taking constant Nod. Constant? Yes. From the interviewer before proceeding. That's how you should in general carry out an interview. I see.
DJ Flamingo: So if I referee, what you said is I should suggest what to do next and I should listen. But I should listen.
Stochastic Storm: You should have a very clear list of general actions always ready whenever a problem is given, first clarify, then write necessary test case is then suggest your approach, then write the code and then suggest the complexity some set of actions you should have clearly with you and keep going ahead as the interviewer is saying yes to them, unless he wants something else, of course. Okay, so now what I will say is, the main thing that I saw you should be really working upon is writing good test cases, right? Make sure you write test cases which include edge cases thoroughly enough before thinking of possible approaches. So let's say for the first problem, three kind of test cases are sufficient, where the first interval is smaller, second is bigger, and the overlapping the exactly same case. In the second problem, also three kind of test cases would have been sufficient. But I think you didn't even write one when I suggested maybe you can take a test case and see things are working or not. That's when you wrote one and you concluded that it's correct just by that one.
DJ Flamingo: Right?
Stochastic Storm: I think that's something I need to agree. That's where the lead code platform may not help. Of course, it totally depends on your luck. Also, in case the interviewer itself has come with good enough test cases, then it's good. Otherwise, sometimes interviewer may come with some test cases and you may have to write more. So there are all cases possible. Make sure you have explored all variety possible before even thinking of the approach. Otherwise approaches remain partial.
DJ Flamingo: Okay, I agree.
Stochastic Storm: Build an approach which is thorough.
DJ Flamingo: Okay.
Stochastic Storm: And will also aid in writing code clearly. Okay.
DJ Flamingo: Yeah. When I watch people, I watch some video with people interview. I think they may not write the full test case very formally, but they will write this in just text. Do you think that's okay or do you think it's better just write?
Stochastic Storm: Yeah, that works as well. Yes.
DJ Flamingo: Okay. Thank you.
Stochastic Storm: Also then how to say if you have only considered everything, interviewer need not give any corrections.
DJ Flamingo: Okay.
Stochastic Storm: In this case, what happened? I was again and again asking, are you sure? Is it correct? Are you sure? Is it correct? And then you had to ask me, can you tell me a test case where it is not working? And then I told, see, this is how it's not working. This kind of case, if it happens, basically any kind of hints in a Google interview brings down your leveling. Basically there is risk that they may down level you.
DJ Flamingo: Right.
Stochastic Storm: And same, always try to dry run the code yourself without interviewer asking for it to make sure you haven't made any logical mistakes in the writing of the code.
DJ Flamingo: Okay.
Stochastic Storm: Interviewer should not be in general pointing out any mistakes in the code. Does that make sense?
DJ Flamingo: Yes, I got what you mean. Yeah.
Stochastic Storm: Okay. All right. So this was good. This is all the feedback that I have. In my opinion, you are doing really good in terms of your skills, in terms of your problem solving. If you also work a bit more on how to approach an interview problem, you'll be complete and we'll be able to crack anything.
DJ Flamingo: Okay, thank you so much. Do you think we can add LinkedIn after we finish this interview?
Stochastic Storm: Yeah, it gives an option in the platform to connect.
DJ Flamingo: Okay, cool.
Stochastic Storm: All right. I wish you all the best. We are good with the time also. Have a good day. Bye.
DJ Flamingo: You too. Bye. Have a good night.
We know exactly what to do and say to get the company, title, and salary you want.
Interview prep and job hunting are chaos and pain. We can help. Really.
