Amrita Dasgupta, Senior Software Engineer at LinkedIn, shares more about the technical screen for the Applications Engineering track.
Hi everyone. Welcome to Prep in session for technical phone screening. I'm amrita I'll be walking through the agenda for today for a meeting and I'll be talking about different that we need to keep in mind for our telephone screen, technical phone screen and also what are the things that a candidate is evaluated based on? Let me begin by talking a little bit about myself. I'm amrita I'm a backend engineer at LinkedIn. I've been here for about three years now and I work in Talent and LinkedIn Talent Insights team. And what my team works on is basically providing helpful and meaningful insights our to customers, be it individual customers or at an enterprise level. For example, a candidate who is looking through LinkedIn jobs can see useful insights regarding the number of applicants or sometimes about the sales information and also about providing different insights to the companies for the recruiting team so that they can tap talent the right way and they can look for the right skills in the right places so that they're able to recruit faster. I not only get to work on the back end rest services, I also get to work on the fun big data stuff as well. So without further ado that was about me, let's talk about the technical phone screening. What typically happens in a technical phone skinning round? So a candidate would be typically given about two coding questions and they are evaluated based on the fundamentals of computer science and also their knowledge on data structures and how they're approaching a problem, how they're writing the code, on their coding skills, on their analytical skills. And also another major factor that we look into is communication skills because since you'll be working in a team, typically we want to make sure that you're able to function in a team. But since this is just the first technical phone screen, definitely the more emphasis on the coding problems and how you're solving the problems and how you're approaching the solutions. So definitely having a good understanding of the different data structures that are out there, what are the pros and cons of each and when to use which one, depending on the question, depending on the scenario, trying to make sure that the runtime is as minimal as possible, trying to make sure that we are not exceeding space, we are not having too much space complexity, definitely having a good understanding of these things will help the candidate succeed. In the TPS round you'll be writing the code repair and we normally don't run the program. So definitely being able to do the drive run when you have written the code will be helpful for the interviewer to evaluate and also show that yes, that your code is working, that it will work. And also if there are any edge cases that you missed, highlighting those during your session is important. Definitely when you're given the question, instead of jumping right away into the coding pieces into coding the program. Try to look at the problem in a more bigger picture way and try to see if you can if all the questions, all the assumptions are being answered, that is, if you need to handle null, if you need to handle empty cases, if there are any corner cases that are not talked about in the problem, it's good to bring those up and clarify all the questions that you might have regarding the question, regarding the input of the question, regarding the expected output of the question, it's great to clarify those and highlight those during the interview before you start coding, once you have clarified all the assumptions, definitely try to bring up if you have a working solution in mind, definitely bring that up. Even if it is not super optimal, definitely having a working solution is super important. So discuss the solution that you have in mind before you start coding with the interviewer. And if the interview is great, if it's okay with it, then definitely proceed towards coding. Coding you can do in any language, so feel free to pick up the language of your choice and then you can start coding once you have the green signal from the interviewer. So the evaluation criteria as I was talking about, that the candidate will be. Evaluated based on the knowledge of data. Structures and the fundamentals of computer science and also how you're trying to calculate the runtime the space complexity and also to mention that this will be quoted packed so you won't have the normal help that we have with ID or online access. So definitely having good understanding of algorithmic logic is important for your interview. Also algorithmic hints would be like as I was mentioning that definitely try to come up with a working solution. Also when you're brainstorming for the solution, try to think loudly, try to explain your thought process because what the interviewer wants to understand other than just your coding is also how you're trying to approach a problem. Because sometimes if you are trying to think of a solution in a certain direction, and let's say if you're going off track, or if you're deviating from the problem, or if you're thinking something incorrectly, the interviewer can guide you and bring you back and try to bring you back on track by giving you hints. So definitely look out for the hints that the interviewer is giving. Try to understand the signals that the interviewer is giving because he or she's there to guide you through the problem. So definitely think out loudly and talk as you are trying to base on the solution that is very important for the interviewer to understand what kind of logic you are trying to come up with. Secondly, when you're writing the code, definitely try to talk loudly when you're trying to write the code, as in like if you're initiating a variable, if you're writing a buy loop, if you're writing a follow? What is that loop happening? What is it trying to do? Just if you try to explain when you're writing the code this way, the interviewer is also on the same page rather than him or her reading through the code and trying to understand what you're trying to do there. Definitely try to write cleaner code, modular code and make sure that you tend to have meaningful variable names but also be mindful of the time. Do not spend too much time making the code prettier if your main logic of the code is not out there yet and you're running out of time. So definitely be mindful of the time because it could be typically a 1 hour interview and you have a question. So definitely try to talk loudly when you're trying to write the code this way. The interviewer can also guide you or help you if something is incorrect or something is missing. Another thing that is when you're trying to talk out loudly and explaining it to someone, you try to catch edge cases or corner cases quickly when you're trying to write it by just repeating it in your head. So definitely that is another plus point of talking loudly that you'll be able to catch the quality sooner. All right. Also, as I was mentioning that definitely want to write cleaner code, modular code. Definitely do not try to overengineer the solution, don't try to over complicate the solution. As I said, it's very easy to read. It's easier for the interviewer to evaluate you in a better way as well. Definitely don't have too many nested fails conditions and basically just try to keep the code cleaner as clean as possible and modular as possible. It will definitely highlight that you are using the Java or whichever language you are using. You're using the best coding practices and it's always a good thing to highlight that during an interview. Next, since we talked about a couple of tips and tricks and also how the candidates would be evaluated, let's see if we can try to do a dummy coding around and see how to implement those. So let's get started on the question. That we're going to be solving together. For the example. So let's say during the interview I've been given a question that have to search an element in a sorted array. So. What are the things at this point that is given to me in the question? I know that it is a sorted array and that I have to search and element. So based on the tips and tricks that we were looking into, I would try to get all the clarifications done with the interviewer. Let's say my question is that and I'm also going to note them down on the quote repair. So let's say my question is that whether this is an intraday and if there are going to be negative values, which is also possible considering this is an integer array. So I'm going to try to get these questions clarified with the interviewer. And let's say that, yes, it's an Interra and yes, there is a possibility for negative numbers. I can also ask another question that I can ask is can the input be empty or null? Do I need to handle those cases? Can it have only one element? Things like that. So whatever doubts or edge cases that you can think of just by looking at the question, try to clarify them with the interview. And also it would be a good practice to write them down so that both of you are on the same page. So let's say that, yes, we do need to handle this one and let's assume that we know for sure that there would be more than one element. What do we do if element not found? This is a possibility, right? So what do we do? The question doesn't clarify what should we be doing at this point. So if element not found, we can ask that can be written minus one. If the interviewer wants you to return something else, he or she can point that out. So yeah, once we have the questions initially sorted out, once we have the details laid out, we can start focusing on the brainstorming of the solution. Another thing that I noticed that the question doesn't have the API defined. So I would also maybe bring up that here. Is this something that we're looking at that we return? Let's say that this is the API. It takes the array and also the number or the element that we are trying to search in the array. So those are the two parameters and it's returned type as integer. That means maybe we can return the index of the value if we find it, so we can confirm this, if this looks okay with the interviewer and then we can proceed in brainstorming. So let's say the search of the question is searching an element in a sorted area. We know that it is sorted, but one possible solution or a brute force solution would be that we do a linear search and try to find like we look at each index and until we hit the target, until they find the target. So that would be one possible solution which would have the runtime of O of N. So maybe at this point the interviewer might be looking for a better solution and would ask you or ask me to come up with a better solution or if we can improve on the runtime here. So, considering that it's a sorted array, another thing that we can do is binary search, as I had given the name of the method. So we can try binary search. So I would explain briefly what I'm trying to do. That is we look at the middle element of the array and we compare it with target, if we find the target, if the middle element is the target. That's great. We return the index of that, that is the middle element. If not, let's say the target value is less than the middle element. So we would go to the left. We would then look for the element in the left side. Since it's sorted, we can do this way. So we can divide and conquer. If it is higher than the middle element, the target value, we would move on to the right side of the. We would look into the right half. Of the array and try to search for the element against similar ways. At this point the interview is like yes, that's it. And we can get started coding. One more thing I would like to highlight is that when we are coding, it's great to talk out loudly what we are writing. So since I gave a brief explanation of the logic that I'm trying to do, so I would proceed with that and I'll also explain what I'm writing as I'm writing. So let's say I'm defining variables low, which is the low or the start index of the array. So in this case it is zero. So we know that the index will always in the beginning at least the starting index of the array is zero. Let's say I define another variable, which is the last index of the A. So it would be length of the array minus one. Now, what I would do is I have to iteratively try to calculate the middle and compare with target and then decide whether I want to analyze the left side of the array or the right side of the array. So that means let's create a loop for that. So the loop will run until as long as low is less than or equal to high. As long as the minute that switches. We should come out of the loop. So that would be our breaking condition here. What I would check is what I would do is that first we need the middle element to be calculated. So our middle element will be. What. We would do is we would calculate the middle element here. And now first thing that we would check is whether the middle element is equal to target. So if this middle element is equal to target, that means we found the index that we are looking for. So at this point we would just return mid, sorry, not mid, it would be mid. So let's say the target is less than mid value, right? So at this point I would move to left side of the array. So when I move left side of the array, the low still remains the starting as it is, but the high becomes mid minus one. If neither of these two cases satisfy, I would just move to the right side. That would mean low would be plus one. So this is sort of our wild loop. If we find the element, it would get satisfied over here. Let's say we are out of the while loop and we don't have a mid element. If you're out of the while loop, that means we did not find the middle element, we did not find the target element in the array. So at this point, as per our discussion, as per the clarification that I made with the interviewer, I would return minus one and in the end I would also try to do a dry run with an example and also mention the runtime. And also if the interviewer is satisfied with the answer, he or she will move on from this one. Or if there are any follow up questions, they would probably at this point they would ask you to resolve if there are any follow up questions for you. So yeah, this is how we would try to utilize all the tips and tricks that we learned into solving a sample coding question during the screening round. So FAQ for a telephonic round. So one common question that we have is that we need to compile and run the code. We won't, we don't have to compile. And run the code. We will be using code repair, but we will not be running it. Definitely. And that's why having a dry run with an example is helpful to the interviewer here. That way they will be understanding that yes, your code will be running fine with an example. Another common question that we have is will there be any system design questions asked? Since this is a technical phone questions, it will be just the two coding questions. We will not have any system design questions for a TPS round. So pretty much since it will be just like 1 hour, we'll be focusing only on two coding questions and most of the time it hits up the whole hour. So we won't have any system design question. Another question is how many coding problems do we need to solve? So I think I mentioned that we'll have two coding questions and that's what we'll try to solve in the 1 hour. Typically we have like a warm up question and another question. But yeah, generally we have two questions. Cool. So thank you everyone for listening, for joining to discussion and listening to this video. Hopefully this video is helpful and hopefully you're able to do creating your Telephonic Phones technical phone screen. Bye.