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

Python Interview with a Meta engineer

Watch someone solve the odd even linked list problem in an interview with a Meta engineer and see the feedback their interviewer left them. Explore this problem and others in our library of interview replays.

Interview Summary

Problem type

Odd Even Linked List

Interview question

1) 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. The first node is considered odd, and the second node is even, and so on. Note that the relative order inside both the even and odd groups should remain as it was in the input. 2) Given the `root` of a binary tree, determine if it is a valid binary search tree (BST). 3 / \ 1 5 / \ 2 7

Interview Feedback

Feedback about Crimson Turtle (the interviewee)

Advance this person to the next round?

Yes

How were their technical skills?

3/4

How was their problem solving ability?

3/4

What about their communication ability?

3/4

Overall easily clears screening round. For onsite, unless you get benefit of doubt it could be a no-hire. BTW -- THERE IS PROBABLY A WAY TO BOOK AN INTERVIEW WITH ME. IF YOU GO TO "SHOWCASE" and FIND ONE OF MY PREVIOUS INTERVIEWS THERE, IT MAY ALLOW YOU TO BOOK AN INTERVIEW WITH ME. Otherwise, you can always mail "support@interviewing.io" or book dedicated coaching sessions with me. - My Dedicated Coaching sessions link: https://start.interviewing.io/dashboard/interviewee/dedicated-coaching?mentor=61b903da92b16b0035d40b61 Detailed feedback below :) All the best! Hope you get through this time with Meta! ## Communication ===================== Perf: Strong q1: Strong (+) created a testcase to discuss (+) didn't jump to coding (+) language is clear (+) used comment space to explain the solution q2: (+) Similar as q1 ## Problem solving skills ===================== Overall: Solid q1 Perf: Strong (+) figured out acceptable solution wihthout any hints (+) knows about linked lists (+) shared time & space complexity himself proactively (+) quick at finding the solution q2 Perf: Solid (+) knew about BST definition (-) assuming it's integers. always worth asking if its integrs or float (+) had to prod but was able to talk about time & space complexity correctly ## Coding skills ===================== Overall: Solid q1 Perf : Moderate/Solid (=) coding speed is avg (+) edge cases taken care of (+) readability is good -- good var names, comments in code, method name is appropriate (+) was able to correct logical bug in his code after the prodding and fixed the code without needing hint for actual solution (-) logical bug : assumed head.next is at same place still...which it isn't. tried minor nudges but didn't work. had to spoonfeed issue again. q2 Perf : Solid/Strong (+) took care of edge cases (+) code readability is good generally (+) code is correct (=) avg coding speed ## Verification skills ======================= Overall : Moderate q1 Perf : Moderate (+) good line by line verification (-) unable to catch his own mistakes and had to point it out two times...and have to exactly pin point the mistakes (+) created test cases q2 Perf : Moderate (-) not a proper line by line verification --- antipattern, don't do this. had to prod you for this. and then you processed 5 before processing 2 or 7 which isn't line by line truly. act as an interpreter, don't use your brain during verification. (+) good way of visualising the states in comment. (-/+) no new test cases created proactively, had to prod TC to do so. Created new test cases. (=) no mistakes to correct

Feedback about Quantum Wolf (the interviewer)

Would you want to work with this person?

Yes

How excited would you be to work with them?

4/4

How good were the questions?

4/4

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

4/4

Interview Transcript

Quantum Wolf: All right, cool. Awesome. So you've done these before. I'm guessing you might have a meta interview coming up. Do you want to give any details about that? Like, is this a screening round? Is this an on-site round? I'll try to judge accordingly because the. There is a difference in hiring bar for both.

Crimson Turtle: Sure, sure, sure. Yeah, so basically like last year around, like, yeah, last year, maybe around like September, I did interviews and then it was like a closeness. So the recruiter actually reached out to me and then she's like, yeah, so like to interview. So I'm in the first interview coming up on the 24th of February.

Quantum Wolf: Gotcha. Gotcha.

Crimson Turtle: Yeah, yeah, yeah.

Quantum Wolf: All right, I understood. Okay, cool. So, meta coding interviews, basically you're going. To get 35 to 37 minutes. I'm going to ask you two questions.

Crimson Turtle: And.

Quantum Wolf: Essentially you're not allowed to run your code, you are allowed to do a dry run by creating your own test cases. Okay, that's about it. I will spend about 21 minutes after the interview giving you all kinds of feedback and because you're familiar with the platform, you know that the You can obviously listen back to it later on. I will submit every piece of feedback I'll give you in the written format as well, so you don't need to necessarily write things down. But that's on you. All right, let's begin. Which language would you like to code in?

