18 ms·

Interviews in the Age of AI: Ditch Leetcode – Try Code Reviews Instead

• otteromkram 3y ago
  I like this idea, but still think that time and people watching you will add pressure. Most coding challenges that non-FAANG companies give aren't terribly hard; they mostly want you to work through your process out loud, ask questions, interact. These soft skills are as important as technical aptitude in determining whether or not you'd be a good fit with the organization.
  • CharlieDigital 3y ago
    > but still think that time and people watching you will add pressure When I conduct interviews, I always try to set a conversational tone from the very beginning. Code reviews in general lend themselves more to a conversational interaction and discussion rather than trying to read, process, construct, and respond in a coding challenge.
    • shortrounddev2 3y ago
      It's admirable, but the interviewee is always under some kind of pressure to perform. if you are taking a conversational tone, they're going out of their way to be similarly nonchalant
  • nextlevelwizard 3y ago
    But you will have people watching you work and you will be under time pressure in normal work as well, so if you just turn to spagetti at interview are you actually going to perform any better at day to day?
    • baka367 3y ago
      When was the last time you had to nail out a fully working nlog(n) longest valid bracket sequence in to prod within 45 mins, without spending 3 weeks in meetings, design doc reviews, capacity plannings and allocations and alignments with the said bracket owners?
      • hcks 3y ago
        meetings, design doc reviews, capacity plannings and allocations and alignments are not supposed to be used as ways to hide mediocrity
      • nextlevelwizard 3y ago
        No one - literally no one - expects perfect implementation of anything in an interview, where are you even getting this notion? What actually *is* expected of you is to describe how you would approach the issue.
    • shortrounddev2 3y ago
      I literally never have anyone watching me code, and the time pressure of an interview is way shorter than a 2 week development cycle
      • nextlevelwizard 3y ago
        So you have never worked in an office with other people? And yes couple hours of interview is different than two weeks sprint, but you are very naive if you think two week of work days means 80 hours of work. Plus I expect a lot more from you during a sprint than during an interview. During an interview I am fine with pseudo code as long as you can explain what you want to do. During actual sprint I actually expect tested deliverables.
        • shortrounddev2 3y ago
          > So you have never worked in an office with other people? I used to, but even then nobody actively watched me code. Everyone else had their own jobs to do > During an interview I am fine with pseudo code as long as you can explain what you want to do. During actual sprint I actually expect tested deliverables. So you're optimizing for the ability to write pseudocode under intense time pressure and social awkwardness. Is that the most important quality you seek in a candidate?
          • nextlevelwizard 3y ago
            [flagged]
• Terrenceenrique 3y ago
  [dead]
• very_good_man 3y ago
  Leetcode being asked in an interview is a marker of an incompetent organization.
  • kemiller 3y ago
    I agree, but it's near-universal. Not sure what that says about our industry.
    • jgilias 3y ago
      That most are incompetent organizations, I guess.
    • bluGill 3y ago
      There is research into how an interview should be done to find who will be a good or bad employee. Most companies (not just our industry!) don't appear to have even looked at it. (I'm not sure how useful the research is for real world hiring)
      • osigurdson 3y ago
        Links?
        • bluGill 3y ago
          I don't know how to search the academic literature to find it. I'm not even sure it is online to link. I just know it is done.
          • deleted 3y ago
            [deleted]
  • hotnfresh 3y ago
    Especially when they don’t pay FAANG money. If I were capable of looking good during the only experience in my adult life that feels like having a solo in a middle school strings recital, I’d be applying to those places, not yours.
