Companies do not have the time and qualifications to test the professional knowledge of hired employees. To get into Google or Facebook, you need to learn how to pass interviews. In fact, any Indian seller of Seven-Eleven knows how to pass an interview with these IT companies in Silicon Valley. My roommate with 10 years in journalism learned algorithms and trained to pronounce their solutions in English, he got a job in Apple. People who are 15, 20, 30 years in the profession, this leads to dissonance.
@@troshenkov This is complete bullshit. If Google or Facebook would hire every Seven-Eleven guy those companies would never be the richest companies in the world, they would be a Seven Eleven. The only reason why they are the richest companies in the world because they hire the smartest people possible. In the field of computer science and software engineering there is no better way to determine how good you are then asking to solve an algorithmic problem. You roommate is probably a very smart guy or he has been hired on non-engineering position (which are plenty in companies like Apple etc.)
Real IT Market (95% plus) is about doing a complex CRUD... everything would be a CRUD, even through a REST operation, in the end it's just a complex CRUD. Don't be fooled by those interviews.
Well, this is Bloomberg, so, the clients would here would be their UX department trying to tell you why you have to move a div like, 15 px left for a better investor "experience" *Disclaimer* I don't work at Bloomberg, just a company in the same industry as of this time
I've been a software engineer for 25 years. I have interviewed TONS of prospects. I've NEVER had them code without using a compiler. Typically, I would just come up with a project, give them the directions and let them sit in front of a computer for one hour and hammer it out the way they normally would. They get the compiler, internet, whatever they need. Now, given that, I do expect o see much better code than what would be written in notepad :) As long as they can then thoroughly explain their project to me I'm good with it.
You must be inexperienced. There is a difference between being a progammer and a principal engineer, and also probably 100k a year more. Clearly you never made over six figures.
@@WyMustIGo I have a senior position in a global company of 75000 employees and I make more than most CEOs in my town. I've interviewed probably hundreds of people in my 27 years in the business and I know what I'm talking about. And the bottom line is someone like you could never afford to hire a guy like me.
The interviewer was being super nice with hints. Most would just give you basic instructions, allow you to ask clarifying questions, and then go silent as you struggle through it.
Thats the point of this interview, not really coding the binary tree, but have something to work on together and see how the guy behaves under pressure.
As a software engineer, I swear the only time questions like these matter are in college. Maybe interview for top 5 percent of jobs, but the other 95 percent definitely not going this in depth. Companies need bodies not rainman.
exactly, some my most fun jobs had no whiteboard interviews, just us devs talking shop, those are the real guys, this coding whiteboard shit has its place... in the classroom
I already had technical interview like that and it never productive. It's impossible to keep calm. In a real work scenario, it's ok to research and you don't need to know everything from heart. The important is to know how to think to find the best solution but not resolve things like this and feeling embarrassed.
I practiced these hard in college (because I had to for the classes). Never used it in a real interview.... ever!! Don't waste your time. Learn a framework like Spring, React, React Native, etc. and you are good.
1. Read the question twice. Look at the examples. 2. Clarify the details of the definitions. In this case what is a "successor" 3. Clarify the constraints. 4. Determine edge cases 5. Choose an algorithm associated with the question. e.g. trees -> inorder, pre-order, post-order, bfs, dfs. 6. Implement the naive solution and discuss time and space. Write clean code. 7. If time talk about how you will improve the solution and implement if you can.
now do all that while mock managers are breathing down your neck asking you if the production fix is ready yet, devops is ready to deploy and SLA's are breached.
This advice doesn't always work. Interviewed with amazon once, asked the interviewer several pointed questions before i got started to make sure i 100% understood what he wanted. This was a 45 minute interview. With like 15 minutes left he asks me a question like "how are you going to handle x" I was like "i asked you about that at the start and you said Y, so i built my solution around that" I had all of 15 minutes to try and throw out everything i'd been thinking of for the last 30 minutes. recontextualize and resolve the problem and write it all down (this was a white board) _then_ he still wanted to ask me questions about my now fictional program. long story short, the interviewer boned me, big time. I aced _all_ the other interviews (amazon holds multiple interviews at once on a single day over the course of several hours), so it _had_ to have been this one guy.
@@SmoothCoaxing Nothing happened after. I didn't get the position. while i didn't enquire and further as to why they made their decision, i believe it was that one guy.
10 years in the industry and I echo what others have said here. There is no particular reason to know how to solve this problem from memory. However being able to work through it is the real test here. If I were ever to sit over someone for a coding interview like this, I wouldn't really be looking for the correct solution, rather the approach and how long the individual stick with it.
I mean the majority of dev, programmer interviews is already like that. However, if someone else performs better (i.e. solve the problems much faster and efficient) than our chance to be accepted decreases significantly.
@@otallono yes that's one thing, another thing is that retaining devs are hard, things like stress, deadline, team disintegration, high demand, competition, etc. It's a big money industry but has it's own curse.
this is the reasoning behind ALL math classes throughout ALL education, so many students are like "trig/algrebra is dumb, why do i even have to know this? ill never use it" it teaches you how to think logically and solve problems. that the entire point
My biggest advice for interviews like this "communication is key".. speak with the guy who is interviewing you say what you think. It gives the guy an idea on how you think. Most of the time it is not about the technical knowledge itself but how you handle it.
10 years of development, code is a passion for me. I had to use a binary search once in my whole career, went to Google and copied the algorithm. Your role as a programmer should not be to be able to recreate already found algorithms. Rather it should be to know when why and how to use them. Maybe show a real-world example, and ask the interviewee how he'd design it from a macro perspective, then help him jump some steps, show a very slow implementation and ask him how this could be optimized (using which algorithm for example), what are the caveats, etc. Now you have someone solving a problem, maybe interested in solving this problem, and he doesn't have to be a talking Wikipedia page working on a problem which he'll never encounter in his day-to-day job.
@@ttt69420 Yes, but the algorithm is not what matters. You don't necessarily have to get the algorithm working in the interview. They want to see if you are approaching it correctly. If you memorized how to write the algorithm you were asked to write, it would be quite obvious to the interviewer and it would not impress them.
I mean if the chauffeur was making hundreds of thousands of dollars per year. It would be nice if they could fix the car as soon as it breaks or continue to upgrade the car throughout the years rather than be having to buy a new one...... That would be worth it. Especially if he's driving me around to extremely important meetings where it would cost my company potentially millions of dollars if I was late or didn't make it
@@djk80 "fix the car", Right, let me just get my wrench and pull out the engine then disassemble it, shouldn't be too long. It will be ready in 48 hours.
I’ve had a very successful career as an engineer working on some very cool projects. To the prospective and newer developers out there-when I see companies interviewing like this I run. If this is your jam then cool, but it’s never been my thing. Please don’t buy into the notion that coding challenges are required in the interview process to have a successful career as a developer.
@@Ybby999 Be real man, who has EVER liked them, unless you had like whole time in the world, and it was simply among friends in college, that is different, actuall challenges are pretty cancer, that is blunt honestly.
I think it has some merit. My company hired an SDET that didn't know OOP principles. They tried not doing a coding interview. 4 years later, they still don't know OOP and still stuck in the same position. They have even had mentoring.
These kinds of cliche questions are never ever used in real-life situations. You can literally learn by heart those types of things and pass any interview with breeze but have no idea what you're doing otherwise.
You really can BY-HEART ALL these questions? You can't. You HAVE to come up with solutions on the spot eventually. They even ask you follow up questions if they get the hint that you've memorized this solution. And you can only come up with solutions on the spot if you have good problem solving skills. And you can only have good problem solving skills in such questions after practicing them. Saying that "people can just BY-HEART these questions and pass any interview after a week's preparations" is like saying "people can just BY-HEART all the syntax of javascript and remember all the working of whole MERN stack and pass the interview after a week's practice only". The point being, both approaches work. People get job by doing dsa only, people get jobs without doing dsa at all also. So go for the one which you think is right for you. Another thing I'd like to mention here is that, recruitors prefer dsa questions bcz with these, they can judge you, with numbers. It's tangible how many dsa problems someone solved. But it's not tangible how good of a project someone made. To judge a project, interviewers have to spend a lot of time. And remember that the recruitors that do use dsa questions, don't just use dsa questions. There is usually also a system's design question and computer theory questions. Do not forget the behavioral questions as well
Yes and no. While these aren't real-life problems, you still need to be efficient in sorting out the solution to an unknown problem in real life. Hence, writing BST is a waste of time as you can memo it (agree), while this one is a good example of a problem that you have to wrap your head around and come up with a solution quickly enough, or at least be able to jam with the recruiter to show of your coop skills. This is a good indication of how the candidate will tackle any potential problem.
Thanks for showing this. I have had a few interviews, including one with Amazon (why they wanted me is beyond me..) and I felt so stupid trying to come up with a solution. Seeing that it's just par for the course really makes me feel relieved (and inspired quite frankly). I really appreciate you and your channel. All the best man.
@@joshuamaltez4704 with Amazon, not well. They are strictly interested in people who live and die by O(n) and nothing else, but I was able to secure my dream job with a game company so in the end, it worked out! Thanks again for the insight!
@@imfrommars7362 I learned being a software engineer wasn't for me, but I took what I learned and ended up being a Technical Producer instead! So it goes to show that these skills are valuable and you never know where you'll land!
@ThePrivateJoker There're separate parts for experience and behaviral questions. But trust me, I'll be able to bullshit and cheat the interviewer like a boy if I want. But cheating on "puzzles" part is way more difficult.
They won't need it, but it's so easy that anyone but a junior should write it up in a few minutes after spending a few minutes to understand the question
As a self-taught and still in the early stages of becoming a decent Software Engineer, I am realizing that these problems are actually very logic-based. If you can understand the problem and break it down into simpler problems, you already have 60% of it solved. Figuring out the logic to solve each part is another 30%. The coding part is just 10% and it is the easy part since you are just translating the answer that you already have into code. Please let me know if I'm wrong about this.
There are questions where the "understand part" is rather easy, but the implementation with all corners cases is tough. Search for "Median of two sorted arrays" or "Text Justification"
Just perform a search on the node using recursion and then if the right child doesn't exist, go back to each of the parent nodes and find which of the parent nodes has a value greater than the node you're looking for.
I don't see how they're even approaching it without initially talking about recursion. These interview videos always seem to miss the correct solutions.
They actually missed one case: If the input node was 20, and there was no 25, it would go to the second case and store the parent node as null and child node as 20 i.e., the input node. Then in the while loop, the code will check for null.right, which will throw an exception. So they need to check if in the second case, the parent node is null, return the child node, i.e., the input node.
Node findSuccessor(Node inputNode) { if (inputNode.right != null) { Node next = inputNode.right; while (next.left != null) { next = next.left; } return next; } if (inputNode.parent != null) { //true if (inputNode.parent.left == inputNode) { //false return inputNode.parent } Node prev = inputNode.parent; while (prev.parent != null) { if (prev.parent.left == prev) { return prev.parent; } prev = prev.parent; } } return null; } This was my solution to it. Are there any problems?
The problem with these interviews is equating that how fast you come up with the solution to the problem to how well you understand data structures and algorithms.
I've always wondered if the real job is similar to these online interview or practice problems. Have you worked as SE before? What types of work do you do on your day to day job? Really Curious to know...
@@athegreat88 The problems and type of interviews on YT are not too far away from what you get asked. The problem is, as the OP says, you are asked to answer problems that are in no way reflective of the actual work you do. Once I pass the technical interview, I always ask the company "Can you tell me on what projects does the company use the algorithms or solutions asked for in the technical interview"? No single question you can ask in a tech interview will make the interviewers squirm as much lol. They know they have just asked you to demonstrate knowledge that is unrelated to the role.
Hu Mann 3 more years and i guess i’ll see what cs majors actually work on. If u guys don’t use arrays or data structures in an actual job then i wonder what the “Actual” job or work really is. Really curious to know. What part or section of what we learn in our CS course do we mostly use for jobs?
If only demostrate how you think to solve Problems. Its not all about building things, but analyzing and solving problems. Critical thinking, logic, algorithm. Syntaxes changes but logic is always the same.
Most of the comments are hating on the question of the interview but as a CS major I actually solved it in 1 minute. I know that as a job i will never need to re implement or create the algorithm. Because there’s built in libraries for that. But I think a developer should know how the code is built and how it works.
If a job is asking you about binary trees in an interview, it's a pretty huge red flag. Surefire sign that working for that company is going to suck. It actually was the deciding factor in my last job. One interview was JUST like this followed up by an in person whiteboard. I got lucky and the question asked was almost completely identical to a question that was asked to me at a previous interview. I eventually got an offer, but it felt like such a cold uninviting performance evaluation that I decided to go with a different offer despite it being around 5k shorter in salary. Give a take home test, asks some general debugging questions, ask general questions about the language and frameworks they are familiar with, intentionally break some code and have them fix it, have them write some generic sql. I've been engineering for 10 years and have never had this come up even once.
i think it's mostly meant to weed out people who can't do these problems (and in turn, should not be behind an IDE coding anything), which is surprisingly a lot of people. It only becomes a problem if the questions are stupidly complicated or the whole interview loop is just coding interviews. But like, they have to verify that you can actually code, don't they?
They want to see how you approach a really difficult problem, do you freeze under the pressure of not fully understanding what you are asked to do, or are you gonna try and work it out with or without the interviewer anyway. It is not necessarily a red flag.
Lol finally someone who said it! This is an extremely simple problem for anyone who's taken an algorithms class and the dude held his hand the whole way through it. Shouldn't have taken more than 10 min to be done with the problem.
Ugh, I hate it when during the interviews the interviewer tells you to literally shut up and just do the problem -_- Like, the people interviewing you are people you will be working with on the team, their impressions on you are just as important in whether you want to work with these people basically throwing you off on an island and getting annoyed at you
These idiots made it way too complicated. All you have to do is: First, you take the dinglepop, and you smooth it out with a bunch of schleem. The schleem is then repurposed for later batches. Then you take the dinglebop and push it through the grumbo, where the fleeb is rubbed against it. It's important that the fleeb is rubbed, because the fleeb has all of the fleeb juice. Then a Shlami shows up and he rubs it, and spits on it. Then you cut the fleeb. There's several hizzards in the way. The blaffs rub against the chumbles, and the plubus and grumbo are shaved away. That leaves you with a regular old plumbus!
Traverse the tree in-order. When visiting a node, check if it's the inputNode. If so, set a "nodeFound" flag and continue traversing. Having found the inputNode, at the beginning of the next recursive call, check if nodeFound flag is set (which it should be) and if so, set nodeFound to false and return the current node (which would be inputNode's successor).
This is a good solution but it is O(n) where n is the number of nodes, and it ignores that the structure given is a BST tree, which if balanced, lets us find the target node in O(logn).
Two cases here Case 1 - When right subtree of the node is not null. In this case the successor is the minimum value in the right subtree. Case 2. When the right subtree is null. Traverse from the root to the node. First time we go left in this traversal is the predecessor node.
I hate interviewers who are so hand-on, let the person explain their process to come to an answer. I feel like they tunnel my vision towards the solution. I like interviewers who just provide a hint when I am stuck and quite for a few mins or even ask me if I'd like to get a hint on my path.
As an interviewer, it's quite hard to keep a decent pace without giving too much information and respect the timing that management gives you to conduct the interview at the same time. I'll keep this advice to "ask if the interviewee would like a hint". Thanks.
Been a game developer for 8 years, never asked any candidate these questions, always walked out straight away from interviews when i got asked these questions, never implemented them in my life for once or felt the requirement. Although good information and style and attitude of interviewer.
I'm good at data structure when I'm in college but now I've already forgotten most of them. Never use any of them since I started working and maybe never ever will.
Guys these questions aren't because this is what you're going to work on on a daily basis, it's to give the interviewer a sense of your ability to problem solve. Nobody is going to ask you to write an algorithm everyday, but if you can reasonably solve it and talk your way through it it shows that you have at least a foundational understanding of the concepts involved and also that you can adapt to solve a potentially odd/tricky problem during a stressful time (the interview). It lets the person know that if they put you on an assignment you're more than likely going to solve it in a reasonably well thought out way and that you understand the potential upside to space/time optimization when it matters. It also shows your communication skills to some extent too so it's good to have a positive approachable attitude while working through it.
@Benjamin You can absolutely get better and improve. Very few people are just born so smart that they require very little practice. Hard work beats out raw intelligence many times and once you code for long enough you start seeing patterns and learning various ways to think about things. Most people spend time practicing these type of interview problems so they arent totally thrown off when they are asked to use some data structure to solve a problem. If you remain dedicated you will succeed. Never let the fact someone else may know it better dissuade you from trying at all. Keep practicing and asking questions. If you want to get good at cooking, you must cook often and with the mindset that you're looking to improve. Same goes for coding or problem solving.
@Benjamin At some point IQ will determine the highest level of abstracted complexity you can deal with. Luckily hardly anything in CS is all that complex. That's why there's hundreds of millions of people who can do it.
Everybody is just saying that tech company will only ask you to do some complex CRUD operations and not this one we are seeing, haha. Don't forget that we learn such stuffs for the sake of improving our way of thinking and very soon you will be implementing this in real world projects knowing already and understanding what you are doing and why you are doing it! Thanks! Learn Data Structures and Algorithms, you will never regret doing so! Thanks for this great content and I wish you a very Happy Coding in this very Happy New Year!
Unless you're writing really complex solutions and i mean backend, optimization, you dont really need to know this... I think searching for solutions online its a required skill for any programmer
It’s an academic question and tests the problem solving skills but in professional development this is highly unlikely you will need to implement a binary search and find the next in order. If someone is writing it in your team, slap him and tell the developer there are libraries for that and most likely there is something wrong with the use case the developer is implementing from a business perspective. If the business is writing a framework better than existing frameworks then... good luck 😀
I'm a Staff Software Engineer, been coding for 12 years and tackled a bunch of really complex problems. Having to code an algorithm for concepts like a BST is bullshit, unless you are being hired for really low level programming. It's no way to assess a candidate that will be doing higher level programming on a day to day basis. A bunch of juniors may be able to do it, as it's fresh in their mind from university. Scalability, identification of performance bottlenecks and how to deal with them as well as how to design maintainable code are way better ways to assess a candidate.
Financial applications are really on the embedded/industrial/c/cpp low level, close to metal, close to high speed trading networking infrastructure side of stuff I guess
This problem has an easier solution than shown. Just traverse the tree to find the input node. Save the root node as your return value. When you choose to go left in the search, save your current node as the return value. If the input node is found and has a right node, go right and then left. Return saved node
For this question, it’s actually looking for the next node in the middle order traversal. So just need to continue the middle order traversal from the input node for one step. If the node has right tree, get the left most node of it. Then if the node has parent, go to it, and check if the node is the left or right child, if it’s the left one, return the parent, otherwise go to the parent and check recursively.
The idea he said about change the getMostLeft from recursive approach to a iteration approach is nice but why the interviewer talking about a irrelevant problem? the candidate doesnt even gonna add any pointer which point to its most left node to every single node of the tree. And this definately avoid expanding call stack
The problem itself screaming to apply a inorder traversal on BST. As a fact, Inorder traversal of BST is always a sorted list of nodes so you just need to return the first node whose value is greater than input node. So next time use this fact. PS - I am just a student preparing for interviews
I thought the same thing at first but the time complexity on that solution will be O(n) since you have to traverse the entire tree. I’m not finished with the video yet but the solution of the video seems to cut down the iterations a lot by traversing based on a logic system
Seen a lot of comments about SWENGs never having to do this in their career. I agree, because as coders we DON'T REINVENT THE WHEEL! This is something you ask interns to see how much they've been paying attention to their classwork in undergrad or maybe graduate school.
@@blacksaibot6158 Why would HR ask to see how much I've been paying attention in school ? even if I was an A student, Why is it so important for you guys that I was paying attention ? Whats Academia have to do with all of this ?
@@blacksaibot6158 What value does asking people to solve impossible tasks can add to the work environement ? bcs to me it seems that HR nowadays dont really know How to hire talents and instead they keep hiring A students who clearly lack experience
Honestly if I was in an interview my first question would be, "Does your coding test have a binary tree in it?" If they say yes, "sorry your company is way too pretentious to work for, thank you for the consideration"
@@nathansire6623 Personally as a developer that values myself and my time, I will say no to a company that asks stupid questions in interviews. & I did actually reject an offer for this reason 2 weeks ago.
this is really helpful, it's cool that you recorded this and posted so i know what i will be facing when i advance my coding skills to look for another job
It's a big luck to meet a helpful interviewer like this guy. He was guiding you in the correct direction all the way. In my experience interviewers tend to be way less chatty and the only thing that you can hear from them is the keyboard clicking while they are taking notes on what you doing and saying.
Just so you know, if you are in an interview and they keep pointing to you in the right direction you failed your interview already and they are trying to get rid of you but leaving you the smile. Its ok to help a little and give some hints but fixing your code and letting you know how its done it its a bad interview.
I think it’s an important part of working with someone. It’s a good way to see if someone is coachable because at some point someone will not know everything
Yep, this is exactly as interviews should be. You learn a lot more helping someone with a problem than seeing what they can remember off the cuff in a stressful situation.
We may not have written binary search in our software developer journey but the external libraries we use day to day they use these kind of algorithms. It’ll useful when you’re authoring a library.
This gets on my nerve so much, had to go through all this as a frontend, been doing it for 8 years now and still baffles me when some small company with a simple app use these kind of problems to evalute the applicants knowing damn well they will never encounter issues like this
A time will come when these type of interviews will be seen as gate keeping. I've not worked as a software developer for long but so far none of my work has ever required me to know all these things about "data structures and algorithms". You also don't need to work at FANG or any other company that does these kind of interviews, there are many companies that will judge you by the projects you've done and what you know about the job that they are hiring you to do, these are the companies you should be looking for in my opinion.
Hi. I am currently in my graduation. Could you give me some guidelines on how i go about finding interesting projects for beginners? I mean like simple stuff that helps me build a good base. Because most of the stuff in my course is just theoretical jargon.
@@Taha-id7vs build a project that solves a problem that you have ,a problem that you find interesting to solve or a problem that you genuinely care about. e.g build a url shortener to shorten long links that you hate, an image classifier that can be used to identify diseases in crops, a twitter bot that tweets latest job openings in your area e.t.c in my opinion when there is something connecting you to the project you're building in this case a problem that you want to solve, you will have the will to figure out the technical challenges that your project presents to you. If you can't think of something at all you can always google or look at sites like this careerkarma.com/discussions/projects/ for inspiration.
That's the issue with most companies today. They don't really look at how much you can provide but rather at how good you are with certain data structures that are quite frankly the least used in organizations. In the case that such a data structure has to be used, the employee could pick it up. But keeping everything in memory is quite stupid. What I think has to be tested is a person's ability to solve problems that are more reliant on a person's thinking ability rather than memory abilities. Either ways, data structures are in important in the sense that a person should know when to use what data structure, but necessarily on how to code them out.
@@thatrandomguy8788 some companies will even make "algorithms and data structures" a must know and things like experience building REST APIs or working with AWS are treated like "nice to have". It's ridiculous.
I wish I had interviewers like him, so he can write half of my code. My interviewer would just sit idle and wait for my code to pass all test cases then he would simply say "Nah! You should have arrived at the solution much faster."
I don't know what it is with software interviews. I'm been programming for quite a number of years and anytime I've seen these posted I never think I'd pass an interview. If I was interviewing someone for a job I'd want to see some of their past projects to see what they've done in the past, I'd have them explain why they did something a certain way if it didn't make sense, etc. You can get a good idea of how someone is by how they answer some questions. I'd probably then give them a small assignment or 2 and have them work it to see how it worked. Even in some of these interviews I hear them asking people to use Word or something to write out a program.
This is great. Sometimes even in these technical interviews the interviewer is looking for someone who THINKS - not someone who knows all the answers. Techinically speaking someone who already saw this same problem could write the code in 5 minutes, get the answer right, and the interviewer still knows nothing about them. They don't hire people that just remember a bunch of crap - the job requires thinking. The job involves being wrong sometimes and responding to being told you are wrong and how you respond when you're right and others are wrong. The tech leads what thinking, respectful, and civil people are on their teams.
For everyone who goes "you don't do this in real life as a dev"; No most of the time you wouldn't. But what you want to look at, as an employer/recruiter, is "How well does the candidate tackle the problem? How does the candidate reason in his/her thinking?" while also getting a general understanding of the programming skills. That's why you'll get silly problems to solve.
Seems like Puzzle solving, Riddles etc. Programming requires time, patience and lots of thinking. If you cannot solve it today you think over the night and you come back tomorrow and you solve it. At least that is how I code and its pretty successful way for me.
26:57 I think the candidate was suggesting something like `Node getMostLeft(Node x) { while (x.left != null) x = x.left; return x }`, which wouldn't require any additional pointers on the Node class and thus wouldn't interfere with the insertion method as the interviewer claimed. It's unfortunate that this insight was dismissed as incorrect since it would eliminate the overhead of the recursive call stack. I'm thinking a good way to handle this in the future might be to ask why an extra reference would be needed per node, or offer to write the iterative version to make sure both sides are discussing the same solution. Of course, it's very easy to come up with these approaches after the fact.
I was hoping this kinda video would make me hate my life but naa, I'm ready for that interview... fun to watch, putting this on my programming challenges list
10 years ago, straight fresh from uni I had recently studied BST's and would answer this quickly. 10 years later, I'm generally a better software engineer, by far, but I would have stumbled through this as I've never needed this knowledge day to day. At least for the first 10 minutes while I got my bearings. These kind of questions are daft, I am guessing they came about because people who started Google/early recruits were academics/students fresh from college/uni and it's what they knew. Now these questions are standard as everyone wants to be like Google...
Easy. You repeatedly move up to the parent node's child pointers. If you came from the left, set the current node as the current and start over. IWhen you reach the one where you came from the left, you follow the right node once, then dig down the left nodes as far as you can. You are now at the successor. I have been a software engineer for 36 years and I have implemented almost all of the container data structures from scratch in production. Some people don't do infantile work at 5GHz with 32GB of RAM and 4GB/s storage, with copy paste duplicated incompetence.
As a staff eng at a major tech company... leetcode has ruined the industry and has led to so many terrible candidates flooding the market and occasionally making it through. Now, the bar for coding interviews has been raised to match the LC grinders so top notch experienced folks (and I mean quality experience not just YOE) are often weeded out early in the process. Luckily I've started seeing a trend away from LC starting at midsized companies but I suspect it will take some time.
Recently in an interview I was asked a similar question. Mine was a bit more complicated and I wasnt allowed to use any sources. The thing is I am a new graduate so I kind of messed it up and didnt get hired. I know it isnt the best way to evaluate my worth as a software engineer but still sucks to not get the job.
Just mass apply bro. Any opportunity you see just go after it and grind grind leet code. Rn it’s rlly hard to get a job as a new grad but it’s up to your own will!
I hate coding interviews. The interviewee has to spend time just to read what is happening written by somebody else. If I was going to do a coding interview, I would give the interviewee some basic but important requirements and give them a deadline of a week complete. I want to see how you code and your structure. I want you to give you enough time and to be comfortable to code it in your way. Interviews like this to me are horrible.
Seeing that there is no preference for right or left, parent or child nodes maybe you should just flatten this tree into a hashmap, sort in increasing order and return the next node to the number given.
This question is actually pretty easy for anybody who knows the property of a BST, but could definitely be challenging for people who are not familiar with it. In the day to day work, a BST is probably being used much more rarely, however, I think this is a good interview to evaluate how fast a candidate can figure out a solution from something that he is totally unfamiliar with (but unfair comparing to those who are already familiar with BST for sure)
Just, the problem is, people commenting will just complain that yeah, "why is this question here if I don't do that?" I know I did twice The question is also really common, so ¯\_(ツ)_/¯ you feel me once, shame on you, fool me twice, shame on me
Logic of technical interviews. This problem is called binary tree traversing, it took some Harvard scientists years of research to reverse it and traverse it in the most efficient way. You have 30 minutes while I watch you to solve it.
I've been coding for about 20 years now. If this was my interview I'd honestly just wish him the best of luck looking for someone to fill this role and end the call. Do you want to know how many times I've had to anything remotely like this in my 20 years of coding? Zero. Do you know what most coding jobs consist of? Making front end UI's or communicating with the database. Most everything is behind a tried and tested library and you mostly do boring CRUD work. This does not represent the VAST majority of coding jobs in the market.
youre missing the point though, if he can come up with an efficient solution. it will ripple into his regular solutions at work. especially during the architecture and planning before you write a system. otherwise the system will be written badly and most likely need a re write
Haha the world is so small, I was working as a Concierge in a residential building(got fired past week) and today I'm having a interview as a jr developer in a brokerage firm and I was watching some interview videos on RU-vid to prepare myself and I got here. Fun fact: the interviewer in this video lives in the building that I worked
So friendly interviewer! My last live coding interview was like: - "Write a jQuery-like library for working with DOM" ... - "Ok, I'm gonna use es6 inheritance here" - "Why? No, you shouldn't. Only es5" - "I'm gonna use Object.create() then" - "No. I was expecting something else" - "Can you give a cue?" - "No."
Going to be quite honest here. I worked at one of the top 4 tech companies in the world, and had a bunch of algorithm questions for my interview. It was an advantage that I had a math degree since I breezed through those questions and eventually landed the job. However, I SUCKED as a software engineer my first few years. Didn’t know what the hell tcp/ip was, didn’t know what the hell a majority of other terms were and definitely didn’t really build web APIs before. If someone is passionate about code and can show some of their examples, architecture decisions and optimizations, that should be good enough. These algo questions prove nothing. I understand you can be good at these types of interviews and have experience with a bunch of projects but a lot of great programmers will trip up if asked to find the median in a linked list, ESPECIALLY if timed. Great ideas and software solutions don’t come in a day.