Crimson Turtle: Python.

Quantum Wolf: All right, that's good. Okay, then let me give you your first question. Are you familiar with LinkList?

Crimson Turtle: Yes.

Quantum Wolf: All right, cool. That's your first question. Have a read. Let me know if there's anything that's unclear. Happy to elaborate further.

Crimson Turtle: Okay. So given the head of a singly linked list, So singly linked means there's one connection from the previous node to the next node. Group nodes, odd indices, followed nodes, even indices, return reordered lists. OK, so we have a singly linked list. We want nodes, odd indices first, all of them first, and then nodes, even indices. after all of the odd indices, and then we are going to return reordered lists. So we still want a linked list, right? At the end?

Quantum Wolf: Yep.

Crimson Turtle: Okay, so want linked list, okay. So first node considered odd with, I guess, with a value of one. Second node is even. Relative order, even odd groups for main as an input. Got it, yeah. We have a linked list with nodes like 12345, and we want all of the odd ones first. So 1356, 2, and then 4. We want this one.

Quantum Wolf: Yep.

Crimson Turtle: Cool. So since the first node is always odd, we can just return the same header. OK. Yeah, so how would we do this? So let's see. So one has to be connected to 3 and then 3 has to be connected to 5 and then 5 has to be connected to 2 and then 2 has to be connected to 4. Okay, so I think essentially, yeah, so I think we can do this by first having a pointer for the even and the odd. that we haven't added. For example, the odd will be here and the even will be here. Then we'll connect all the odds first. Odd.Next would be odd.Next.Next. It would be this. Then this would be canceled. Then odd.Next.Next is two steps up. Again, it's here. And then since odd.next is none, we must have finished going through all the odds. And then so the odd.next is now going to point to our even pointer, so 5 times 2. And then we check, do we still have even nodes to add? If the next.next and the next exists, then yes we do. So the 2 gets pointed to the 4. Then we say, hey, do we have any more even pointers? Even.next is existing, but even.next does not, so we must be finished. Just do that and then we can return the same head. Yeah.

Quantum Wolf: What would be the... Yes, sorry, go on.

Crimson Turtle: Oh, sorry. Yeah, so the time complexity in this case would be O of n. since we just iterate each of the nodes once and the space in this case would be constant, so we're not using anything.

Quantum Wolf: Okay, sounds good. I think that sounds good to me. Let's see the code for this. And you can assume the usual, so you can assume that you have, let's say, a list node class, so that's what your head object is like and. It can have the usual value and the next pointers. OK, those attributes are available, so you don't need to record up the class structure.

Crimson Turtle: Got it, got it. So define my function, so reorder. Which. Takes in the head. So first we're going to define our left pointers. So left is qual to head, and then we're going to have the right is qual to head.next. We also have the edge case where we just have a single node. So if head.next is none, then we can just return the head as we have finished. We have the head and we have the head.next. First wire left odds, Odd and then even. So why are the odds? What is the condition for wiring the odds? If odd.next exists and odd.next exists, odd.next is the next even element. If odd.next.next is the subsequent odd element. If this exists, While this exists, we want to continue, so both have to be true. Let's wire it, so odd.next is qual to odd.next.next, and then we move the odd.next, odd2, next is qual to odd.next.next, and then odd. So one gets pointed to three quals all.next. Let me just move it forward. Okay. Yeah, so when we finish this, one gets wired to three. It exists, so we get wired to five. The next does not exist, so we finish. Okay, so now we have to wire the evens. I said while even.next exists and even.next.next exists. So. Is qual to the first even. So the first even would just be at e. Yeah, so we have all the odds wired up and then we have the last odd wired to the first even. And then now we're going to wire all the evens together until the end. So this should be just the same logic. So e.next is qual to e.next.next and then e is qual to e.next and then we return head. So this should be the general structure. I can also trace examples from now on.

Quantum Wolf: Yeah, let's do that.

Crimson Turtle: Okay, so I will trace the same example. So here, it's not the base case where we just have a single node. So we have an odd starting at the head and then even is head.next. So let's start with the odd. Odd.next is existing and the second one also existing. So odd.next is qual to, One, two, three. And then move odd to this one. And then keep going. So odd.next exists and the second one exists. So three gets wired to five. Then odd goes here and then odd.next is false now. So we exit the loop and odd.next is qual to two. When you wire the evens, so e.next exists and the second one exists. Let's move that forward to positions. And then, yep.