• swader999 3y ago
  I like this article a lot and have had great success with this tactic (as a hiring manager) over the years. I often give a page or two of code as a take home assignment to discuss at the interview. They get a chance to look at it and research it on their own. And they also get a bit of the crucible of face to face thinking and reacting on their feet while you discuss it with them in the interview.
  • napo 3y ago
    why opting for an "home assignment" instead of doing that as part of the interview?
    • shortrounddev2 3y ago
      Better simulates the conditions of the job. I never have to write code on-demand in front of my boss with my job on the line. I get assignments and I do them asynchronously. Less pressure that way and I can do it right.
    • osigurdson 3y ago
      Possibly because many quality candidates work / think better when not being watched. It is also likely far more natural for most people.
    • Aurornis 3y ago
      In my experience, most candidates prefer it. They get to use their own computer and own environment and nobody is pressuring them while they code. It’s also most similar to the job, where I won’t be standing over their shoulder doing live coding.
  • danwee 3y ago
    In the year 2023 tech companies are not "buying" (supply > demand) but "selling" (supply < demand); that means the hiring process should at least be equal in terms of time spent on it. Candidates spend way more time in home assignments (hours to days), while companies spend in the order of minutes to review the assigments. We think this is "normal" because "the company is OFFERING you a job"... that couldn't be less true nowadays, it is "me the one CONSIDERING working for your company". A big difference.
• christofosho 3y ago
  For take home reviews, I wonder what the impact of generative AI would be. I can see a lot of people feeding the code segment into an AI and using it's comments instead of generating their own. Of course, people will do that with programming questions as well, so I suppose it's up to the hiring manager to decide on the best method to handle this situation. What strategies do people leverage to avoid purely AI answers?
  • bluGill 3y ago
    Time will tell, but there optimists are already predicting that in just a few years great programmers will feed requirements into AI and then review the code it produces, not write code themselves. I'm not sure I believe it, but given that someone who can make AI produce good results is worth a lot more than a great programmer without an AI.
  • Aurornis 3y ago
    A good take-home interview process usually involves a review phase where the candidate talks about their solution and how it works. This is remarkably effective at filtering out people who had a little too much help in solving it, either from friends, Googling it, or now using an LLM. It doesn’t happen often, but from time to time someone will come in with a solution they supposedly wrote in the past week but they are unable to discuss it. “I don’t remember exactly what I did here…” and other excuses. It doesn’t take much discussion to reveal someone who never actually understood their own submission. Of course, I always continue the technical interview to cover the odd possibility that maybe they were too nervous or something. So far I haven’t had anyone who is unable to discuss their own take-home yet shows well in the rest of the interview process.
  • trescenzi 3y ago
    With a take home, and honestly any kind of interview, the key is not in the deliverable it's in the discussion about it. To be totally honest as a hiring manager I don't care if a take home was fully written by AI so long as when we discuss the solution the candidate can clearly explain how the code works and why it was written that way. Of course in the case of an AI the why might be flimsy but if it isn't then who cares. The goal is to hire someone who's capable of solving problems and in turn explaining their solutions I don't care who wrote the code.
• liquidpele 3y ago
  This acts like cheaters didn’t exist before AI, give me a break.
• antman 3y ago
  Makes sense, any ideas of dead Github projects to use for interviews? I assume most projects evolve so difficult to count on their current status to present them for code review.
• suriyaG 3y ago
  I might have a different take. But, is it not the case that anything more than wiring up high level APIs together, requires understanding a fair amount of DSA? I'm preparing for interviews and I kinda see the value in them.
• chefandy 3y ago
  I like this. In the last dev organization I worked with, we made an artificial practical coding problem, like adding a small feature to an existing purpose-made codebase. It was nice to directly compare the results of the same task among several candidates, and we were fortunate enough to be authorized to pay them for their time. All great but it was a ton of work... Making the challenge, doing code reviews, debating valid differences in approach or unexpected but understandable interpretations of the challenge... I think the code review method could tell you a lot of the same things about a candidate and show whether or not people can issue criticism without being jerks.
