Quantum Wolf: Hello.
Purple Griffin: Hello.
Quantum Wolf: Hey, I'm so sorry. There was some internet issues I was not able to join earlier. Can you hear me?
Purple Griffin: Yes, yeah, yeah, no problem. Yeah.
Quantum Wolf: All right. Okay, cool. How are you doing?
Purple Griffin: Good, good. How are you?
Quantum Wolf: I'm doing good as well. Just some internet drives that I have today. That's all but yeah, doing good as well. Thank you. So have you done these interviews before mock interviews on the platform or otherwise? Any mock interviews elsewhere?
Purple Griffin: And yes, I've used this platform before. Yes.
Quantum Wolf: Gotcha. Cool. And Do you have any interviews coming up at meta? anytime soon?
Purple Griffin: Yes. You know, in a week, I have my first phone screen with Facebook or meta? Yeah.
Quantum Wolf: Gotcha. Okay, cool. All right. And do you want to tell anything about your years of experience, what level you are aiming for? Anything like that you have any of the functions?
Purple Griffin: Yeah, definitely. So I'm a software engineer, I have two years experience. And I am interviewing at Meta for I think there is a general one, which is for E3 or E4. Right? Yeah. And I was told that my first interview is going to be 45 minutes phone screen with two problems. So my goal is like, I would like to, you know, get the same experience like as close as possible from this as real as possible from this mock interview, and also get feedback from you. So I want to know where I'm standing now, how far I am, from that interview, to be successful, that interview and get any feedback, if you can then give me in order to, you know, I can help, I can become prepared for the interview. And possibly, if I'm very far away from the phone screen, I'm going to postpone it. But yeah.
Quantum Wolf: That makes sense, that's my job as well here. So I'm gonna try to keep it as realistic as possible. I've taken now more than 40 interviews for the company for Meta. So I think yeah, and these are coding all coding interviews that I'm talking about. So should able to give you a pretty realistic picture. Now, about that 45 minute round, just to kind of tell you about the structure is divided into three parts. So it's five minutes initially for introduction, followed by 35 minutes for the actual problem solving, followed by for five minutes at the end, where you can ask any questions you might have. One thing that I suggest, the start itself, especially here on this platform is really don't waste any time for introduction. So you can try to keep your introduction as short as possible. As interviewers, we do the same, especially in coding rounds, because when coding rounds, really your background, information about that you're gonna tell us does not matter. And we cannot really judge you based on that. The only only metric on which we have to judge you is just how well you perform in the coding on the problem solving basically. So so if you if you kind of save yourself a few minutes of interruption, if you just say something which lasts maybe like 30 seconds or less, you can get three to four minutes from the introduction part for problem solving. So you can end up getting close to 40 minutes for solving the problems instead of just 35. Now, another thing is that you should know about is that you you're expected to solve two problems, not one. This is so we can get more signals around you. Now, something that I do is it's so it's possible that the interviewer pivots the question, it's also possible that they don't. So this kind of depends upon how the candidate is performing and where they are and what kind of signals the interviewer is trying to extract okay. So what I tend to do is that if you have not had any major movement on the first question, I will change the question about in about 15 to 20 minutes. The reason being giving you another chance basically with the second question and not letting all the 14 minutes just go away. But but different interviewers look for you Like, there can be an interviewer who might want to just discuss the first question for a longer time with you, just to extract the signal off. If it's at a place where they feel that you will be able to crack it, then they might keep going on. So, so there can be that difference, okay? The idea will still be that you should try to solve both the questions, or get very close to solving both the questions completely, you will not be allowed to run the code, neither in the real interview nor I'm going to allow you to do that here, even though the code execution is enabled on the platform. So just something to keep in mind. Which language will you code in today?
Purple Griffin: Python
Quantum Wolf: Okay let me shift to Python. Alright, is there any other question that you have before we begin with them?
Purple Griffin: No, that's good. Before we start that about the introduction, I think that was a very good point. Very quick tip you gave me so is it like, is it okay? I just said like, Oh, I'm a software engineer with two years experience. Like what Yeah,
Quantum Wolf: Yeah. Yeah, that's usually enough. You can add another line or so. Just around if you're working on frontend back in and what kind of system it is, or what that system does and whatever you're currently working on. You can just add a little. Another small line about that. Yeah, that's
Purple Griffin: Okay. Yeah. Thank you.
Quantum Wolf: Okay. Alright, in that case, let's begin with you now. That's the first question. Can you see it pasted on?
Purple Griffin: Yes. Okay. Given the head of a singly linked list, group all the nodes with odd indices together followed by the nodes with even indices, and return the reordered list. Okay, so it's basically indexed by one, we start at one. Okay,
Quantum Wolf: Right. So just to kind of make sure that you've understood the problem correctly, how would you take a stab at telling me what would be the output? If this was the test case?
Purple Griffin: Yeah. So it's gonna be 1 5 9 3 7.
Quantum Wolf: That's correct. Yeah. That would be the answer. Yep. With that there, I think now you can think of how we can solve this.
Purple Griffin: Yeah, sure. So to clarify, my input, is the head of a linked list.
Quantum Wolf: Yeah, that's correct. Yeah.
Purple Griffin: And should I, can I create a new linked list and return it? Or should I modify the input?
Quantum Wolf: Let's discuss both the solutions that you have in mind here. What would be the difference and why one wouldn't make sense over the other or not?
Purple Griffin: Yeah. And for my linked list is a singly Linked List. It means like, if I want to just get this define it has a value, it has a value.
Quantum Wolf: Yeah.
Purple Griffin: Right.
Quantum Wolf: Yes. And just a pointer. Yeah that's all you have. Yeah. You don't need to write down this entire thing. It's okay. I think it's understood that you will have this sort of a Linked List and you can just maybe work with the method that you will have automatically. Yeah.
Purple Griffin: Yeah, and so the value here doesn't matter. So should I expect that I always get it valid? Input? Like, could I get a null?
Quantum Wolf: Yeah that's possible. It's possible you get another Linked List.
Purple Griffin: Okay. Can get null. So if I get null, it means that has nothing to do and just return it. Right? That's my edge case. And the number of nodes can be anything can be odd can be even I assume. So I don't care about the value of the nodes. So there is nothing for me to worry about that. So the very first simple solution come to my mind is I create a new linked list and return and I can create this new linked list first, going through the linked list, one loop, go through it. And just as select the odd index nodes, as I select them, I put them in my new linked list. For example, I create a new node, this is my new node, and has an X pointer in this, my first iteration, I start with here, here, oh, this is odd. So I just add it here, and I moved these two times, two steps, because I only like, one after this is gonna be five. And I do it again, another two, I get nine. And now if I'm moving it i'm out, so I know I'm done. And I reset, I do another one, another reset, this is time, I start with the second node. And I keep doing the same thing. I collect them. And I moved this pointer. Two steps. Right until I'm out of bounds. Yeah. And I returned that new node that next, which is going to be the head of the elements.
Quantum Wolf: Gotcha. Is this like a completely new linked list? Or were you like when you were connecting five afterwards are you trying to change the pointer with attach this one or is this like a new node which has value one.
Purple Griffin: So this approach is a new so every time I make a new node, that is completely new linked list, and the input is not going to be changed. So that, that allows me that, that allows me that I go through the linked list two times without any problem. So in terms of I want to think about, like how optimised it is. So in terms of time complexity is O of n, n is number of nodes in the linked list, in terms of the space complexity is also O of n. And because I'm creating a brand new linked list with the same link. So one other approach that I'm trying to get into is not creating a new linked list, and how can I actually modify the pointers. next pointer of each node and create a new one. So let's see if I want to do that. Let's let me have two pointers, one always pointed the odd nodes, the other one J. J point at the even ones. So I know that the node after the even is always odd, so I can change i point to five here. And 1 point to 5. If I do that, I lose this pointer here. I have so I need but then I can move i, my next i is going to be five, so it's fine because I did the pointer to five. Now I need to do the next one, which is J should point to three should point to seven. So, I do the same thing J always point to the next i so it means I lose this pointer and here I have 3 point to 7 And then I now move to j to J next which is going to be seven and then I do the same thing for i it means is 5 point to 9. I moved it I lose this pointer cause I move five either next is going to be nine and J again which is going to be the node after i which is null so this is going to be to the null and move J out. And now I have I need to just make these two connect to each other and nine should connect to three. So if I initially if I had a pointer here for three for the head of the even ones So I just connect these two together so this yeah, so this is going to be, I think the better approach, to not return the nodes obviously, the cases that I want to be careful is not the length of the linked list, for example yet so the thing is either of these pointers if they go out of bounds I'm done so first first if my first pointer is going to be the head, the second pointer is going to be to head at next which is I'm gonna keep this pointer as the head of either linked list for and then so I can tie them together then I started loop then loop until loop until both pointers are not null. And as I do that, I always always do one pointer to the next one start with the odd one starts with p one. p one dot next always going to p two dot next and then P one I moved the P one is going to be P one and for the next iteration for the next iteration, I do it for p two. p one and p two at each iteration. So, I just select these two each iteration one iteration p one the other iteration P two and in the end p one dot next is going to be head of the, that head that I kept in the step two and returned actually the root or the first new first node first node from the input I need to keep track of this also. So you know that yeah, so I think this is like my algorithm if it makes sense to you I can
Quantum Wolf: Yep make sense to me I think we can we can jump to coding this up yeah
Purple Griffin: Call it reorder linked list. I keep track of my root and p one is my odd. P two is p one dot next. And if here P one doesn't exist. Okay, so I know now I actually P two and while I have a flag so I know which one I'm tying together in my while loop. First I start with the r. While p one exists, and also P two exists. And if it's time to do the odd one. I do Okay, in this example, if I go again p one dot next is going to be P two dot next yeah. P one dot next is going to be P two dot next, P one is going to be P one dot next. Else is time for p two. P two dot next is gunna be P one dot next and now I moved the P two to the next one and at the end I fully forward the turn so its not a half turn anymore. So here on step four, step four, I'm gonna just tie them together okay, I forgot actually to do this that two which is saying keep the head of the even one. Even head I have it here. So what I'm gonna do is p one let me see p one may be out of bound or if I have an exact call. I have such a thing like this this is p one this is p two. p one dot next is going to be null and then this is going to be P one. So and then so one previous of the P one should go to the actual head so yeah, I want the previous node of P one all the time so let me first. None and here it's gonna be p one and then I knew that so in this example prev P one is going to be one and then I do prev P one to P two yeah. Node p one it's gonna be head its not actually this all the time and then I returned my root. So, I think this is it with me just I run one example to see if it works. So for example, if if I have only two elements p one p two and I, p one and p two, first is odd, P one dot next is going to be null P one previous going to be one I am out of the loop and then on line 68 I did prev which is one dot next to two so it's going to be one return the same one two is going to return the same if it is two elements. If its three elements p one p two so P one is going to be one next to three, P one is going to be three now. Prev is going to be one and then next element p two is going to be pointing to the next element of P one it means we're gonna have two point to null and I moved the p two. P two now it's going to be null. So now the loop, now the loop and now p one should be 1 3 2 Yeah. So this is the bug. So if the P one is out of the range, I use the prev P one. Otherwise, I use the P one. So then P one dot next is going to be to the even head, which is two so it's going to be 1 3 2. It's gonna return one, three and two. So I did two tests. One is for odd length, the other one for even length. And for the length zero, I have an early returning line 53. Right I think.
Quantum Wolf: Yeah, I think I think it looks good to me as well. Let's maybe jump to another question.
Purple Griffin: Sure. Do you want me for the time complexity or that's fine?
Quantum Wolf: I think you kind of implicitly discussed that when we were discussing this particular solution.
Purple Griffin: Yeah yeah.
Quantum Wolf: I just pasted the question number two on nine number 89.
Purple Griffin: Yes, yes. Do you know how long? How much time is left for me?
Quantum Wolf: Yeah, so we have close to 21 minutes left.
Purple Griffin: Okay. Sounds good. So, given the root of a binary tree, return an array of the largest value in each row of the tree definition of the binary tree is has a value as a left and right pointer and tree node left right pointer. Okay so it basically I have only one value in each node, left and right. And what I want to return is array of largest value in each row. Okay. So before I jump again, can I get like invalid input?
Quantum Wolf: Yes
Purple Griffin: Like, okay, so Invalid input, it means. Like, I get a get null as a root, right? That can be root. And can and the tree is, is not anything is special about like, for example, it's not a completed tree. It's a can be in any form, right?
Quantum Wolf: That's correct. Yeah.
Purple Griffin: Okay. And all the values, values of the tree are integers always. Is that correct?
Quantum Wolf: Yes, let's assume that
Purple Griffin: Values of integer values, and these integer values can be positive or negative. And it is possible that I have duplicates. So far I am not seeing any any point that I need to clear now, but I may ask later. So since since the questions tell, tell me in each row of the tree, it means in each level, right, each level, I need to get the maximum. So if I do a level order traversal of my tree, and at each level, I just calculate the maximum. So like a breadth traversal level order, I can use a queue, I initialise my queue with the root. So obviously, root is just one element when I pop from when I popped when I when I have a queue, it means that's more level. So at first I have one in my queue, in my queue is one. So I know there's a level so I calculate the maximum of the queue, oh the max is one and I make the queue empty and go for the next level. The next level while one is going to be three and two. So now it's time for me to visit three and two, the maximum is three. Okay, and then I clear out the queue, go to the next level. Put everything in the queue is going to be 5 3 9. What is the maximum one of these is nine. I clear at this later and go to the next level.
Quantum Wolf: Can you just give me a second?
Purple Griffin: Sure.
Quantum Wolf: Okay, sorry. Yeah, back.
Purple Griffin: Yeah. So. So my what I have the first idea come to my mind is do a level order traversal?
Quantum Wolf: Yeah, I think I saw I saw you're adding things to the queue. I have a question there. So you initially, so So you went from level one, then you added nodes for Level Two in the queue, like three into? My question there is that after adding those to the queue, are you kind of looping through the queue to understand what's the maximum value? Or how is the maximum value being calculated? Is it like at, once you pick out a node from the queue, at that point, you check whether it's max or not? Or is it that you're, you're kind of doing it together for all elements of a level.
Purple Griffin: So yeah, my initial thought was that I have everything in the queue. So I have to loop through the queue one time and get the maximum calculate the maximum. So that's one way. But I was actually thinking, if I want to optimise that, maybe, as I add to the queue, for the next level, I also keep track of the maximum. So I have a value like max val, in the current local at first is negative infinity. And then when I have one, I'm going through the my node is one and I want to get the next level. So one, the left node is going to be three, three is greater than and with you and the other node is two, two is not so I have three. So and then when I come to visit to visit this level. I know the maximum already is three. So I add it to the output. And then I now go to now I have to do the next level which is going to be confirmed three and two. Next Level confirm three and two against this negative infinity at first is going to be five then it's going to be three, three is not greater than five. So I keep the five then I have two, two has nine, nine is greater have nine. So, my next is going to be nine. So when I come here to the next visit time to visit my level I know the maximum already. If I do this, if I if I do this, it means I am going through each node one time using my level order traversal. So if n is number of nodes, I'm going to have O of n which is O of n time complexity. For the space complexity, I need to know this queue that I'm maintaining what is the maximum size of it. So the maximum size of the queue is when I have a sort of like a complete tree. And for example a complete tree and number of leaves in the complete tree. The number of leaves in a complete tree is let me calculate it is if I have one node is going to be one I have three nodes is going to be two. If I have another level to do, it's going to be four, right? And it's gonna be eight. So each level at make it double. So in a complete tree the space complexity is the number of. I know In a complete tree, the number of level levels is log N.
Quantum Wolf: Yeah that is true.
Purple Griffin: So each layer at the end, last level is going to be log N. Log N times two. Is that quick? So if I have that one, one is one, two is 2, third is four, four is eight. Let me see. It's it should be. I'm trying to see if it's a good way to calculate the space complexity through the number of levels. So actually, through number of nodes.
Quantum Wolf: Yeah, I think in the end, you need to figure it out in terms of N itself. So maybe try to look at it from the angle of like, you were trying to figure out how many nodes your queue will have, if it's, it was a complete rewrite of three levels, two levels, so on so forth. So if it's three levels, now you have, you know, you're gonna have four nodes in the queue. In the worst case, but how many total nodes would be there in that?
Purple Griffin: Sorry, how many total nodes in the queue?
Quantum Wolf: Yeah, if it's like a complete tree of three levels? How many total nodes are there in the queue?
Purple Griffin: So it's gonna be four.
Quantum Wolf: No, that's no, that's the issue right. And how many total nodes are there in the tree?
Purple Griffin: Oh N.
Quantum Wolf: What is N in that case? Is what I'm saying. Like you can you can try to relay
Purple Griffin: Oh, I see.
Quantum Wolf: Yeah.
Purple Griffin: Seven nodes is going to be seven nodes give me four. So it's going to be seven plus one divided by two. Does that work? So if I can generalise it as n plus one divided by two? Oh, yes. Yeah, it works actually. Yep. So space is going to be O of N plus one divided by two, which is like in terms of time complexity is O of N.
Quantum Wolf: Right.
Purple Griffin: Yeah. So yeah, that will be my approach. If you think sounds good, I can
Quantum Wolf: I think we can, you can definitely see that
Purple Griffin: Have a root of my tree and initialise the result array. And if root doesn't exist, I just return the empty array and initialise my queue as root inside and say while queue here and initialise max so far. It's gonna be root dot value. So, here, I will append the Max so far. This is a time to visit each level and so far I have it and then this and I empty the queue. So this is a temporary queue. Because I want to add all the next level in this queue. So then for each node in queue. So I do, I have to reset the max so far to negative infinity. And you said for each node, start from the left to the right, if node does not exist and see the max update the max so far and then I push it to my queue and go to the right node in the same thing return result so let me run an example one this so this example that we have at the top. So, first my root is one, so queue has one, my max so far is one, so append to the result one. Max so far now, it's become in negative infinity, and then I go to the next level left is three. So max so far is going to be three, I pushed the three to the queue and go to the right max so far is not going to be changed. Because two is less than three pushed it right it is two and then I have three, add three to the results. And four and start with three then for the next level. And three also be set to max so far. And then node dot left is going to be five, five is going to be the max so far. And node dot push, push the five to the queue and then going to be three and three is going to be, not going to change the max so far. And push the three and then going to be to two dot left. Two dot left is null so I'm gunna go to two dot right. Two dot right is nine is gonna change the max so far to nine, and then push push, push the nine to the queue. So then I come talk to the line 150 I know the max so far is nine, I pushed the nine. And then I reset the max so far infinity and I go for each node which is going to be 5 3 9. I'm going to their children, their children doesn't exist. So queue gonna be empty. I'm out of the loop I returned a 1 3 9 as output so it works for this example if I'm thinking I want to think about any other cases. If its root is null I will have a, I return the empty array and if yeah, I think I'm not saying any weird case cause problem yeah, I can have negative values is still is fine because I set my max so far to negative infinity Yeah. If you have any questions for me.
Quantum Wolf: I think I think this looks okay to me. Okay, let's let's stop the interview here. We are a little early, you still had like two minutes left. Okay, so how did you think you perform before I give you the feedback that I've written down?
Purple Griffin: I think I, I think it went well. Yeah, I'm pretty happy that I heard feedback from you for both of them. You said it's good so.
Quantum Wolf: So yeah, so let me just give you TLDR version. If this was the real interview, you will get a hire signal with a very strong confidence. So we, when we are giving out, actually submitting your review. For the interview, we have to along each of the axes, we kind of suggest, is it like a hire signal? Or is it like a no hire signal? And how confident are we about about speaking about hire? This would definitely be among the strongest interviews that I've had on, especially on this platform. I think you're among the best candidates that I've seen. Honestly, at some point, I was feeling that maybe I could have thrown a hard question at you just to maybe discover some things that, where I would have been able to help you out with, because right now, it just seems too perfect to suggest something which could be better, you kind of ticked off all the boxes that that perfect candidate would so so let's go one by one. And then we just cover these things, at least. So you get to know that all the things that you're doing, which are good and which are noticed, right? So on the angle of communication from communications perspective, you ask very good clarification questions at the start of the question. You also think about edge cases, then and there itself, that's all good. You spoke about the time and space complexity yourself for each solution that you were talking about. That's also pretty good. And you knew about them. And generally, your communication skills are among the best that I've seen you. Not only do you speak very clearly, and not only do you talk about the the way you will be doing things, you also use the common space very efficiently. You make sure that visually, you're putting out whatever you're saying in in the most clear manner for the interviewer. So I don't see any way any person would have trouble understanding what you're saying. So those are all good things. I have no gripes at all. The only thing I would suggest is, in case you feel that the question is too hard, or that you're low on time, right? Because in this case it worked out, most likely it will work out, given you're going to appear for E3 or E4. You, you will most likely not get a hard question. Okay. I'm not guaranteeing this, because it depends on the interviewer what questions they choose. But for an E3/E4 we, and especially on a phone screen round, generally, it would not be a great idea as an interviewer to throw a hard question. For an on site, perhaps it can appear, it still appears with very less probability compared to a medium level question. Right? Most likely, you'll get medium level questions, there's chances you might see the first question as being an easy level question. Also, I asked both questions which are medium level, but there are chances that you might even encounter an easy question on the, as the as your first question. Now, keeping all of that in mind. Yeah, so overall, your communication skills are great. But because you're spending a lot of time making sure that everything's understood well. Remember that if you feel that you're low on time, and it's good that you tried to check that with me as well, you can do that in the real interview, too. If you feel at any point that you're low on time, it's okay to skip on few few of those things, right? It's okay to not go out of the way to explain everything very nicely, just so that you because more than that communication, what's going to matter is that your code is correct, that it's complete. And then that you did some sort of a dry run to verify, and you've come up with a test case or two yourself and you've verified your code. So those things have higher weightage than just discussing the solution, or coming up with a solution. So a lot of people still get high confidence, hire signals, if their discussion part was not that great communication skills were not amazing. But they were able to explain that they came up with the optimal solution, just that they did not highlight it in the comment space very efficiently. Okay. So I'm saying that's the place where you can take a hit, if you feel you're low on time, okay. Otherwise, this is perfect. Try to keep it like this. That's all you need to do. Our technical knowledge side. Again, you knew about linked list, you knew about breadth first search you knew about queue, how you implement that with a queue you could answer about time and space complexity for both questions. In the second question, there was a tiny hint that I had to give you to think about space complexities the right way. But you were able to, you were going in the right direction. And these kind of tiny hints do not really, will ever make you, like, make it red signal for hire. So the entire idea behind interviews is that we are trying to evaluate if we, in fact, if we give you a hint, and if you can catch on to it, that's a positive signal. That's not a negative thing. If there are like too many hints, maybe like 10, 15 hints that is given in the round, that's where it becomes a problem, right? Because we are the ones who are leading the discussion. In this case, you were leading the discussion almost entirely. So it was all good, no major issues. problem solving skills. So again, one of the I had literally written this was absolutely perfect, because you lead the discussion, it was more like a presentation, less of a back and forth discussion. That's the best way of coding round could be when you, you have figured everything out, you're just explaining how it would work. To me, or to the interviewer. You talked about the brute force solution, you discussed its complexities, you talked about optimal solution and discussed its complexity, you kind of showcase how that will work in comment sections. And then you asked whether this looks good, and you can jump to coding. And that's the perfect way, then writing down the code. So for both the questions you did well, on that front, you were able to come up with optimal solutions yourself. I did not have to give you any hints or guide you in any way. So all of that was amazing. coding skill side code looks to be clean. For both the questions, I have no issues. The only small thing that could could have been improved in the first question is that you just the variable names. So one is that instead of p one, P two, you could have chosen slightly more semantically meaningful names, maybe like, even pointer odd pointer, because that's what they were representing something along those lines would have made slightly more sense. That's the only thing. In the second question, I don't see that issue reappearing. So, I it's not that you're gonna do that always. But it's just something small issue that I could point out. You did cover edge cases in both the questions. You were able to fix your code, there was a small logical bug which you fixed yourself in the first question, so I have no issues, they're both code seems to be pretty good, they will work. And another good thing was that your dry run quality is quite good as well, the way you encode the question, how in the first question, you adapted the way of writing down the difference in your linked list, one after another, which is good. And in the second question, you took the approach of just describing the value of a particular variable as an inline comment. Both are good, dry run approaches, you can use either of them and it's good that you use the one which was better for a particular question at the better at the right place. So again, no issues there. Keep doing like that. What else? Yeah, one more thing is you do tend to speak out when you're coding. So you're kind of explaining the entire code as you're writing it down, which also helps keep the interviewer engaged. So keep doing that. Because that way, an interviewer is not going to have questions around a particular piece of code or particular part of the code later on. And you're avoiding a back and forth discussion, which helps save time and give you more time to basically solve the question and do everything. So this was one of the best interviews that I've ever had, honestly. And the only thing is that as an interviewer, especially a mock interview, there's not much improvement feedback that I can really give if you perform this well. So that's the only thing. How it is like you, you definitely seem ready. You could have interview tomorrow. For all intents and purposes, and you'll still do well I think yeah.
Purple Griffin: I'm glad. I'm glad to hear it. Thank you very much for all good feedback. One, one last question I have is what do you suggest for practising these questions? I've been using leetcode, do you think? Should I go through like, all the Facebook tag leetcode problems? Or do you have any other platforms you suggest me to use?
Quantum Wolf: Yes. So I think leetcode is the best one 90% of the questions that get asked are already available on leetcode. There might be like five to 10% questions that maybe are not there. But then they show up there after, soon enough, no matter whichever new questions we create, they often end up on the leetcode platform within a couple of months. So most of the questions are covered, you should definitely target all the Facebook tag questions on leetcode buy an account if you don't have it, and sort them in the order of frequency. The reason I say that is usually interviews have a small pool of questions, like every interviewer is gonna ask maybe same five or six questions to almost all candidates that they interview. They that's the usual case, and there are far too many interviewers in the in at meta. So what happens due to that is that if some questions are being asked too many times, that's gonna keep continue happening, because maybe a large chunk of the interviewer population, ask those questions. And that's not going to change anytime soon, either. So because of that, it would be good to follow the frequency order that leetcode provides as well and start solving from top to bottom. Our usual suggestion that I give is that I've seen candidates who are able to do well on these rounds have usually solved close to 100 to 150 questions before phone screen, and maybe around 200 questions by the time they get there on site rounds. So if you're able to get to that number, that would be amazing. And, but I I feel that you're ready, at least with the questions that I threw at you, you seem to be quite ready. But yeah, that's the that's the advice I can guess. Yeah.
Purple Griffin: Okay. Yeah, yeah. And so you said, is that possible, the probability that I get hard questions, right, not that high.
Quantum Wolf: Not that high. It's just that even if you get a hard question, remember that, most likely, it's not going to be the first question. Like, generally, a hard question will be thrown out with an easy question. And the easy question will be the first one, it's not like the interviews gonna give you the first question as the hard question. That's very unlikely, like, the reason for that is, it's kind of against the guidelines that we are given. So technically, an interviewer could do that. But it will not really be following the kind of guidelines or the kind of suggestions that have been given to Interviewer When they get trained for taking interviews, what we are told is that you keep the first questions complexity lower than the second one, generally all keep them at an equal level, if you feel both can be solved around in the same time. So if you get a hard question, that's going to be second question. And if you get a hard question, do remember that if for a phone screen to clear the phone screen, it's not always necessarily that you are able to solve the two questions as completely as you did here. Even if you get very close to sake, just completing the code of second question, you have not done the dry run and not fix the code, but you have gone to the point where we have discussed optimal solution and you have maybe coded like 50 60 70% of the code and the time runs out even then you you will, you will get a hire signal from a phone screen. Okay, so you will get a pass to go on for the on site in our on site. Because the reason is that in such a case, it's like a borderline right, you are not able to solve two questions, but at the same time, we do have enough signals that you can solve these questions, you can come up with a case and if you had another five minutes, you might have solved the question completely. So if we know that we know that all that is needed, perhaps more practice so that you can be slightly faster. And you can definitely do that. Before scheduling your own. sight. So if you're in doubt, you'll still get a higher signal in a phone screen. But an on site ground, if you're if you're in doubt, you're not going to get hired. So that's the difference in phone screen. If you are in doubt, you'll get benefit of doubt in on site. If you're in doubt, you're not gonna get the benefit.
Purple Griffin: Makes sense. Yeah. One last question is, is that common that the first question, which is like, whatever it is, is easy or medium? And the second question is, like, built on top of the first like, in the same area, they assess me?
Quantum Wolf: Yeah, so that's a good question. Again, very, I know people who ask questions that way, wherein the second question builds on top of the first question. And then I know interviewers who will, by design not do that I am one of those people. There are reasons behind both. The first one kind of the thinking behind the first one is that it's, it feels more natural, more smooth of a transition, that you're just adding more complexity to the first question, you know, just just looks more looks and sounds and feels more sophisticated and natural, that you're kind of discussing the same problem, just adding more complexity to it. So that's why a lot of interviews do that. I think there are more interviews, however, who will not do that? And who will basically give you two different questions. The reason behind that, is that they are trying to judge, they're trying to get more signals from you. Because what if you just know how to solve linkless questions, but you don't know anything else? Or if you are on the other way around, maybe you and maybe one of the, like, the question that we gave you, maybe, maybe linklist is your weak point. So you're not able to do well on that. But as soon as the three word question from a different area, you were able to nail that immediately, right? So asking two different questions gives us that advantage that we can get signals on how diverse of a knowledge do you process? Or maybe if, you know, just because of bad luck, we asked a question from the area that was not your strength. So in that case, maybe you didn't perform well in first question. But then you showcase a lot of positive things in the second one, that gives us the positive things that we need. So an entire idea at the end is that can we get enough positive signals to realise that, hey, this guy would be able to work at Meta? And we'd be happy to have them here. Right. And if he asked two different questions, there are two independent opportunities that you get to prove that. So that's why that's why me and a bunch of other interviewers will choose that instead of the approach where the second question is just added complexity on top of the first question.
Purple Griffin: Yeah makes sense yeah, thank you very much for your time. Yeah.
Quantum Wolf: All right, man all the very best. I will submit whatever I just spoke off in the written form as well so you can have a look but I think I think you don't need to have a look you you just nailed this. I wish you all the best. I hope to see you at Meta down the road.
Purple Griffin: Thank you. Thank you very much. Really appreciate that.
Quantum Wolf: Okay, bye bye.
Purple Griffin: Have a good day.
Quantum Wolf: You too.
Purple Griffin: Bye.