Quantum Wolf: How is e.next? What should be the value of e.next.next here? Is it for?

Crimson Turtle: Still in this one, right?

Quantum Wolf: Yeah, the operation that you just said. Yeah, why is it four?

Crimson Turtle: So we have the E here. So E.Next and E.Next.Next exists.

Quantum Wolf: But what does three pointing to now? Did your first loop not change things?

Crimson Turtle: Oh, yes. So three is now pointing to five. Yeah, so. Right. So one is pointing to three, three is pointing to five. oh, that makes sense. So. So actually, I think we have to starting with the odd and the even. So basically we have to move the even first two positions and wire it. Uh. Let's see here. Yeah, so in this case, I think it's not working because we're doing it one at a time. We should actually be moving them together. So for example, if we're starting with this, odds should be going to 3, and then even should be going to 4, and then we move the odds up. So 3 should be now pointing to 5 and then keep going kind of like weaving and then we should basically just splice them together at the end. So I think I can implement that. So first we move the O.

Quantum Wolf: Let's see here.

Crimson Turtle: O is qual to next dot next. That goes here. That's the 1 gets pointed to 3 and then E goes to 4. So 2 gets pointed to 4. And then o goes next.next, so it gets pointed to five and then e gets pointed to end. And then we can get the end of the odd, which is five and pointed to the first one, which is thought, I had.next yet, so I think that should be fine. So what is the condition here? We want to keep wiring the evens. While there is an even and then they're going to keep wiring the odd as we have an odd. And then we're going to, okay, keep continuing. But let's see here. Yeah, and I think we can use the odd as the parent condition since it's always going to come ahead of the even one. So I think we can get rid of this. And then we can say odd.next goes to odd.next.next and move on up. And then even.next.next is qual to this and then move the even up. And then since odd.next.next exists, move the odd. And then the even, it's also moved up. Yeah, and then so we have to connect the last odd node to the even node. So the last odd node is just going to be at O and next is qual to the first even node, which is head.next. Yeah, I think this should be handling that edge case there.

Quantum Wolf: You want to do a driver?

Crimson Turtle: Sure, yeah. So, okay. So O goes to head, even goes to head.next. So while O.next exists, so the two one-up exists, so one gets pointed to three. And. Then odd moves up here. And then even.next.next also gets moved up. So even goes to here and we have two going to two going to four. We have 2.24 and then so the second one exists so this three gets pointed to five. Odd goes to five. And then even.next goes to null so we get none and then even goes to none. So at this point, we have this, so 135, and so we can say the current position of the odd, which is at the last, gets pointed to the first even, which is set. Yep, so head is at the one. So we want to point the final value of odd, to the first even, which is head on next, so which is two. So five gets pointed to two and we should have this.

Quantum Wolf: Okay. Do you want to do any other test cases?

Crimson Turtle: Yeah, so if we just have a single node, that's just a base case. So if we just have one head on next would be none and then we can just simply return this and we would be finished.

Quantum Wolf: Anything else that comes to mind?

Crimson Turtle: Yeah, so I'll just do, let's see. So right now we have an odd number of nodes, so another one would be even. So for example, if we have 1, 2, 3, 4, so we should be odd. Odd and even. So second one up from odd exists. So in this case, one goes to three and odd moves up and then even moves up. So two goes to four. It goes here and odd.second, second does not exist. So we would exit. And so odd.next is qual to Aod.next is qual to head.next, which is two in this case, which is already linked to four. This should be fine. We have the odd elements first and then we have the even ones.

Quantum Wolf: How is your head.next not changing?

Crimson Turtle: Oh yes, the headless next should be now RT3. Yeah, so it just seems that we need to save the head of the even ones, which is just, we can just say even head, is qual to head.next, and we can just save that node here. And then we can wire the all the next two.

Quantum Wolf: Even.

Crimson Turtle: Yeah, just like that.

Quantum Wolf: Okay, I think let's move on to the second question.

Crimson Turtle: Do you mind if I just go to the washing very quick?

Quantum Wolf: Sure, sure, take it that. Thanks.

Crimson Turtle: Right. Okay, thank you.

Quantum Wolf: Yeah, all right. So should I move to the next question?

Crimson Turtle: Yep.

Quantum Wolf: All right, cool. Second question is around binary trees. Again, have a look. And just so that it's everybody easy, and let me just draw one of the binary trees for you.