• bluehorizon2 3y ago
  People are forgetting why companies these days do Leetcode in the first place. The initial reason why we have Leetcode today is that Google originally determined through their interview research that the smartest candidates were the ones who were best at algorithms. Google wanted to hire the smartest people, not necessarily the best coders, so that’s why their interviews were mostly algorithmic. Of course everyone started copying Google without doing the same research and the message got lost. They just blindly asked coding algo questions and that’s why we have an entire industry built around coding algos and the signal is entirely lost now. It’s funny that people have lost that intent and are now creating derivatives around that, ie thinking code reviews are a good replacement. It might be, but there needs to be data done to research it to see if you get what you want. If you interview using code reviews, you get good code reviewers. If that’s what you want, great. But remember that Google’s initial goal was to hire smart people, and there’s no research to suggest that good code reviewers are smarter than average.
  • hcks 3y ago
    It’s just a proxy measure for IQ really. They could have handed out Ravens matrices and got better outcomes prediction.
    • guappa 3y ago
      You can also train for IQ tests.
      • mywittyname 3y ago
        People misunderstand the reason for this. Test takers can improve, but only up to a point, and only because they getting comfortable with the test format, not because they're getting any smarter. Solution: give the candidates a few practice tests first. This extends to every test though. My ACT score jumped massively on my second try. The reason: I didn't realize how much little time they gave test-takers, so I ran out of time on some portions. The second time around, I rushed through as fast as possible.
• danwee 3y ago
  Not sure if it would be any better, and I say this as someone who hates leetcode-related interviews. Code reviews are way more subjective than writing a piece code (at the end of the interview session, if the code works, then that's a huge thing already). If I highlight something like "Perhaps we could inject that dependency, instead of harcoding it": sure, that seems probably the most correct assesment, but again, what if we are dealing with a really small project and hardcoding the dependency is the best way? Same goes for variable names ("i" is too short? Depends on the scope, right? Well, probably it depends on the interviewer's mind), what about composition vs inheritance? Again, subjective as hell. And don't let me get started with anything related to microservices vs monolith...
  • francisofascii 3y ago
    I think job interviews are subjective and not a bad thing. Some objectively good candidates are not good for certain roles and vice versa. To me, your answer would be the best and would allow you to fit into more roles. You give options for a situation, rather than dogmatic statements like, you must inject that dependency, or the variable names should be done this way. But that is my subjective assessment.
  • endemic 3y ago
    I've come to the conclusion that any sort of job interview has a high level of subjectivity. Basically as an applicant, you roll the dice and hope that you have a good day and "click" with the interviewer.
• wiremine 3y ago
  I'm a CTO for a small software studio. We've used mini projects and code reviews in our interview process for years, and it works great. The code review is a great way to explore a candidate's ability to code, and also to communicate their decisions about a piece of code. In the "age of AI", I'm not sure we'll ditch the mini projects. I think testing a candidate's ability to _use_ AI to generate code is an important skill. However, it's so new, I'm not sure what the best practices might be. I'd be curious if anyone has any advice on this front...
  • codeTired 3y ago
    I use AI to generate code sometimes but it often doesn’t work as expected. Other times I get just awfully inefficient answer. Someone who has programmed without AI for a few years will spot those things. Someone who doesn’t have any “gut feeling” formed about code and just relies strictly on AI will do awful. I think your approach is good, I would introduce things that work but are terrible design decisions and have the person interviewing figure out what could be improved.
  • Dudester230602 3y ago
    Would you allow employees to subcontract and outsource their work?
    • wiremine 3y ago
      > Would you allow employees to subcontract and outsource their work? No, but I do encourage them to use the best tools possible. :-)
      • Dudester230602 3y ago
        "Sir, there is this approach where I feed in requirements and get back results, can I use it?"
        • farhanhubble 3y ago
          You can't fix the stupid ones no matter what hiring strategy you use.
