I support this 100%. Tech interviews are heading towards a bad direction. I'd rather someone is tested for what they applied for rather than slapping leetcode questions and using that as a measure for prowess.
Leetcode problems are not always bad. Sometimes you get a good interviewer with whom you just talk the ins and outs of the problem. To such an interviewer your thought process is more important than whether the solution is a success. Those people are very rare, though, and it's been like 2 years since I saw a person like that. It all depends on the interviewer and their enthusiasm.
@@Pavel-wj7gy That's just a good interviewer. They'd do well no matter what the coding part looked like. They might do even better if they don't use leetcode.
but how? The problems engineers working on in real life are, normally, quite big, complex and entangled. You cannot give any such problem on an interview and see an engineer devouring it bit by bit in a course of one hour. He'll need 3 to 5 months to simply start getting into this problem at work. So how can we assess an engineer, if not by a smaller scale problems that still, hopefully, have some of the properties of the larger ones?
@@chess_ramone culture fit is not a predictor of engineering abilities. And these days there is an insane amount of impoators, of pseudo-engineers wbo Dunning-Krugered themselves into believing tbey are capable while tbey are very far from it.
I interview at startups in London UK quite often, Im very pleased to see the trend of everyone ditching the traditional interviews in favour of "walk me through a recent project" or "explain a piece of tech you enjoy working with to me like I'm 5" and my favourite "let's talk code". Hope the rest of the industry follows.
@@zhoorba just a 30-60min long conversation about anything code. Start Smalltalk and wrap up arguing about whether golang is viable for whatever problem they're facing. One interviewer ended up solving a docker issue I was facing at work at the time lol
@@Unc3 Who gives a shit about your tech stack though. Leetcode style interviews provide a common protocol between interviewers and interviewees. You know exactly what you’re expecting. You’re going to onboard at the company and learn their tech stack anyway. Who gives a crap about some bullshit trivia question I could have Googled in 5 seconds in the actual job?
Algorithms are generally something that I think you would be incompetent for not looking up in a book, even if you are 100% sure of what you are doing, and so they are particularly poor choices for interviews. I understand the thinking is to use it as some sort of iq test substitute, but unfortunately that only seems to work in the extreme (i.e. you may successfully filter the person who can't do fizzbuzz, that is generally predictive of being a bad programmer, but somebody who knows the trick to some obscure algorithm problem isn't generally a better programmer than somebody who bombs the same question). Skilled programmers don't get to be skilled via rote memorization which is mostly what leetcode problems are about. People tell themselves it's about "being able to work through a problem", but we all know that's a lie. For the more difficult leetcode problems, you either know the trick or you don't. Nobody is building that stuff out from first principles while racing against the clock in an interview. At the end of the day, leetcode filtering is just a slight improvement from literally flipping coins . It's embarrassing for me as an interviewer and as a candidate . I just don't know of an alternative that doesn't involve unpaid work / take home projects or unfairly filtering based on where you went to college. So my recommendation for candidates is simply to put in the time and jump through the hoops. It sucks and it isn't fair but I don't think it will be changing anytime soon.
This video represents exactly the kind of paradigm shift I think we should be seeing more of in our industry. Leetcode has it's place and I'm not one to go as far as saying it offers no value, but companies are missing out on hiring potentially fantastic engineers by optimizing for leetcode mastery rather than testing on-the-job tasks. (Hiring a react engineer and exclusively interviewing them on algo problems is just sad). As you said, set your developers up for success, including the ones you're interviewing. Great content.
I recently ran into a junior developer on LinkedIn who made his entire identity around the fact that he did over 1000 leetcode questions. While that is impressive, I also think that this hyper optimization limits you from spending time on other interesting things, like building projects using modern tools and frameworks or learning more about the frontend or backend. Is leetcode really all you need to be successful?
Wow.. you are so well spoken and you really nailed the point you made. Thank you for the advice at the end and providing a solution to a big problem in tech. I hope this video goes viral.
I find it amazing that this isn't more the norm. When you interview at the company I work for we do 1: Informal 1-1 with a dev. No "tech" questions from me. Lets talk about culture, tech-stack, background, ideas, directions. I always encourage people to ask more questions. I lay out the full process going forward. 2: Technical interview (where they already know the format). We do 3 questions - some bad code to refactor, some code with a bug and a small problem to code from scratch (not algorithm-y). This is what we do day-to-day - fix bad code, fix bugs, write new stuff. We allow stackoverflow/google with no penalty. We pair. No one ever leaves without successfully completing this - even if they are not successful. Hopefully they leave with a good feeling. 3: The boring HR stuff. I don't go to these. I never would give a take home question (anymore). Even tho I'm pretty happy that the above is _better_ than the norm, I still think its imperfect. Social people tend to shine, introverts tend to clam up. Almost all processes tend to people who are better at social interactions. I really like the "bring your own interview" idea. I interviewed at a FANG company a few years back - lots of algorithms, etc. I asked the question - how often do they solve these problems. He laughed and said "never". I dropped out of the role as it prevented me from knowing how I would fit in the role.
This is such a breath of fresh air, I wish I got an interview like this. When I get asked Random Terminology Jeopardy or Leet Code Style I am always stressed because I may have missed a question thats not commonly asked or fail to identify the correct algorithmic approach in time, but if you put me in front of an actual code base I can show you I can shine
Holy shit that last part hit me hard. I'm interviewing for a first "real" programming position for the first time, currently working in the general field, and I've had 2 major interviews that reached high stages, one where I reached the HR stage after like 5 interviews, and one where I reached the CTO stage after 4,and both of them ended on "we all really liked you, you have a great vibe and is a great fit for the role, but we still won't accept you". When I asked for feedback, both of them basically told me to go fuck myself. Aside from the ego hit, it's really demoralising to reach final stages without even being given the minimal amount of info - why you didn't accept me...
I'm sorry you had to go through that. It really highlights the soulless culture at some of these companies. It's hard enough already for me and many others sending out resumes with personal messages and getting 0 responses. It brings out the inner imposter syndrome. I hope things go well for you.
Yeah this is awful. I tried with Canonical twice. It's like a 3 month process, every step the people I talked to seemed to like me, even occasionally excited to talk to me. Get to the end "We are pursuing others" like...wtf? Like, if I have some major lacking thing, let me know so I can get better.
I strongly believe these are subsidized by a third party, somehow. They are compiling an updated database of profiles enhanced with education, work experience, and skill level across industries, mostly in "tech". Some (shell) companies are paying folks to program or write scripts until, suddenly, work ceases to be available for certain individuals . I think they are in the process of automating a variety of programming oriented positions.
Potentially, this a component of digital twin generation on a mass scale. Why? Combined with ones search history and threat indexing, potential threats can be targeted and surveilled, possibly even thwarted (convincing, surgical honeypotting )
This is great, love the idea of allowing the interviewee to choose the path. I am going through various interviews and they are all over the place. Some leetcode, some take home. It is hard to really prepare as a front end dev since you can expect just about anything.
11:50 Feedback is very important. It also says a lot about the personality of the Interviewer when they don't give feedbacks especially on rejection. Great video!🙌🏼
This is a lot better than most tech interviews. I think the best part of this, is; it allows better communication between the interviewer and interviewee.
This is the best implementation of technical interview options I have ever seen the Realist choice is my personal favorite because this is exactly what you are being hired for to begin with why not have a dry run of the day to day to see where the individual aligns with someone already working at the company.
This video is incredible. Strongly agree on - If your interview process sucks and strong candidates drop out, that limits the quality of engineer you can hire - Letting the interviewee have some agency over how they can best showcase their skills and themselves. Love the idea that they can “bring their own interview” - Letting candidates know why they got rejected
I talked about the interview process with my superiors and their reaction was more on the lines of "wait, that was an option?". I am pretty sure they won't change a thing because "they know better" , but what I took from that exchange is also what you said in the video "you can make a guess on the company culture based on the interview process".
Good approach Theo, i feel like some companies have no real method of interviewing and just go with the flow. Last interview i "failed": 1. Was approached by the recruiter, scheduled an interview. Did it, was pretty good. 2. Other interview with the TL + Head of HR, questions about how i'd act in some situations and my tech skills. Went pretty well. 3. Next came the "Technical interview". They asked LITERALLY the same questions as the second one, lasted 20 minutes (of the 1:30 that was scheduled), no code, not even leet code. Received an message a couple weeks later: I wasn't "engaged", whatever that means, enough with their project. Dude, i literally have a job. You're the one trying to get me out of there to work with you, not the opposite.
This is great. Providing tech interview options is something I’ve advocated for a long time. If you optimise for hiring one type of person who excels at your one style of interview, you end up with a dangerous monoculture. Different working styles and complementary strengths make for a much better team than “everyone is awesome at leetcode and can recite big O in their sleep”
I appreciate that you’re not just criticizing the current process but also providing alternatives for that process. Offering potential solutions is really important because the vast majority of companies don’t actually put any thought into interview processes, they just copy paste and change some variables. So it’s actually viral to give people something to copy pasta if you want to drive change.
I think this is a great idea! My favorite question to ask in interviews is what's your favorite programming language and why. It gives them a chance to explain how they think about building a project, difficulties they run into, and how their language can help address them.
Dude, Theo. I just have to tell you that you're incredible. I feel so stuck and I hope I figure it out because I just want more than anything to be a really good engineer. I hope I can get out of this Vanilla JS role and be working with cooler technologies and growing towards developing in a more modern way soon. I appreciate the way you go about assessing a potential candidate for hire and I hope you inspire people in hiring roles to do the same.
Setting up for a success is the most important takeaway. I often ask just one question: "describe your passion project" and it filters pretty well those engineers that are really passionate about development and even a bit product management, as a manager i can filter out the most important aspects and validate if they were described enough
As a senior who interviewed a bit, I usually had a technical part and around it was just chit chat programmer to programmer, trying to find what "activates" this interviewee in the first part and then diving deeper after a few technical questions (related to the actual work). People are telling / hiding a lot about their struggles during those chats and it was painless to see if it is a good fit or not. But man I love the ideas in this video and giving multiple options to make sure the interviewee is at its best is really next level! Smart and kind. I want to try this out next time.
Great video and I totally agree with you on every single word and I like the Notion doc (I will steal it). I saw and did a lot of Tech Interviews where the main purpose was to make the candidate fail
You make some really good points, particularly about giving feedback. As an interviewee I would be weary about being send an interview plan weeks in advance and being able to choose the interview style. Going blind into an interview, might mean I'm being caught off guard sometimes, but I would also expect an interviewer to show some understanding given that I didn't know what was coming. If I get to choose the interview style or even the questions, I would assume that the interviewer expects me to be extremely well prepared. That's means I have to do a ton of prep work and induces a lot more anxiety.
I'm a first timer here and I love your approach and attitude. You are the kind of developer/lead I believe I would enjoy working with. I'm with you ... the interview should be about finding the right person for the ACTUAL job they will be doing (or could be in the near future). So often, interviewers are seeking validation of their own KSAs in their questions.
These are great ideas. We usually create realistic problems that demonstrate what a typical work task would look like so option 2. I can see why option 3 is not taken; it’s hard to find interesting feature additions or bug fixes that take 45 minutes to complete, usually those are 3 hrs minimum for work that’s challenging and bug fixes can be however long it takes for you to give up or solve it. I also do quite a bit of work to come up with the right problems, so I can see why other companies tend to do straight leet code.
Great advice as always. When I started interviewing people to work on my teams it really upped my skill on the other side. I've been lucky and I've gotten almost every job I've applied for so I haven't had to do the grueling job search (yet). But I attribute all that luck/success to me being on the other side for so long and it helped me relax and just be myself more in interviews. Interviewing is a very underrated skill considering how important it is to your career as a whole.
Thank you for bringing your voice into this issue. It’s frankly demoralizing to lose a job opportunity where you know that you’d be a perfect fit only to be out-algo’d by someone next in line.
The interview process has definitely thrown me into spirals of depression. I hate wasting my time and mental effort for a company to throw out no offer after the final round and not have any idea what I need to improve.
I love this ideas!, one thing some people get wrong when making no-leetcode interviews is to put you into a problem without any context (or really poor context) expecting you to fix/add something in 30minutes, which tend to fail almost all the time. With your approach you let people know what are they going to so they can at least give a read and prepare to give a good effort into the interview. Personally I like the take home approach in many scenarios as it tend to be more "soft" in terms of coding (because many times people are just nervious in writing code with someone looking in an interview and that does not reflect how good or bad they do at coding really), particularly in scenarios where low/poor context is given in the assessment.
Thanks so much for sharing, Theo! I think a lot of folks I talk to agree that the Algo interview norm is bad, but nobody has any suggestions on how to meaningfully improve things. I really like the flexible alternatives you've come up with, and for offering a process that puts the agency back into the hands of the interviewee. I'll be happily suggesting the Notion notes and this video to my team!
This is awesome! Huge fan of this approach, especially for smaller companies that know exactly what type of engineer they are looking for. It is definitely brutal that college grads need to spend an absurd amount of time preparing for Leetcode style interview rather than building up relevant industry skills. If more companies adopt this approach it could help a lot and entry/early career candidates a ton!
So important to rethink and replan tech interviews, even if companies are doing that slowly, trying and testing different strategies, its important they change
I really like the way you approach tech interviews. Algorithms and leet code are the things that makes me anxious just to think about it. I've been working with web development since 2012 and last year after a layoff in a startup that I've been working on, I started doing interviews for other companies and almost 100% of them had leet code as technical interview - and I failed all of them. Mostly because I'm not really good in algorithms and because of that, anxiety takes me completely... But on the other side, when a company introduced to me a real world problem like implementing components or solving bugs in a React application, I nailed it (even a take-home of developing a SDK for NPM was something that was really fun to do and I also got great feedback for it). So, I think that Theo's notes about interviews and letting the candidates pick which kind of interview they want to go in, is the perfect choice for a developer that is seeking for a job and I hope all companies start doing this more and more. As always, great video Theo! ✨
Given performance anxiety, I would also consider a not-so-technical interview. Talk about some points in their CV and linger a bit on the technical stuff, measure their interests and curiosity.
There is so much truth to this. The majority of interviews I have sat for were clearly designed to break the interviewee. In my experience the worse the interviewing process, the more toxic the work environment. I have turned down several roles for this very reason.
As someone who has been applying and getting denied for the past 6 months, I love this. I feel pretty confident in the things I’ve built, and in the things I’m capable of doing and learning, but man do I hate leetcode questions. More than the technicality, it just feels like a field of gotchas, coupled with interviewers who refuse to give feedback during the problem and just nod along. I love the Pokédex problem, because it’s realistic, and I feel like I could do it front to back, even if I’d need to put a little mental elbow grease into actually writing out the syntax. I feel confident in it because it’s what I enjoy doing! Just let people feel good about themselves, because if you’re a decent place to work, you won’t make me feel on edge or at risk anyway.
Well, the point of leetcode is to proxy analytical problem solving ability in a scalable and stack agnostic way. That the content isn’t something you “use on the job” isn’t the point; it’s to extract underlying ability to solve difficult logical problems, and does seem to line up with psychometrics research about the predictive value of general cognitive ability. I think if properly conducted it works in terms of low false positives if you’re hiring generalists (but maybe you can reduce the false negative, particularly from nerves).
we as a team as a part of my company (not apart of the channel, for clarification) will strive to do better, great call to action, theo is 1000000% right your engineers and scientists quality are a product of your selection process, 10000% facts. damn
I dislike interviewing a lot. I get flustered, feel judged, feel like my time is being wasted for the sake of the interviewer trying to look smart etc. It’s not an accurate reflection of my capabilities or work ethic (just ask the team I’ve been working with since the start of Covid). I’ll definitely be looking to bring in some of these into the interview processes we have internally, as I’m sure there are plenty of people with the same feeling as me.
I'm currently looking for a new frontend job and I did a couple of interviews. In the first one, I was asked to solve an algorithm problem in 30 minutes and I couldn't make it because I wasn't prepared for that. On the other one, I was asked to solve a React problem in the same amount of time and I got a perfect score. So yes, I couldn't agree more on this. Great video.
I've interviewed people a handful of times for a junior react position. I actually liked asking a question about promises/async programming, like implementing Promise.all/allSettled. I liked this a lot because it's an actual domain specific technical problem. Everyone needs to understand async when writing js. Another question I asked is implementing a vanilla todo list. Again, a react developer should have a basic idea of how the dom works, and it is easy to start from scratch and the problem scales to more and more features if there is time.
Agreed 100%. I feel like people have forgotten that interviews are the potential merging of two entities, so it should allow for that 2 way conversation from the get go. "Testing" style interviews automatically make the conversation dominated by the company and doesn't give the interviewee the freedom to fully express themselves. Development, or any technical ability for that matter, is partly an art and if you are not open enough to consider that art is multidimensional, you may lose out on some of the best candidates you will ever interview.
Number 3 is how I got my 1st tech job over 7 years ago. I made a lil mock version of their product and we talked through all the problems and what they wanted to do in the future. Nowadays I wouldnt do that because of family commitments etc. But it can be a great option for those trying to break into the field
agreed 100% . I have seen a lot of devs just grinding leet code more than practical development of apps or understanding core concepts that needed for their development workflow.
This video brings up an obvious truth in our industry. You can be a dev that has shipped prod ready code in modern frameworks for 6 yaers, but when you hit the job market you need to practice for leet code interviews like your are studying for the Bar exam. How about an interview system that is multi option, that lets candidate show strengths and not a gotcha game. Theo is spot on.
Theo, you have some really hot takes sometimes - which I may or may not agree -, but you are always genuine from start to end. When I disagree, it is still great and genuine content. When I agree is the same. You rock, a lot. Really spot on take on interviews 🔥
There is something to be said for a consistent process. You might interview 10 candidates for a spot; it’s nice to be able to compare apples to apples.
In my previous job, the most logical thing to me was just to present a very difficult problem to see how the person would deal with it. I wouldn't even expect them to solve it. I just told them to do whatever they would normally do to troubleshoot the issue. It's pretty apparent if they're a good fit if they then ask questions, use google, I even had one person whip out a book they used for reminders. I never understood why we expect people in these interviews to be great memorizers instead of just being very resourceful.
I really appreciate this. Currently trying to find my first role as a junior level dev. I’ve been asked to code a game, to do leet code questions, and other stuff. I KNOW I’m a competent React engineer because I can build stuff and I know how to build and which tools to use. Getting past the industry BS is such a bummer. Sometimes I doubt myself, but I’ll be damned if I give up. So glad ppl like Theo care about interviewee and their potential to contribute. So many companies do the bare minimum to get know the candidate. Thx Theo 🙏🙏🙏
I like algorithm questions because it tests more general knowledge that applies to any language, framework, game engine. But what is good about this interview process is that I would be much more excited to talk about the option that I chose. And that would be option 3 where I can show my side project.
@@NorweskiDrwal Yeah, most people don't need any algos for frontend. But I like graphical problems on frontend, E.g. once I implemented image pyramid with progressive image loading and touch gestures. It downloads higher quality images as you zoom in. Some math and algos are needed for things like this.
completely agree. I think a lot of times, they forget in technical interviews the role and task the interviewer is gonna do. To me it's pretty like school. You learn a lot of things that you will forget after starting working on something less intense (which is pretty much most of the time)
8 หลายเดือนก่อน
"Your best engineer is only as good as your interview process" - Theo
We do a home technical test where you have 48h to refactor and optimize intentionally bad code. It's low pressure for the candidate, more aligned with what they would be doing if hired and really effective for evaluating a person's level.
Leet code problems are the most irrelevant things when hiring a good engineer. There are way more important things: Can you communicate functionality and features like a real person? Do you know important libraries and Frameworks? Can you document and debug your code? Can you write proper unit, integration, and performance tests? Can you expose functionality behind an API or CLI? Can you choose the best engineering design patterns and implement the correct metaprogramming structures?
I think the reason companies like google require leetcode type interviews is because a lot of engineers are truly awful at optimizing algorithms to run at scale, they have no idea how memory or data is fundamentally being created, copied, moved around, etc. You can’t scale something to a youtube scale if your engineers have no idea how to to optimize things. Unfortunately some things really are math tricks that you either know or don’t know, and they would probably never naturally “come to you”. So it’s preferred to hire people who already are strong in that kind of problem solving, and also have the requisite technical background and intuition to implement things like that. But yeah, if you’re hiring someone to be a front end web dev or implement something that doesn’t need to scale to tons of data, then of course, lc probably shouldn’t be required.
I'm somewhere in-between on this one - I'm up for giving more real-life tasks on interviews, but I also think Leetcode's algorithmy challenges can show who has better problem-solving skills even if they're not related to a job. Coming from a person who usually slays front-end related tasks, but fails miserably general algorithm ones.
THIS. And ByteBoard is another interview experience company which gives you a real world problem and lets you implement a feature from the problem. Recently had a round with a company. Totally cool.
At a previous company I was specifically told that HR and the legal team wouldn't allow variations on interview questions or changing the language we use to question candidates during the interview process. They said this was because if a candidate was not hired and sued us for unfair hiring practices we needed to show that we gave everyone the same opportunity. If we allowed some developers to play to their strengths we weren't being fair to all candidates. I thought this was total BS and often went off script. After a few interviews I was removed from the hiring process and officially reprimanded.
Thank you it was great choice. I had some interview in the last months, Unfortunately after all process and doing home assignment and the team lead was happy about that and excited, they suddenly rejected me and no one answers my email or LinkedIn messages on what was the problems... I wish It wouldn't be bad to tell those companies names to prevent others to get stuck with those...
At least Leetcode style interviews provide a common protocol between interviewers and interviewees. You know exactly what you’re expecting. You’re going to onboard at their company and learn their tech stack anyway. I think it’s better to prove that you’re intelligent, thoughtful and can learn/solve anything they give you instead of answering some bullshit trivia questions I could have googled at the job in 5 seconds. For example, SpaceX asked me how a vector was implemented in C++. I didn’t actually know at the time and didn’t really care, and the interviewer sighed and thought it was a red flag. I googled it after the interview and found out it was something so stupid that I learned it by reading less than a paragraph.
I think that the standard LeetCode interview questions got popular because they can be done on a mass scale at a fast pace. When you're a company like Google, Microsoft, etc, then it only makes sense to use that form of interview because they have a more global scale and each second is counted for and costs a lot of money. Still, doesn't excuse how fast paced they are, your way of interviews are more slow, interesting and most importantely: *Humane*
It happened to me recently. I agree with you, specially option 3. I applied to a back-end position (I'm more of a front-end guy lately) and I failed some random leetcode algorithm, so they dismissed me, even though I made my own back-end router close to the metal and my own zod alternative and a few other open source projects. A few weeks later, they hire me as a front-end dev. The difference was that the front-end interview was about implementing an accessible tab component from scratch and I nailed that. See the difference? but I still have that bitter taste about getting rejected because some random algorithm.
I feel that interviews have become about showing how superior the company is, and how privileged the applicant would be to work with such geniuses. The reality is often that the staff have similar skill sets. The real trick is to make a applicant comfortable and dig down into their whole philosophy toward software. Do they take pride in what they do? Is it just for the dollars? Do they need precise requirements and guidance, or are they able to see the big picture and be innovative? You can't get a feel for this with leet code tests.
I had an interview 2 weeks ago. The interviewer pulled out some crazy dfs hard question. I said i dont know how to do this... It was for a frontend role too. Mind you, I have shipped dozens of app. Most recent one having 10000 users.... Fuck leetcoding. I rather build
It's a bummer, I had a few promising job prospects and I lost out because of the tech interviews. I either barely squeaked by or not at all. s a self-taught frontend engineer, this is difficult. I've decided that never again and I've had to grind Leetcode, about 130 problems so far. I've learned a few new things with TypeScript and JavaScript be overall, I've been learning LeetCode, for the sake of interviews.
In order for a company to be able to conduct "out of the box" interviews, I think we need a new position, like a Technical Hiring Specialist. Currently, the process is pretty much "Let's get a few people on the team out of their work a little bit and get this done quick" and Leetcode is perfect for that. Just pick a few questions out of the wild and boom, you're done preparing for an interview as an interviewer.
If you are building a database, it is incredibly important to know how to construct and traverse B-trees. However, only 5% of engineers work on problems akin to this and they tend to work at the big bois, because that's where that kinda work gets done.
I support this 100%. Tech interviews are heading towards a bad direction. I'd rather someone is tested for what they applied for rather than slapping leetcode questions and using that as a measure for prowess.
Leetcode problems are not always bad. Sometimes you get a good interviewer with whom you just talk the ins and outs of the problem. To such an interviewer your thought process is more important than whether the solution is a success. Those people are very rare, though, and it's been like 2 years since I saw a person like that. It all depends on the interviewer and their enthusiasm.
@@Pavel-wj7gy That's just a good interviewer. They'd do well no matter what the coding part looked like. They might do even better if they don't use leetcode.
but how? The problems engineers working on in real life are, normally, quite big, complex and entangled. You cannot give any such problem on an interview and see an engineer devouring it bit by bit in a course of one hour. He'll need 3 to 5 months to simply start getting into this problem at work. So how can we assess an engineer, if not by a smaller scale problems that still, hopefully, have some of the properties of the larger ones?
@@vitalyl1327 Have you tried culture?
@@chess_ramone culture fit is not a predictor of engineering abilities. And these days there is an insane amount of impoators, of pseudo-engineers wbo Dunning-Krugered themselves into believing tbey are capable while tbey are very far from it.
I interview at startups in London UK quite often, Im very pleased to see the trend of everyone ditching the traditional interviews in favour of "walk me through a recent project" or "explain a piece of tech you enjoy working with to me like I'm 5" and my favourite "let's talk code". Hope the rest of the industry follows.
what's "let's talk code" ?
That’s awesome
@@zhoorba just a 30-60min long conversation about anything code. Start Smalltalk and wrap up arguing about whether golang is viable for whatever problem they're facing. One interviewer ended up solving a docker issue I was facing at work at the time lol
how do you objectively judgd such interviews
@@Unc3 Who gives a shit about your tech stack though. Leetcode style interviews provide a common protocol between interviewers and interviewees. You know exactly what you’re expecting. You’re going to onboard at the company and learn their tech stack anyway. Who gives a crap about some bullshit trivia question I could have Googled in 5 seconds in the actual job?
This video is what we need right now. Instead of explaining things people keep on coming up with Algo this Algo that.
Algo means "something" in Portuguese. Lol '-'
Algorithms are generally something that I think you would be incompetent for not looking up in a book, even if you are 100% sure of what you are doing, and so they are particularly poor choices for interviews.
I understand the thinking is to use it as some sort of iq test substitute, but unfortunately that only seems to work in the extreme (i.e. you may successfully filter the person who can't do fizzbuzz, that is generally predictive of being a bad programmer, but somebody who knows the trick to some obscure algorithm problem isn't generally a better programmer than somebody who bombs the same question). Skilled programmers don't get to be skilled via rote memorization which is mostly what leetcode problems are about. People tell themselves it's about "being able to work through a problem", but we all know that's a lie. For the more difficult leetcode problems, you either know the trick or you don't. Nobody is building that stuff out from first principles while racing against the clock in an interview.
At the end of the day, leetcode filtering is just a slight improvement from literally flipping coins . It's embarrassing for me as an interviewer and as a candidate . I just don't know of an alternative that doesn't involve unpaid work / take home projects or unfairly filtering based on where you went to college.
So my recommendation for candidates is simply to put in the time and jump through the hoops. It sucks and it isn't fair but I don't think it will be changing anytime soon.
This video represents exactly the kind of paradigm shift I think we should be seeing more of in our industry. Leetcode has it's place and I'm not one to go as far as saying it offers no value, but companies are missing out on hiring potentially fantastic engineers by optimizing for leetcode mastery rather than testing on-the-job tasks. (Hiring a react engineer and exclusively interviewing them on algo problems is just sad). As you said, set your developers up for success, including the ones you're interviewing. Great content.
I recently ran into a junior developer on LinkedIn who made his entire identity around the fact that he did over 1000 leetcode questions. While that is impressive, I also think that this hyper optimization limits you from spending time on other interesting things, like building projects using modern tools and frameworks or learning more about the frontend or backend. Is leetcode really all you need to be successful?
Wow.. you are so well spoken and you really nailed the point you made. Thank you for the advice at the end and providing a solution to a big problem in tech. I hope this video goes viral.
I find it amazing that this isn't more the norm.
When you interview at the company I work for we do
1: Informal 1-1 with a dev. No "tech" questions from me. Lets talk about culture, tech-stack, background, ideas, directions. I always encourage people to ask more questions. I lay out the full process going forward.
2: Technical interview (where they already know the format). We do 3 questions - some bad code to refactor, some code with a bug and a small problem to code from scratch (not algorithm-y). This is what we do day-to-day - fix bad code, fix bugs, write new stuff. We allow stackoverflow/google with no penalty. We pair. No one ever leaves without successfully completing this - even if they are not successful. Hopefully they leave with a good feeling.
3: The boring HR stuff. I don't go to these.
I never would give a take home question (anymore).
Even tho I'm pretty happy that the above is _better_ than the norm, I still think its imperfect. Social people tend to shine, introverts tend to clam up. Almost all processes tend to people who are better at social interactions.
I really like the "bring your own interview" idea.
I interviewed at a FANG company a few years back - lots of algorithms, etc. I asked the question - how often do they solve these problems. He laughed and said "never". I dropped out of the role as it prevented me from knowing how I would fit in the role.
I liked the way interviews go on your company! Let me know if you need a front-end dev lol
This is such a breath of fresh air, I wish I got an interview like this. When I get asked Random Terminology Jeopardy or Leet Code Style I am always stressed because I may have missed a question thats not commonly asked or fail to identify the correct algorithmic approach in time, but if you put me in front of an actual code base I can show you I can shine
Holy shit that last part hit me hard. I'm interviewing for a first "real" programming position for the first time, currently working in the general field, and I've had 2 major interviews that reached high stages, one where I reached the HR stage after like 5 interviews, and one where I reached the CTO stage after 4,and both of them ended on "we all really liked you, you have a great vibe and is a great fit for the role, but we still won't accept you".
When I asked for feedback, both of them basically told me to go fuck myself.
Aside from the ego hit, it's really demoralising to reach final stages without even being given the minimal amount of info - why you didn't accept me...
I'm sorry you had to go through that. It really highlights the soulless culture at some of these companies. It's hard enough already for me and many others sending out resumes with personal messages and getting 0 responses. It brings out the inner imposter syndrome. I hope things go well for you.
Yeah this is awful.
I tried with Canonical twice. It's like a 3 month process, every step the people I talked to seemed to like me, even occasionally excited to talk to me.
Get to the end "We are pursuing others" like...wtf? Like, if I have some major lacking thing, let me know so I can get better.
I strongly believe these are subsidized by a third party, somehow. They are compiling an updated database of profiles enhanced with education, work experience, and skill level across industries, mostly in "tech". Some (shell) companies are paying folks to program or write scripts until, suddenly, work ceases to be available for certain individuals . I think they are in the process of automating a variety of programming oriented positions.
Potentially, this a component of digital twin generation on a mass scale. Why? Combined with ones search history and threat indexing, potential threats can be targeted and surveilled, possibly even thwarted (convincing, surgical honeypotting )
In a more protective sense, individuals with essential or exceptional competence can be identified and marked for enhanced guardianship
This is great, love the idea of allowing the interviewee to choose the path. I am going through various interviews and they are all over the place. Some leetcode, some take home. It is hard to really prepare as a front end dev since you can expect just about anything.
I just hit the interview circuit it is a complete wild west, including gotcha games masquerading as technical interviews
11:50 Feedback is very important. It also says a lot about the personality of the Interviewer when they don't give feedbacks especially on rejection.
Great video!🙌🏼
This is a lot better than most tech interviews.
I think the best part of this, is; it allows better communication between the interviewer and interviewee.
This is the best implementation of technical interview options I have ever seen the Realist choice is my personal favorite because this is exactly what you are being hired for to begin with why not have a dry run of the day to day to see where the individual aligns with someone already working at the company.
Thank you Theo for such amazing content! Need more such videos!
This video is incredible. Strongly agree on
- If your interview process sucks and strong candidates drop out, that limits the quality of engineer you can hire
- Letting the interviewee have some agency over how they can best showcase their skills and themselves. Love the idea that they can “bring their own interview”
- Letting candidates know why they got rejected
How great the world would be if everyone adopts your mindset!
You're my role model and I learn a lot from you
I talked about the interview process with my superiors and their reaction was more on the lines of "wait, that was an option?". I am pretty sure they won't change a thing because "they know better" , but what I took from that exchange is also what you said in the video "you can make a guess on the company culture based on the interview process".
Good approach Theo, i feel like some companies have no real method of interviewing and just go with the flow.
Last interview i "failed":
1. Was approached by the recruiter, scheduled an interview. Did it, was pretty good.
2. Other interview with the TL + Head of HR, questions about how i'd act in some situations and my tech skills. Went pretty well.
3. Next came the "Technical interview". They asked LITERALLY the same questions as the second one, lasted 20 minutes (of the 1:30 that was scheduled), no code, not even leet code.
Received an message a couple weeks later: I wasn't "engaged", whatever that means, enough with their project.
Dude, i literally have a job. You're the one trying to get me out of there to work with you, not the opposite.
This is great. Providing tech interview options is something I’ve advocated for a long time. If you optimise for hiring one type of person who excels at your one style of interview, you end up with a dangerous monoculture. Different working styles and complementary strengths make for a much better team than “everyone is awesome at leetcode and can recite big O in their sleep”
I appreciate that you’re not just criticizing the current process but also providing alternatives for that process. Offering potential solutions is really important because the vast majority of companies don’t actually put any thought into interview processes, they just copy paste and change some variables. So it’s actually viral to give people something to copy pasta if you want to drive change.
I think this is a great idea! My favorite question to ask in interviews is what's your favorite programming language and why. It gives them a chance to explain how they think about building a project, difficulties they run into, and how their language can help address them.
Dude, Theo. I just have to tell you that you're incredible. I feel so stuck and I hope I figure it out because I just want more than anything to be a really good engineer. I hope I can get out of this Vanilla JS role and be working with cooler technologies and growing towards developing in a more modern way soon. I appreciate the way you go about assessing a potential candidate for hire and I hope you inspire people in hiring roles to do the same.
Creating options for how you want to interview is amazing and I love it
Thanks for this Theo. 100% agree with this process. Loved the idea on "Option:3 The Realist".
Setting up for a success is the most important takeaway. I often ask just one question: "describe your passion project" and it filters pretty well those engineers that are really passionate about development and even a bit product management, as a manager i can filter out the most important aspects and validate if they were described enough
Mad props for this article! It was of tremendous help.
As a senior who interviewed a bit, I usually had a technical part and around it was just chit chat programmer to programmer, trying to find what "activates" this interviewee in the first part and then diving deeper after a few technical questions (related to the actual work).
People are telling / hiding a lot about their struggles during those chats and it was painless to see if it is a good fit or not.
But man I love the ideas in this video and giving multiple options to make sure the interviewee is at its best is really next level! Smart and kind.
I want to try this out next time.
Great video and I totally agree with you on every single word and I like the Notion doc (I will steal it). I saw and did a lot of Tech Interviews where the main purpose was to make the candidate fail
You make some really good points, particularly about giving feedback.
As an interviewee I would be weary about being send an interview plan weeks in advance and being able to choose the interview style.
Going blind into an interview, might mean I'm being caught off guard sometimes, but I would also expect an interviewer to show some understanding given that I didn't know what was coming.
If I get to choose the interview style or even the questions, I would assume that the interviewer expects me to be extremely well prepared. That's means I have to do a ton of prep work and induces a lot more anxiety.
This is easily becoming my favorite channel
I'm a first timer here and I love your approach and attitude. You are the kind of developer/lead I believe I would enjoy working with. I'm with you ... the interview should be about finding the right person for the ACTUAL job they will be doing (or could be in the near future). So often, interviewers are seeking validation of their own KSAs in their questions.
These are great ideas. We usually create realistic problems that demonstrate what a typical work task would look like so option 2.
I can see why option 3 is not taken; it’s hard to find interesting feature additions or bug fixes that take 45 minutes to complete, usually those are 3 hrs minimum for work that’s challenging and bug fixes can be however long it takes for you to give up or solve it.
I also do quite a bit of work to come up with the right problems, so I can see why other companies tend to do straight leet code.
I strongly support this!! I love this critical thinking and looking from that perspective. I learned so much from this video - thanks for sharing it!
Great advice as always. When I started interviewing people to work on my teams it really upped my skill on the other side. I've been lucky and I've gotten almost every job I've applied for so I haven't had to do the grueling job search (yet). But I attribute all that luck/success to me being on the other side for so long and it helped me relax and just be myself more in interviews. Interviewing is a very underrated skill considering how important it is to your career as a whole.
Thank you for bringing your voice into this issue. It’s frankly demoralizing to lose a job opportunity where you know that you’d be a perfect fit only to be out-algo’d by someone next in line.
The interview process has definitely thrown me into spirals of depression. I hate wasting my time and mental effort for a company to throw out no offer after the final round and not have any idea what I need to improve.
I love this ideas!, one thing some people get wrong when making no-leetcode interviews is to put you into a problem without any context (or really poor context) expecting you to fix/add something in 30minutes, which tend to fail almost all the time. With your approach you let people know what are they going to so they can at least give a read and prepare to give a good effort into the interview.
Personally I like the take home approach in many scenarios as it tend to be more "soft" in terms of coding (because many times people are just nervious in writing code with someone looking in an interview and that does not reflect how good or bad they do at coding really), particularly in scenarios where low/poor context is given in the assessment.
Thanks so much for sharing, Theo! I think a lot of folks I talk to agree that the Algo interview norm is bad, but nobody has any suggestions on how to meaningfully improve things. I really like the flexible alternatives you've come up with, and for offering a process that puts the agency back into the hands of the interviewee. I'll be happily suggesting the Notion notes and this video to my team!
This is awesome! Huge fan of this approach, especially for smaller companies that know exactly what type of engineer they are looking for.
It is definitely brutal that college grads need to spend an absurd amount of time preparing for Leetcode style interview rather than building up relevant industry skills.
If more companies adopt this approach it could help a lot and entry/early career candidates a ton!
Totally agree. Also wrote a blog post about this last year. Thanks for the video!
this is incredible, keep impacting the community positively!
what a wonderful video! I want to rewatch this video every week
So important to rethink and replan tech interviews, even if companies are doing that slowly, trying and testing different strategies, its important they change
I really like the way you approach tech interviews. Algorithms and leet code are the things that makes me anxious just to think about it. I've been working with web development since 2012 and last year after a layoff in a startup that I've been working on, I started doing interviews for other companies and almost 100% of them had leet code as technical interview - and I failed all of them. Mostly because I'm not really good in algorithms and because of that, anxiety takes me completely... But on the other side, when a company introduced to me a real world problem like implementing components or solving bugs in a React application, I nailed it (even a take-home of developing a SDK for NPM was something that was really fun to do and I also got great feedback for it).
So, I think that Theo's notes about interviews and letting the candidates pick which kind of interview they want to go in, is the perfect choice for a developer that is seeking for a job and I hope all companies start doing this more and more. As always, great video Theo! ✨
This is the one of the best content I have watched so far
You seem more thoughtful and involved than most other "interviewers"
Given performance anxiety, I would also consider a not-so-technical interview. Talk about some points in their CV and linger a bit on the technical stuff, measure their interests and curiosity.
There is so much truth to this. The majority of interviews I have sat for were clearly designed to break the interviewee. In my experience the worse the interviewing process, the more toxic the work environment. I have turned down several roles for this very reason.
As someone who has been applying and getting denied for the past 6 months, I love this. I feel pretty confident in the things I’ve built, and in the things I’m capable of doing and learning, but man do I hate leetcode questions. More than the technicality, it just feels like a field of gotchas, coupled with interviewers who refuse to give feedback during the problem and just nod along. I love the Pokédex problem, because it’s realistic, and I feel like I could do it front to back, even if I’d need to put a little mental elbow grease into actually writing out the syntax. I feel confident in it because it’s what I enjoy doing! Just let people feel good about themselves, because if you’re a decent place to work, you won’t make me feel on edge or at risk anyway.
Wow this is a great take. I really hope interviews evolve more in this direction.
Damn, I would genuinely enjoy this process, feels lika an actual evaluation :D
Well, the point of leetcode is to proxy analytical problem solving ability in a scalable and stack agnostic way. That the content isn’t something you “use on the job” isn’t the point; it’s to extract underlying ability to solve difficult logical problems, and does seem to line up with psychometrics research about the predictive value of general cognitive ability. I think if properly conducted it works in terms of low false positives if you’re hiring generalists (but maybe you can reduce the false negative, particularly from nerves).
The realist option is awesome. I wonder why I never thought about that option. So simple. So genius
we as a team as a part of my company (not apart of the channel, for clarification) will strive to do better, great call to action, theo is 1000000% right
your engineers and scientists quality are a product of your selection process, 10000% facts.
damn
I dislike interviewing a lot. I get flustered, feel judged, feel like my time is being wasted for the sake of the interviewer trying to look smart etc. It’s not an accurate reflection of my capabilities or work ethic (just ask the team I’ve been working with since the start of Covid).
I’ll definitely be looking to bring in some of these into the interview processes we have internally, as I’m sure there are plenty of people with the same feeling as me.
I'm currently looking for a new frontend job and I did a couple of interviews. In the first one, I was asked to solve an algorithm problem in 30 minutes and I couldn't make it because I wasn't prepared for that. On the other one, I was asked to solve a React problem in the same amount of time and I got a perfect score. So yes, I couldn't agree more on this. Great video.
I've been doing this for a while when I interview people, it's nice to get the validation.
I've interviewed people a handful of times for a junior react position. I actually liked asking a question about promises/async programming, like implementing Promise.all/allSettled. I liked this a lot because it's an actual domain specific technical problem. Everyone needs to understand async when writing js. Another question I asked is implementing a vanilla todo list. Again, a react developer should have a basic idea of how the dom works, and it is easy to start from scratch and the problem scales to more and more features if there is time.
Agreed 100%. I feel like people have forgotten that interviews are the potential merging of two entities, so it should allow for that 2 way conversation from the get go. "Testing" style interviews automatically make the conversation dominated by the company and doesn't give the interviewee the freedom to fully express themselves. Development, or any technical ability for that matter, is partly an art and if you are not open enough to consider that art is multidimensional, you may lose out on some of the best candidates you will ever interview.
Number 3 is how I got my 1st tech job over 7 years ago. I made a lil mock version of their product and we talked through all the problems and what they wanted to do in the future. Nowadays I wouldnt do that because of family commitments etc. But it can be a great option for those trying to break into the field
100% on every single point in this video. I've turned down roles because the interview put me off.
Also that Pokédex option was fantastic.
Yes! I love your last two options.
agreed 100% . I have seen a lot of devs just grinding leet code more than practical development of apps or understanding core concepts that needed for their development workflow.
Thanks!
🫡
This video brings up an obvious truth in our industry. You can be a dev that has shipped prod ready code in modern frameworks for 6 yaers, but when you hit the job market you need to practice for leet code interviews like your are studying for the Bar exam. How about an interview system that is multi option, that lets candidate show strengths and not a gotcha game. Theo is spot on.
Theo, you have some really hot takes sometimes - which I may or may not agree -, but you are always genuine from start to end. When I disagree, it is still great and genuine content. When I agree is the same. You rock, a lot. Really spot on take on interviews 🔥
There is something to be said for a consistent process. You might interview 10 candidates for a spot; it’s nice to be able to compare apples to apples.
In my previous job, the most logical thing to me was just to present a very difficult problem to see how the person would deal with it. I wouldn't even expect them to solve it. I just told them to do whatever they would normally do to troubleshoot the issue. It's pretty apparent if they're a good fit if they then ask questions, use google, I even had one person whip out a book they used for reminders. I never understood why we expect people in these interviews to be great memorizers instead of just being very resourceful.
Practical questioning is the way, nice work.
I really appreciate this. Currently trying to find my first role as a junior level dev. I’ve been asked to code a game, to do leet code questions, and other stuff. I KNOW I’m a competent React engineer because I can build stuff and I know how to build and which tools to use. Getting past the industry BS is such a bummer. Sometimes I doubt myself, but I’ll be damned if I give up. So glad ppl like Theo care about interviewee and their potential to contribute. So many companies do the bare minimum to get know the candidate. Thx Theo 🙏🙏🙏
React engineer but not a software engineer? Think about what you just said...
I like algorithm questions because it tests more general knowledge that applies to any language, framework, game engine. But what is good about this interview process is that I would be much more excited to talk about the option that I chose. And that would be option 3 where I can show my side project.
Leet algos don’t apply to the frontend :D
@@NorweskiDrwal Yeah, most people don't need any algos for frontend.
But I like graphical problems on frontend, E.g. once I implemented image pyramid with progressive image loading and touch gestures. It downloads higher quality images as you zoom in. Some math and algos are needed for things like this.
Awesome video with great ideas! This makes me want to launch a startup, just so that I can get to hire people using these methods
Great video. I hope companies adopt this method
completely agree. I think a lot of times, they forget in technical interviews the role and task the interviewer is gonna do. To me it's pretty like school. You learn a lot of things that you will forget after starting working on something less intense (which is pretty much most of the time)
"Your best engineer is only as good as your interview process" - Theo
These notes + Video is really great resources, I've already pitched for a few modification in the interviews at work. Hopefully, they'd consider it.
"The Realist" option is really cool.
We do a home technical test where you have 48h to refactor and optimize intentionally bad code. It's low pressure for the candidate, more aligned with what they would be doing if hired and really effective for evaluating a person's level.
Thank you for talking about this. The interview process is broken
Leet code problems are the most irrelevant things when hiring a good engineer.
There are way more important things:
Can you communicate functionality and features like a real person?
Do you know important libraries and Frameworks?
Can you document and debug your code?
Can you write proper unit, integration, and performance tests?
Can you expose functionality behind an API or CLI?
Can you choose the best engineering design patterns and implement the correct metaprogramming structures?
Such a great video. Thanks a million!
I think the reason companies like google require leetcode type interviews is because a lot of engineers are truly awful at optimizing algorithms to run at scale, they have no idea how memory or data is fundamentally being created, copied, moved around, etc. You can’t scale something to a youtube scale if your engineers have no idea how to to optimize things. Unfortunately some things really are math tricks that you either know or don’t know, and they would probably never naturally “come to you”. So it’s preferred to hire people who already are strong in that kind of problem solving, and also have the requisite technical background and intuition to implement things like that.
But yeah, if you’re hiring someone to be a front end web dev or implement something that doesn’t need to scale to tons of data, then of course, lc probably shouldn’t be required.
I'm somewhere in-between on this one - I'm up for giving more real-life tasks on interviews, but I also think Leetcode's algorithmy challenges can show who has better problem-solving skills even if they're not related to a job. Coming from a person who usually slays front-end related tasks, but fails miserably general algorithm ones.
THIS. And ByteBoard is another interview experience company which gives you a real world problem and lets you implement a feature from the problem. Recently had a round with a company. Totally cool.
At a previous company I was specifically told that HR and the legal team wouldn't allow variations on interview questions or changing the language we use to question candidates during the interview process. They said this was because if a candidate was not hired and sued us for unfair hiring practices we needed to show that we gave everyone the same opportunity. If we allowed some developers to play to their strengths we weren't being fair to all candidates.
I thought this was total BS and often went off script. After a few interviews I was removed from the hiring process and officially reprimanded.
We also were not allowed to even make small talk with candidates out of fear of showing any type of favoritism.
Thank you it was great choice.
I had some interview in the last months, Unfortunately after all process and doing home assignment and the team lead was happy about that and excited, they suddenly rejected me and no one answers my email or LinkedIn messages on what was the problems...
I wish It wouldn't be bad to tell those companies names to prevent others to get stuck with those...
At least Leetcode style interviews provide a common protocol between interviewers and interviewees. You know exactly what you’re expecting. You’re going to onboard at their company and learn their tech stack anyway. I think it’s better to prove that you’re intelligent, thoughtful and can learn/solve anything they give you instead of answering some bullshit trivia questions I could have googled at the job in 5 seconds.
For example, SpaceX asked me how a vector was implemented in C++. I didn’t actually know at the time and didn’t really care, and the interviewer sighed and thought it was a red flag. I googled it after the interview and found out it was something so stupid that I learned it by reading less than a paragraph.
Love option 3, and it fits so well on Open Source too. I just hope you ideally also pay people for it.
That was super cool and inspiring. Thanks!
I think that the standard LeetCode interview questions got popular because they can be done on a mass scale at a fast pace. When you're a company like Google, Microsoft, etc, then it only makes sense to use that form of interview because they have a more global scale and each second is counted for and costs a lot of money.
Still, doesn't excuse how fast paced they are, your way of interviews are more slow, interesting and most importantely: *Humane*
It happened to me recently. I agree with you, specially option 3. I applied to a back-end position (I'm more of a front-end guy lately) and I failed some random leetcode algorithm, so they dismissed me, even though I made my own back-end router close to the metal and my own zod alternative and a few other open source projects. A few weeks later, they hire me as a front-end dev. The difference was that the front-end interview was about implementing an accessible tab component from scratch and I nailed that. See the difference? but I still have that bitter taste about getting rejected because some random algorithm.
I love this approach
I feel that interviews have become about showing how superior the company is, and how privileged the applicant would be to work with such geniuses. The reality is often that the staff have similar skill sets. The real trick is to make a applicant comfortable and dig down into their whole philosophy toward software. Do they take pride in what they do? Is it just for the dollars? Do they need precise requirements and guidance, or are they able to see the big picture and be innovative? You can't get a feel for this with leet code tests.
I had an interview 2 weeks ago. The interviewer pulled out some crazy dfs hard question. I said i dont know how to do this... It was for a frontend role too. Mind you, I have shipped dozens of app. Most recent one having 10000 users.... Fuck leetcoding. I rather build
I do the technical screen for my tech consulting agency I'm convinced I will use your framework
Here I am thought I knew nothing about react until I saw 2nd option's example thinking the heck that is easy as hell
Valuable lessons. Thanks for that!
I love the "Dan being the creator of React" joke
It's a bummer, I had a few promising job prospects and I lost out because of the tech interviews. I either barely squeaked by or not at all. s a self-taught frontend engineer, this is difficult. I've decided that never again and I've had to grind Leetcode, about 130 problems so far. I've learned a few new things with TypeScript and JavaScript be overall, I've been learning LeetCode, for the sake of interviews.
In order for a company to be able to conduct "out of the box" interviews, I think we need a new position, like a Technical Hiring Specialist. Currently, the process is pretty much "Let's get a few people on the team out of their work a little bit and get this done quick" and Leetcode is perfect for that. Just pick a few questions out of the wild and boom, you're done preparing for an interview as an interviewer.
If you are building a database, it is incredibly important to know how to construct and traverse B-trees.
However, only 5% of engineers work on problems akin to this and they tend to work at the big bois, because that's where that kinda work gets done.