Crimson Turtle: Sure, sure. There you go. Okay. Yeah. So. For this problem, I think it's best to first define what a binary search tree is. So, ST is so for every single node, it's left child should have a value that's strictly less and then and the right child should have a value that's strictly greater. And this should be true recursively for every single node. So for five, the value should be smaller than five, but of course greater than three. And then for seven, it should be greater than five strictly. So essentially the problem asks us to validate if it's BST. So we need to ensure that this condition holds for every single node recursively. That's the problem. So essentially what we need to do is every time we go down a node, we need to define the valid space of numbers that's allowed according to the definition of BST. So for three, we allow the elements everything less than three. So we can say have the range going into the left child as negative infinity to node minus 1 going into this one. And if it's in that range, yes it is because the upper bound is 2, it's valid. So it returns true for the left child. We go to the right child. That's looking for elements 1, 3 plus 1, which is 4 all the way to infinity. And that again fits the condition. so 4 to infinity going down to the left child. Now it should be less than 5, so it should be 2 to 5, 2 to 4. And that's, again, that's valid. And then going into the 5, the lower bound now is 5, so it should be 6 and up. So this is also valid. So we can solve it in this fashion. Yeah.

Quantum Wolf: OK, what would be the answer for the given tree?

Crimson Turtle: So the given tree would be given tree would be false because the lower bound here is 3 and then the upper bound is 5, so this node would make it fail. Otherwise, if it was like this, it would be fine.

Quantum Wolf: OK, sounds good. Let's see the code for this. By the way, so what kind of traversal would you be doing for this?

Crimson Turtle: Yeah, so I would be doing a DFS for this one.

Quantum Wolf: Okay, and what's the time and space complexity here?

Crimson Turtle: Yeah, so every node is being visited once, so the time complexity is O(n), and then the space in this case would be, in the worst case, it would be O(n), If we just have a single, like a linked list sort of structure, then it'll be O of n. But if it's kind of balanced, like the one we see here, then it would be logarithmic. Or the stack docs, yeah.

Quantum Wolf: Yeah, let's see the code.

Crimson Turtle: Okay. Stack docs. So let's see. So this is the outer problem. We're going to define a helper function which takes in a node and it has a left and a right. We'll just say low and high. So if not node, then we can return true since we expect that a single node is a valid BST. And then if in the recursive case, so check if node value is in between low and high. So if node.val is though in this case we're going to be doing it inclusive. So if the node value is inclusive of the two range, then we can return.

Quantum Wolf: True.

Crimson Turtle: Okay, so we have the answer for this node and then we can. See. So if this node for this node. If. So node is in range and. Also. We need the answer from the children. So helper.node.left but when we go into the node.left, the low is the same and then the high should be node.val minus 1. And then we have another helper function called to the right child. So node.right. And then for node.write, every value should be strictly greater. So the lower balance should be node.val plus 1. And then the upper balance should just be the same. So I. Okay, and then we get the answer for left and the right. And then from this one, we can. Return. So if the current value is valid and the children are valid, then we can return true. So for example, in the case of two, both of the children will be null. And then two itself, if it is valid, then we can return true and false if not. And then for seven, both of them will be true and this value is in range, it can return true. And then Yeah, so we can check between the children and the node itself. So let's see. So. We can return left and right and, and, so we can do this. Okay, and then now we call the helper function, which is called on the head. And then for the first value, anything goes. So we can say inf as the lower value and then the float of inf as the positive value. So going into the three node here, we have all the space available. So the first node is going to be in range and then we call it on the children to get the left and right. And if those are valid and the node value itself is in range, you can return true. So we have the answer here. Yeah, so this should be good.

Quantum Wolf: Okay, can we do Word Drive and some tests here?

Crimson Turtle: Sure, sure. Yeah, so I'm just gonna do the test case at the bottom. Okay. So our state variables are node to indicate the current node that we're traversing, and then we also have a state variable low and high. So I think in this case, I'll just list the state variables beside each of the nodes in the tree. So the three, which is the head, is being called on negative infinity, And then, so it's going to be, so the three node here is going to be in range, so the ends here will be true. And then we call the left. So the left is being called on the same negative end and the node.val minus 1, which is going to be 2. So again, this one is in range and then we're going to call the left child. So the left child is going to be called on, no dot left is being called on the same low and no dot dot minus one, which is going to be So -inf and node.val-1 is 0, so in this case 2 would be false. And then the right child would be the node.val+1 which is going to be 2 and then the high is going to be. 1. Oh, yeah, yeah, I think the spacing kind of threw me off. So yeah, so one would be in range. So again.