• hcks 3y ago
  I don’t get why people always hate on leetcodes. Anyone can train and get good at it, it makes interviews short and not time consuming, it’s a standard accros industry so you can focus on studying it and not have to read one book for each company you apply to. What would be a better alternative? Hiring based on connections? Take home assignments that takes 15 hours to complete? Domain specific knowledge grilling?
  • codeTired 3y ago
    Because adults with hobbies and families have better things to do. How is this so hard to grasp? Bonus is that 90% of devs literally will not use most of that knowledge. My biggest problems are getting requirements, understanding the problem, working around a legacy system or deciphering old code, not actually writing code when requirements and documentation is on point.
    • brigadier132 3y ago
      > Because adults with hobbies and families have better things to do If you really valued your time you would spend a week studying for the interview that gives you a 50pct or more increase in salary so you can work that many fewer years
      • codeTired 3y ago
        I never said I didn’t grind or I won’t grind to move up. It doesn’t change my opinion.
      • harryquach 3y ago
        To be fair grinding Leetcode to the point of proficiency takes longer than a week. With that said I agree on your other point, putting in the work and sacrificing time, even months, will pay dividends long-term with a salary that allows someone to retire early.
        • wishpishh 3y ago
• tzs 3y ago
  He's on the right track, except instead of ditching LeetCode use it as a source of code to review. I think many people overlook that each LeetCode problem has an associated forum where people discuss the problem and post solutions. Here's what I'm going to try if I ever again have to conduct interviews. 1. I'll present the candidate with a LeetCode problem (or let them pick from a list), after emphasizing that I'm not going to be asking them to actually solve it. 2. After they read it we'll discuss it, starting with the problem statement and examples, until we are both sure we think we know what the problem is actually asking. We'll also talk about any edge cases we anticipate might give us problems. 3. We'll talk about possible approaches to the problem. 4. After we have come up with some approach that with sufficient hand waving could convince someone that we could actually right a solution, we'd go the forum for the problem and start looking at the solutions people have posted. 5. For some of those solutions we'll try to figure out if they would work, if they handle the edge cases, spot bugs, see if they are well organized, talk about how well they appear to be written, and stuff like that.
  • pedrosorio 3y ago
    > For some of those solutions we'll try to figure out if they would work, if they handle the edge cases, spot bugs Most of the solutions will have been posted after submitting to the platform and passing hundreds of test cases, so you'd have to pick a very specific problem and solution to find any bugs/not handling edge cases.
• krupan 3y ago
  My favorite interviews are when they give me some code to read and understand, and then either test or fix bugs or add a feature to. That is what we all spend bulk of our time doing and so it makes sense to make that the "technical challenge" part of the interview
• m0llusk 3y ago
  The big deal here is that it allows for relevance. Skilled coders don't want to waste time with exercises. They come up with useful tools and side projects and contribute to open source. Leetcode is a distraction because it is relevant only as an exercise, not as something truly useful. And that is the biggest test of a coder. Not that they can code something, but that they can apply the ability to code to real problems and address something relevant. Code that really matters has traction. Sometimes it is a very simple thing that makes a tool or application or library truly useful, and the skill to see that and apply such knowledge goes far above some leetcode exercise that has no real application and serves only for points in some game.
• a13o 3y ago
  I think a company with a mature code review culture wouldn't be able to benefit much from this kind of interview. The candidate wouldn't have to figure out what the code does, because there would be a PR description and/or walkthrough video explaining the code. There wouldn't be any bugs to find, because code reviews aren't a great way to find bugs. The bugs are found by automated and manual tests. There would be no stylistic feedback to give. The linter already enforced everything enforceable, leaving only things that are a waste of time to fight about. There's no point in giving architectural feedback, as the architecture was already socialized and agreed upon before the code was written. Now on to what code reviews are good for. The changeset is probably a small piece of a bigger picture, because the code is being shipped incrementally. The candidate has no comprehension of the bigger picture to weigh in on downstream issues. The candidate has no broader understanding of the codebase in general, to suggest reusing an existing pattern, or avoiding a common pitfall with a private API. The candidate can be well-versed in the OSS framework, and suggest better ways to write some particular boilerplate, or avoid a framework pitfall. I fear an interview structured like this says more about the company than the candidate. If your company's development lifecycle is mature, there's not much a candidate can weigh in on. The most useful case that jumps out to me is gaining an understanding of the candidate's familiarity with a framework. A contrived diff falling into lots of common pitfalls could cover more ground than having them write something in the framework. But having them write something in the framework shows you a lot more than just their awareness of pitfalls, so I'm not convinced this is better still.