Quantum Wolf: Yeah, five, maybe let's write it down. It might be easier to write it. Down as you were writing and you can just create more space between them. Or you can just write down the. States for each of them below it.

Crimson Turtle: Either way, sure, sure, sure, sure, sure. Yeah, so 3 is -inf to inf, so and is qual to true. And then left, right, so left is 1, so the bound for that is going to be -inf. And then the high bound is going to be 2. So and is qual to true. since the value is 1, it has no children, so both of the left and right are true, so 1 is going to return true. Now let's go to node 5. Node 5 is a right, so it's going to be called node.val as a lower bound, which is 4, node plus 1 as a lower bound, and then the high would just be same, so it's inf. Is 5 inbound? Yes, it is. So AND is going to be true. Now let's go to the left child. It's going to be 2. The value for that is the left child, so it's the low, which is 4. And then the upper bound is going to be node minus 1, which is also going to be 4. So AND is qual to false. And then we go back up to the 5, and then we go to the 7, which is the right child. So the right child is 7. So node.val + 1. So in this case, it's 6. And then the high for node 5 was infinity. So for the node 7, the value 7 is in range, so it's true. because it's in between 6 and infinity. It has no children, so 7 is going to return true. So for the 5 here, the left is going to be false, the right is going to be true, and since we're returning left and right and and, it's going to return false. And then for the three node here, the left is going to be true, As we figured out in node number one, that the right is going to be false. And since for this one returning and and left and right, we're going to return false. So this ultimately returns enter false.

Quantum Wolf: Got it. Do you want to try any other test cases?

Crimson Turtle: Yeah, so we can try the case where we just have a single node. So that's going to return true. Let's see here. So I think some good test cases to try will be if you only have a skewed binary tree. So if we have something like this. So, K-SOR for example, the answer is true, so something like this. And we skew it a little bit. So, for example, 3. So, left is qual to minus infinity, infinity, so and is qual to true. And then the left, is none, so it's going to be true. And the right is going to be five, so let's go into the five node. So the five is the right child, so we go node.val plus one as the lower bound, which is four, and then the upper bound is infinity. So the five is in bounds, so we say ands is qual to true, and then the left is true because there's nothing there, and then the right is going to be node number seven, So when we go into the right child, the lower bound is 1 plus the parent node. So in this case, it will be 6. And then the upper bound remains the same. So in this case, it will still be infinity. So again, 7 is valid. The left and right is true since it has no children. So this guy returns true. since everything is true and the five element seven is true and then the left is none so it's also returning true and then the three node also ultimately returns true because everything the ends yeah so it seems good. Yeah.

Quantum Wolf: All right. All right, let's stop here. Before I jump to the feedback, how did you think you performed today?

Crimson Turtle: I think for the linked list, I think I was focusing too much on wiring the pointers that I forgot. That. Essentially that the heads would have been rewired. And then if I zoomed out a little bit and saw that, I would have seen that you would need to traverse them together, so without messing up the traversal. But I think at the end, I did get it, so yeah. All right.

Quantum Wolf: I think overall this would clear both screening and like this will easily clear screening for an onside. I think there's a little bit of a doubt because of verification skills probably not meeting the hiring bar. Okay. But for technical training round, I think it easily clears things. The reason is I think there are. A few places where you're not being super proactive and I have to nudge you and when I nudge you or when I ask you when I prod you, At that point, you're able to answer the questions. So I'm going to go into more details. First of all, do you know that. There are four axes on which. Meta interviewers judge your coding performance? Is that something that you're aware of?

Crimson Turtle: Yeah, I think I heard of it. I'll just write it down and note it though in the future.

Quantum Wolf: Okay, sure. Let me specify how things go. There's communication access. Let me just put this in comments. There's problem solving skills, there's coding and there's verification. Now what's happening is within each access, you're being judged for each question. So for example, first I'm trying to see your performance in first question and second question. The reason Meta is asking two questions is solely so that In case a signal was missing in first question, they can get the signal in second question. Also, if something was weak in first question, second question serves as a way to know is that a pattern with you or was that a one-off case? So if it was a one-off case, you can kind of forget you. Now, the rating scale also just mentioning this is At a scale of five, but instead of 1-2-3-4-5, it's these terms. So you're being rated insufficient, moderate. And just before I'm going to jump into feedback, one more thing is the hiring bar, which is in screening. What you have to do is you have to be moderate or higher on verification. or communication and moderate or higher on problem solving and coding. Okay, but for on-site coding grounds, you have to be solid or higher on each axis.