• mjohn 3y ago
  I've never tried it, but in the age of AI why not ask candidates to interact with ChatGPT to solve a problem? In my (limited) interviewing experience the good candidates were the ones who had a good mental model for solving novel problems, were inquisitive and asked good questions. I think these attributes are also a reasonable indicator of general intelligence. The people who I hired that were less successful were the ones who solved the coding exercises but had a poor mental model of how to solve novel problems and did not ask good questions. Trying to use ChatGPT could take the pressure off from regurgiating coding minutae. The interviewer would be able to observe how the candidate approaches the problem and whether they can spot where ChatGPT goes wrong. It might also help introverted candidates since it feels less confrontational and there is likely to be less anxiety about unimportant details (after all any syntax mistakes would be ChatGPT's mistakes).
  • kweingar 3y ago
    Could candidates opt out of using ChatGPT? I don’t think I’d be comfortable using it in an interview.
    • mjohn 3y ago
      Sure, why not, I'm just thinking out loud to be honest and am probably biased towards feeling quite comfortable using something like ChatGPT. I don't ask ChatGPT to write code for me but regularly use it to explore, a bit like a rubber duck that talks back. Just curious - why would you not feel comfortable using it in an interview? Interesting to hear a different POV.
      • kweingar 3y ago
        It’s a little overwhelming given the time constraints. I don’t know how I would fare trying to juggle a conversation with the interviewer, a conversation with ChatGPT, and typing into a code editor all at the same time, especially when ChatGPT usage involves vetting the output for hallucinations or misunderstandings. A search engine would be much quicker and easier for me to use.
• mochomocha 3y ago
  Be the change you want to see in the world. I refuse to interview at places that are Leetcode-heavy. Never prevented me from getting 7 figures offers at FAANG-type companies. Similarly when I interview candidates, I don't ask them Leetcode questions either. I like to get a sense of whether or not a candidate can reason in semi-unknown territories and has good intuition, not if they can parrot a textbook.
  • farhanhubble 3y ago
    Same boat. I've interviewed hundreds of engineers, using thirty minute code review kind of setup, who have proved damn good in the depth of their knowledge.
  • OnionBlender 3y ago
    What are some FAANG-type companies that don't ask Leetcode-heavy questions?
  • burkaman 3y ago
    7 figures? I appreciate your stance, but if you're getting million dollar offers I'm not sure your advice is relevant to most of us. It's like a movie star saying "why bother auditioning, just wait for a director to request you specifically".
  • oofta-boofta 3y ago
    [dead]
  • neilv 3y ago
    You can't just leave that hanging there. What "FAANG-type" companies are making 7-figure offers to anyone on HN, without a Leetcode fratbro hazing?
  • dane_jordan 3y ago
    I sense some dissonance here: "I interview at FAANG companies and refuse to interview at FAANG companies"