Crimson Turtle: Right, right.

Quantum Wolf: Simple as that.

Crimson Turtle: Okay.

Quantum Wolf: And what's happening is within each axis, let's say I'm giving you rating for each question that gets averaged out for your overall access rating.

Crimson Turtle: Right.

Quantum Wolf: So access might be in this case, it could be solid or strong depending upon where the interviewer is feeling you lie more towards.

Crimson Turtle: Right. Right, right, right.

Quantum Wolf: Hey, can I hear you?

Crimson Turtle: Yeah, yeah, yeah.

Quantum Wolf: Sorry, I lost you there. Maybe some internet issue. Okay, so how did you do, right? So in communication, A couple of good things. One is you like in the first question, I intentionally did not give you a test case.

Crimson Turtle: Okay. Right.

Quantum Wolf: It would happen and it's important to understand, do you create a test case to discuss the solution?

Crimson Turtle: Right.

Quantum Wolf: It's good communication skills to do that because it's always better to create a test case. You did that so that was good. You did not jump to writing the code without discussing the solution, getting a nod from the interviewer. So that's good as well. the language is easy to understand, pretty clear, so no problems there either. And you were in the common space to explain the solution. In communication, I've actually given you strong for both, right? In both cases it was pretty good, right? So this is almost as good as you can get. The reason I said this is as good as you can get is exceptional is a very, very rare performance signal, right? Exceptional happens when a candidate comes in and they're able to solve both questions, suggest the rare hard approaches, even write those down and finish everything up within 15-20 minutes. Sometimes interviewers are learning a new technique or something new about the question and something beyond what they even expect. Don't go for that. You want to aim for getting stronger on each axis ID. when you're preparing, right? So in the worst case also you will get a solid and you'll be able to clear the ironing bar, okay, even for on-site. So communication is already there, right? There's nothing wrong here, right? When we go into problem solving skills, so problem solving skills, what I've overall given you a solid and the reason is let's go to question one, right? Question one, you figure out an acceptable solution without any hints. So that was good. You knew about linkless, you were able to share time and space complexity yourself proactively. I did not ask them. So that gives you again a good point. And then you were quick at finding the solution. So here it was a strong performance. Okay. Everything was good. I did not have to interfere. I did not have to nudge you. So that's like strong signal is often given when it's a very smooth presentation.

Crimson Turtle: Right.

Quantum Wolf: And emphasis on the word presentation. Presentations are often one way, right, where the other person does not have to speak much. So it feels more like that. That's when you get strong, right, that you're covering all the bases without me having to nudge you for anything. Okay, so this happened in question one did not happen in second question. Second question, I've given you a solid, right? The reason is, so you were able to, first of all, the good thing is you were able to discuss what a binary search tree is, so you knew the definition. that's good. Now, a couple of things that weren't great is one time and space complexity. I had to ask you about it. So if I would not have asked you, you were kind of wanting to jump to writing the code. The other thing is you.

Crimson Turtle: You.

Quantum Wolf: This is a very minor thing, but want to mention it. You assumed it's integers. Hey, can you hear me?

Crimson Turtle: Yeah, yeah.

Quantum Wolf: I'm so sorry. I'm facing some weird disconnects today. So I was just saying that for. Problems on second question. One thing was that you, I had to ask you about time and space complexity. So it's not as smooth a presentation anymore because it's a back and forth happening. The other thing was you assumed that it's going to be integers. You did not ask me. If you would have asked me, and I would have clarified it's indeed just then it's okay. If I would have said that it could be floated, it could be doubled, right? In that case, you know, some parts of your logic would also change, by the way, you're doing a plus one and minus one. Instead of that, you might have done just a less than or greater than in your condition, right? So, so I think that those things I would expect again to get a strong signal, you have to be great, right? You have to do all the things correctly, right? And you can't miss out on these minor things, but you still do get a solid because everything else was fine. Even if you required a minor nudge here or there, again, emphasis on minor, then it's fine. You're able to solve the question. You get a solid, right? As soon as it's a major hint or something like I'm, I have to really point out what's the issue, that's when it kind of goes into the moderate territory from solid. Okay, so that's usually the difference between modern and solid. So here overall, strong and solid. There's a chance that somebody kind of pushes you down. So worst case you get solid. Best case on a day where interviewer is very happy with you, they might give you a strong also. Okay. Coding skills. Coding skills. First question. You took care of edge cases. Readability is pretty good in your code. You know, good variable names, comments in the code, method name is appropriate, all of that is great. you could go even better by the way, you could think about doing type hinting and stuff but it's okay if you don't do it, you can still get a solid or a strong signal without it also. Now. The reasons and coding speed is also something that is just on that front you are average, you're not better than average at this point, okay? You don't get a positive point, you don't get a negative point either. Now, there were two logical bugs in your code. One was that you were trying to do both odd and even separately, which would not have worked. And unfortunately, when you did your own dry run, you did not figure that piece out. I had to tell you how well you're even doing this. So that's one thing. the other, there was another logical bug, which was the head.next bit. Now, after the first thing, the first bug, I've pointed it out, but you corrected it yourself. You figured out the solution for it yourself. So, I wasn't hinting towards going solid for this access, coding access. But then there's a repeated mistake that happened, right, with head.next also. When I asked you specifically, hey, can you do more dry runs? There is a reason why interviewer is trying to do that, right? Maybe there is something else you want to catch, right? But then you did not catch that and I had to again point out specifically that how is your head.next, where is your head.next, what is it pointing to, right? And when I'm being very specific about the issue calling out exactly that there's a bug here, then it kind of goes a little bit into moderate territory, okay?