• indymike 3y ago
  We use this process, and it has helped us hire some great developers without having to use third party staffing and headhunters: 1. Post well written job post on major job boards. 2. Immediately reply via text to every applicant (yes, we have opt in on the application) 3. Initial screening including several knock-out questions via text. Immediately let candidate know if they are not selected and why. 4. 30 minute can you write a working function from requirements code test. Allow one re-try. Immediately let candidate know if they are not selected and why. 5. Interview and code review session. Bring a side project, show us how it works. 6. Offers out. 7. Background checks start in parallel with on-boarding. First week is spent with business unit teams to learn what the company actually, really does. 8. End of first week, we occasionally have to let someone go on background issues. Otherwise, week 2 is first week coding, expect a working pull request by end of week. All candidates informed position is filled, ask if they would like to be alerted if similar job opens. Works like a champ. Helps we write software that does this. Average developer tenure is two years, company is three years old. We write telecom software that does texting, voice and video interviews.
  • bobobob420 3y ago
    "Bring a side project, show us how it works." Can people in the industry stop this please? You have to be mentally sick to ask people to code review their side projects. It doesn't make any sense. "Average developer tenure is two years, company is three years old." Got it. I don't think this statement says what you think it does.
    • lmarcos 3y ago
      Agree. Interviews taken into account side projects are biased towards: - people who have free time to work on side projects (usually young people have more free time than people with families) - people who don't mind sharing their code with others - people who work on interesting side projects. If your side project is boring, that will probably bore your interviewers -> no offer - people who work on side projects on regular basis. If I get to work on one side project every year, well, chances are I may have forgotten the hell I did on that project (depending when the interview takes place). If I work on side projects constantly, I have no trouble picking up a fresh one to talk about
• commandlinefan 3y ago
  > For hard problems, I may go for a walk, talk to a co-worker, research algorithms, build small toy codebases first Everything about the JIRA/timetracking/project management regime is expressly designed to prohibit that - you're a programmer, program! Faster! Know the answer RIGHT NOW!
• bobobob420 3y ago
  I just ask an eoasy coding question and sometimes push it a bit, its really not that hard. Anyways most of the time diving deep into someones resume and asking them genuine questions about what they would d in certain technical situations or about the technical skills they have listed is enough.
• deleted 3y ago
  [deleted]
• pie_flavor 3y ago
  The best coding interview puzzle I've ever done involved a (fictional) thrice-cursed data-management system with inaccurate documentation and a couple nasty traps. Instructed to collaborate with the interviewer as if they were a coworker, you had to adapt another piece of software to this system so that they could migrate it. I was awestruck by how many ways it tested your real competence at the actual day-to-day of the job.
• qkeast 3y ago
  I've done something similar for product designer interviews in past roles and at my current company: rather than any variation of take-home or design challenge (which are unethical and unhelpful), we ask candidates to do a design critique with us centred around a third-party product of their choice. It gives us great signals into the things we care about in designers: communication skills, design and product thinking, their mindsets and approaches to thinking about and evaluating products and design, and even their craft.