Crimson Turtle: So.

Quantum Wolf: Here what happens is question one, I've kind of kept it somewhere between modern and solid. That's what I wrote down. Question two, however, is on the other hand done much better. You took care of edge cases, readability is good again. Code is correct. There is no issue in the code. Coding speed is average in general, so nothing, no positives or negatives there. And here again, you get a solid flash strong, right? So overall kind of becomes at access level a solid rating, okay? Which brings me to verification. Now, verification first question is strictly moderate because you were trying to do a good line by line verification, but you did not catch up your own mistakes. So there are two mistakes in your code, you did not catch them. What's the point of doing line by line verification if you can't catch your own mistakes? So that's something, I think that's the biggest feedback for you from this mock that try to be like when you're trying to do a dry run, Forget any logic in your brain, okay? You have to literally be an interpreter. Read line by line and actually do that operation in the comment section here. Do not actually try to process anything in your brain. That's the biggest mistakes people do and that's why their verification skills are poor and they don't get hired sometimes because of that and that's pretty sad, right? Because you are able to code up things, you obviously know all the structures. and you're getting stuck just at verification stage, which nobody really has to do in their real job, right? So it's something that I feel the most sorry about, that this should really not be happening. And I would encourage you that if you are really focused towards, you know, doing well for Meta this time, it is important to spend, like when you're practicing questions on LeetCode in the next few days or in the next couple of weeks, Every question you do, do not click on submit button, create three for test cases, do a dry run and do a proper dry run and try to catch the issues. If you don't catch the issues and think of it like this that you only get to click on submit button once, right? That's the limitation you have, right? So it's kind of similar to a real coding interview.

Crimson Turtle: And.

Quantum Wolf: Once you click the submit button the first time, if there is an edge case that got missed, write it down. Write down what mistake you made, which kind of HKS did you forget about? Write it down in a Google Doc or a Google Sheet or in a notebook, something that you will have a look at every single day before you start practicing more questions. Okay? That is the only way you'll definitely imbibe this within you in the next one or two weeks. So it's a more short short way of kind of doing that and not making this mistake. so that's that. That's why you get moderated here. You did create a couple of test cases, which is another checklist item that interviewers are looking for. Just the test case given in the question is not enough. You have to create few test cases yourself. Okay, so the interviewer will always ask you unless the time is out. Interviewers are gonna ask you to do some test cases, but to go from a solid to a strong rating in verification, you have to do the test cases proactively. I should not be asking you. Right, so think about that. To go to solid, you need to make sure you do line by line like an interpreter and you fix and find out the issues. And to go to strong, you have to create test cases yourself, right? I should not be asking you for it.

Crimson Turtle: Okay.