• MPSimmons 3y ago
  I consider myself a mediocre, if competent, programmer. I would like to improve my level of code reviews, but I'm on an operations team and I'm pretty much the only person who programs (it's a small company for now, but if we're successful, we'll grow pretty dramatically over the next few years). What tips would you have for doing this?
  • daotoad 3y ago
    It's essentially the same advice given to writers. Read a lot and write a lot. If you can get access to review work by folks on other teams that do more coding, that would be a good start. From there, you need to allocate time to looking at changes closely. Don't just accept things at face value. Ask basic questions like "why is that there?" and "what does that really mean?" and hunt the answers down. Code consistency can mean many things, formatting and variable casing are the obvious things, but also things like how method names are constructed (e.g. when do you use "get" vs "fetch" as a prefix), are concepts named consistently (is "business hours" always spelled "business hours" adjusted for casing or is it called things like "hours" or "biz hrs" in some places. I look for three big things: * technical soundness - does the code do what it says it does? * ontological soundness - are the concepts used well defined with clear boundaries and do they play well with the conceptual framework of the rest of the application? * semantic soundness - is the meaning evident? does the code do what you'd expect? How hard is it to reason about what the code does when it is called? I view writing code as a primarily communicative activity. So, I evaluate it based on how well the ideas it embodies are structured and how well it communicates those ideas.
    • MPSimmons 3y ago
      This seems like really good advice. Thank you for taking the time to write this o ut!
• gregdustin57 3y ago
  [dead]
• n4r9 3y ago
  > Bug hunter > Intentionally introduce some logical flaw or defect and see if a candidate can spot it. A good idea is to go back and find recent bugs that were solved and pull the source before the fix was applied. Can the candidate identify the root cause? How would the candidate suggest resolving the defect? I've had this exact idea on the back-burner for years! https://news.ycombinator.com/item?id=18794465 https://news.ycombinator.com/item?id=18794465 The example bug that gave me the idea initially is this one I reported on the "Satsuma Graph" dotnet package: https://sourceforge.net/p/satsumagraph/tickets/2/ https://sourceforge.net/p/satsumagraph/tickets/2/ Very keen to hear from anyone that has experience with this, from either side of the interview fence.
  • mcronce 3y ago
    I had a bug hunt as part of an interview once (or, I should say, once that I remember). It was different from that proposal in that the code was not part of the company's actual codebase - it was entirely fabricated for the test. It was fun, though; I enjoyed that more than livecoding and live-whiteboarding.
    • shaftway 3y ago
      I had one that wasn't fabricated when I worked at Strip. There was an old bug in the requests library for Python where it was sending wrong data when posting a stream and the response had to be retried. The bug had already been fixed upstream. We cloned a repo, ran they tests, it failed, and the task was to identify why it failed. It was a tough process for me, since I've never really used Python debugging tools, so I actually had to learn during the interview, but I was able to reason well and picked things up quickly enough that I found the cause, and we had time to discuss ways it could have been fixed. It was different. I do well during Leetcode questions, so stepping out of that framework was uncomfortable and stressful. I got an offer, but I felt like it was closer than it should have been.
      • n4r9 3y ago
        Thanks for relating your experience. I'm sorry to hear that it was uncomfortable and stressful, but it sounds like you must have reacted pretty well in those circumstances to get an offer. Do you feel like the skills assessed by the interview were reflective of what you ended up doing on the job (assuming you accepted) ?
• jmull 3y ago
  Let’s break down the problem: * hiring is a very high-stakes decision * the normal interviewing process has no hope of directly measuring a candidate’s fitness for a particular position. There simply is not enough time. You’d want to evaluate the candidate over maybe a couple weeks of full time work, which, of course, a large number of candidates aren’t willing to do. * So you have to use the limited time you have to get as much information as possible and accept that direct knowledge really just cannot be obtained. The idea of leetcode exercises is that someone capable of the analytical problem solving skills and determination necessary to do well at those puzzles will also be capable enough to handle the harder parts of software development jobs. It’s an imperfect approximation, but for a problem where there is no closed-form solution, it could be one of the better of a number of poor options. (That’s the idea anyway, I don’t know if it’s true.) All that said, I think a code review is a good idea. Maybe do a couple leetcode puzzles and a code review (and a design discussion, and a “explain a recent project of yours to me” discussion, etc)
• mock-possum 3y ago
  I interviewed for a place earlier this year that had the best process I’d ever seen - they paid me to come in and pair program with their team for half a day, then took me out for lunch to chat with the CEO and CTO. It was nice! I probably should have taken that job offer. It was hybrid, not remote, and the pay and benefits were a little lacking compared to my other options - but in retrospect, they might have been a better fit than where I ended up.
• Nellyz 3y ago
  [dead]
• robertnicholas 3y ago
  [dead]
• wly_cdgr 3y ago
  You misunderstand, interviews are about gatekeeping, not about demonstrating relevant competence
  • mardifoufs 3y ago
    And what would be the purpose of said 'gatekeeping' (that word really lost its meaning)? I'm pretty sure the intention is to filter out bad candidates, so if that's gatekeeping well... I guess hiring is inherently about gatekeeping Not saying the method works, but I think it's weird to argue that it isn't at least an attempt at having good candidates.
• swingingFlyFish 3y ago
  I can't tell you how sick I am of doing technicals anymore for a job. If you can't tell from us talking shop and my resume and your due diligence i probably don't want to work with or for you. The arrogance most software "engineers" have is astounding. 99% of companies aren't splitting the atom. Companies shoot themselves in the foot and waste so much talent this way.