Quantum Wolf: Second question is, I was initially thinking it could be solid, but it's also moderate and I'll tell you why. So in, so first of all, I like the way you were trying to do visualization for the state for each number. Very, very clean way of doing the dry run here for second question among the cleanest that I've seen for this question. So that's nice. You did not create a new test case yourself unless I asked. So that automatically pushes it down to, you know, solid and then The other thing was that it would not be considered a proper line by line verification. So here's what happened, right? Once you finish the code, you did a first round of verification yourself by just skimming through it, saying with the test case, you know, with three, this would happen one, this would happen without writing anything down. And then you said, yeah, this should work, right? Don't do that. It's an anti-pattern. Meta is asking you to do proper verification and you have to be patient through it, even if it's boring. So don't say that this would work. Never say that after you've written the code that it will work. A better way to phrase things is, okay, I think this code, I think I've done the code as I thought it should be. Let me try to now test it through dry runs and make sure that there's no bugs in here. Right? And then you will start doing a dry run, do it properly line by line and if nothing like after two test cases, let's say there are no issues in the code, at that point you can say something like that, okay, I think this should work, right? And even then you should ask the interviewer, would you like me to test more test cases? And that's kind of, you know, nudging them to just say yes or no. And if they're saying yes at that moment, there is probably some bug in your code. so that's a better way of directing the whole coding interview, just better way of getting the right answers without sacrificing your performance ratings for any question. That did not happen here first and then when you were actually doing a proper drive and after me asking you to do it with test cases, what happened is you started doing it line by line but when you reach like again, I'm looking at line number 74 to 78, right? when you start going from three, then one, then five. Now, if you technically go through your code, you cannot get an answer for five, like what it will return until you go through two and seven.

Crimson Turtle: Right?

Quantum Wolf: But you ended up not processing things that way. You ended up processing, okay, five will return true and then you went to two, which is not how your code actually goes, right? So again, you're not doing a proper line-by-line verification. Okay, so the expectation is you go line by line and see where it leads you and you can leave some of the variables in partial states if you don't have the full answer right now, right? And that would make it a thorough verification. That's what is expected. That's why you got a moderate here because two times this thing happened and I had to prod you also. So overall then, overall this verification access remains at moderate. Now if you see the hiring bar that I wrote down, wrote up above, you'll see that you're obviously clearing the screening round with this performance. But for onsite, it's a little bit difficult because verification is at moderate.

Crimson Turtle: Okay, okay.

Quantum Wolf: Onsite there is a chance that the interviewer you know, gives you benefit of doubt, but there's a 50 chance they don't clear you because they, because they State poor verification skills. And that's so sad.

Crimson Turtle: Right.

Quantum Wolf: And these are the kind of things that happen when, and then you get feedback from recruiters stating, you know, you were very close to passing the round. Did not happen. This is what's happening. Essentially, you did well on few axes and one access, you were not. up to the, up to the past. So, so that's, this is about it. Hopefully this gives you a better insight into how you are being judged now.

Crimson Turtle: Right, right, right. Yeah. Yeah. Thank you. Thank you so much for the thorough feedback. So it looks like I have to, like, focus more on, on tracing and, like, I didn't, I didn't really know that, like, it's a, it's a minus point against me if I kind of, like, don't do it proactively. So yeah, so definitely in the future I will be like the first one to suggest the test cases and then like do them and then kind of just ask like would you like more test cases from the interviewer?

Quantum Wolf: Yeah, it's always do it like that. Yeah, just always try to be proactive. That's often in fact, although for coding leveling doesn't matter, but for all other interviews except for behavioral, any system design interviews, any other kinds of interviews, often a big difference between E4, E5 or l4s and l5s is actually to how proactive are they, how much are they leading the interview themselves versus requiring the interviewer to help them or to nudge them or to have a back and forth with them.

Crimson Turtle: Right.

Quantum Wolf: So the, the more you lead, the better you seem anyway as a candidate. So that, that'll always be better regardless of which interviewer it is except for behavioral. Behavioral is one of those interviews where the questions would always be coming from the interviewer.

Crimson Turtle: Yeah, thank you so much. Do you do any like, I would like to practice more interviews with you. Is that possible?

Quantum Wolf: Yeah, I think so. I believe there should be a way. One is, so there are two ways around this. One is obviously dedicated coaching. I do dedicated coaching as well with IIO. and you could sign up for three sessions, five sessions, depending upon how many sessions you'd want, and we could turn those into design, behavioral coding or anything else you might be going for. I've coached a lot of people from Meta as well as some for Google Open AI as well. So that's that. The other way would be, I'm not sure if interviewing.io, when you're booking just a regular mock like you did today, whether it supports booking it with a certain person, if it does, you can always. Yeah, it is random as far as I know, but you can always mail support@interview.io to check with them. If there is a way, you could just book it with me. There should be possibility of doing that, but you can just check with them, I would say.

Crimson Turtle: Yeah. Thank you. All right.

Quantum Wolf: Happy to help. Take care. All the very best. Bye-bye.

Crimson Turtle: Bye bye.