10 ms·
The last time I've used a leet code style interview was in 2012, and it resulted in a bad hire (who just happened to have trained on the questions we used). I'v
by fhd2 2y ago
The last time I've used a leet code style interview was in 2012, and it resulted in a bad hire (who just happened to have trained on the questions we used). I've hired something like 150 developers so far, and what I ended up with after a few years of trial and error:
1. Use recruiters and network: Wading through the sheer volume of applications was even nasty before COVID, I don't even want to imagine what it's like now. A good recruiter or a recommendation can save a lot of time.
2. Do either no take home test, or one that takes at most two hours. I do discuss the solution candidates came up with, so as long as they can demonstrate they know what they did there, I don't care too much how they did it. If I do this part, it's just to establish some base line competency.
3. Put the candidate at ease - nervous people don't interview well, another problem with non-trivial tasks in technical interviews. I rarely do any live coding, if I do, it's pairing and for management roles, to e.g. probe how they manage disagreement and such. But for developers, they mostly shine when not under pressure, I try to see that side of them.
4. Talk through past and current challenges, technical and otherwise. This is by far the most powerful part of the interview IMHO. Had a bad manager? Cool, what did you do about it? I'm not looking for them having resolved whatever issue we talk about, I'm trying to understand who they are and how they'd fit into the team.
I've been using this process for almost a decade now, and currently don't think I need to change anything about it with respect to LLMs.
I kinda wish it was more merit based, but I haven't found a way to do that well yet. Maybe it's me, or maybe it's just not feasible. The work I tend to be involved in seems way too multi faceted to have a single standard test that will seriously predict how well a candidate will do on the job. My workaround is to rely on intuition for the most part.
- fhd2 2y agoTo add: I can very well imagine this process isn't suitable for FAANG, so I can understand their university exam style approach to a degree. It's easy to arm chair criticise, but I don't know if I could come up with something better at their scale. These days, I'm mostly engaged by startups to help them build an initial team, I acknowledge that's different from what a lot of other folks hire for.
- mnky9800n 2y agoIs your job consulting for hiring technical positions?
- fhd2 2y agoI have a consultancy - we mostly do development, but I also do quite a bit of "consulting CTO" work. Quite often, that means helping with hiring. But hiring is nowhere near my full time job, thankfully :D
- mnky9800n 2y agoThat’s cool. My main job is being a research scientist but i also work at a computational science consultancy that essentially builds numerical simulations for hire along with other software consultancy jobs. I occasionally have been asked to serve as an outside consultant for hiring data science positions. I’ve been wondering how to grow that a bit into more regular work because I enjoy it. Any thoughts on that?
- fhd2 2y agoWell, my contracts pretty much all came through my network, someone recommending me, and then clients recommending me, and so on. Not sure if I just got lucky or if this actually works, but my first step would be to tell some relevant folks you know that you're doing this now, see if they have any advice or know someone who might be interested. Another approach would be to ask the consultancy you work with if they want to add this service you can provide to their portfolio, see if it's something they could sell to existing or new clients. However, these days, people seem barely OK with paying for a recruiter. They think just because more people than usually are looking, they get to just lean back and great candidates show up. IMHO, if anything, it got more difficult to hire. More noise to work through, people in existing roles are more reluctant to switch, candidates hustle more because they need a job etc. I absolutely think it's a useful service. But I don't know if it's easy to market.
- adastra22 2y ago
- kamaal 2y ago>>Do either no take home test, or one that takes at most two hours. I do discuss the solution candidates came up with, so as long as they can demonstrate they know what they did there, I don't care too much how they did it. If I do this part, it's just to establish some base line competency. The biggest problem with the take home tests are not people who don't show up due to not being able to finish the assignment, But that those people who do, now expect to get hired. 95% people don't finish the assignment. 5% do. Teams think submitting the assignment with 100% feature set, unit test cases, onsite code review and onsite additional feature implementation still shouldn't mean a hire(If not anything, there are just not enough positions to fill). From the candidate's perspective, its pointless to spend a week working and doing every thing the hiring team asked for and still receive a 'no'. I think if you are not ready to pay 2x - 5x market comp you shouldn't use take home assignments to hire people. There is too much work to do, and receive a reject at the end. Upping the comp absolutely makes sense as working a week to get a chance at earning 3x more or so makes sense.
- Fr3dd1 2y agoWe did a lot of these assignments and no one assumed that they will be hired if they complete it. Its about how you communicate your intent. I always told the candidates, that the goal of the task is 1. to see some code and if some really basic stuff is on point and 2. that you can argue with someone about his or her code.
- kamaal 2y ago>>We did a lot of these assignments and no one assumed that they will be hired if they complete it. Its about how you communicate your intent. Be upfront that finishing the assignment doesn't guarantee a hire and very likely the very people you want to hire won't show up. Please note that as much as you want good people to participate in your processes. Most good talent doesn't like to waste its time and effort. How would you feel if someone wasted your time and effort?
- Fr3dd1 2y agoI am in germany, so by far not the same situation as in other areas of the world. If I would get such an assignment myself and I have the feeling that this will help the company and also me to verify, if it is a fit, I will do that 1 to 3 hour task very happily.
- Stratoscope 2y agoWhen I was interviewing candidates at IBM, I came up with a process I was really happy with. It started with a coding challenge involving several public APIs, in fact the same coding challenge that was given to me when I interviewed there. What I added: 1. Instead of asking "do you have any questions for me?" at the very end, we started with that general discussion. 2. A few days ahead, I emailed the candidate the problem and said they are welcome to do it as a take home problem or we could work on it together. I let them know that if they did it ahead of time, we would do a code review and I would ask them about their design and coding choices. Or if they wanted to work on it together, they should consider it a pair programming session where I would be their colleague and advisor. Not some adversarial thing! 3. This the innovation I am proud of: a segment at the beginning of the interview called "teach me something". In my email I asked the candidate to think of something they would like to teach me about. I encouraged them to pick a topic unrelated to our work, or it could be programming related if they preferred that. Candidates taught me things like: • How to choose colors of paint to mix that will get the shade you want. • How someone who is bilingual thinks about different topics in their different languages. • How the paper bill handler in an ATM works. • How to cook pork belly in an air fryer without the skin flying off (the trick is punching holes in the skin with toothpicks). I listed these in more recent emails as examples of fun topics to teach me about. And I mentioned that if I were asked this question, I might talk about how to tune a harmonica, and why a harmonica player would want to do that This was fun for me and the candidate. It helped put them at ease by letting them shine as the expert in some area they had a special interest in.
- asalahli 2y agoLove the 3rd point! I might start using that in my future interviews
- Stratoscope 2y agoPlease report back when you do! I don't remember how I came up with the idea. Maybe I just like learning things. One candidate even wrote after their interview, "that was fun!" Have you ever had a candidate say that? This was the moment when I realized I might be on to something. :-) Interviews are too often an adversarial thing: "Are you good enough for us?" But the real question is would we enjoy working together and build great things! People talk about "signal" in an interview. Someone who has an interest they are passionate and curious about and likes to share it with others? That's a pretty strong signal to me. Even if it has nothing to do with "coding".
- axegon_ 2y agoI feel like take home tests are meaningless and I always have. Even more so now with LLMs, though 9/10 times you can tell if it's an LLM-people don't normally put trivial comments in the code such as > // This line prevents X from happening I've seen a number of those. The issue here is that you've already wasted a lot of time with a candidate. So being firmly against take home tests or even leetcode, I think the only viable option is a face to face interview with a mixture of general CS questions(i.e. what is a hashmap, benefits and drawbacks, what is a readers-writer lock, etc) and some domain specific questions: "You have X scenario(insert details here), which causes a race condition, how do you solve it."
- throwaway2037 2y ago> I feel like take home tests are meaningless and I always have. Even more so now with LLMs This has been discussed many times already here. You need to set an "LLM trap" (like an SSH honey trap) by asking the candidate to explain the code they wrote. Also, you can wait until the code review to ask them how they would unit test the code. Most cheaters will fall apart in the first 60 seconds. It is such an obvious tell. And if they used an LLM, but they can very well explain the code, well, then, they will be a good programmer on your team, where an LLM is simply one more tool in their arsenal. I am starting to think that we need two types of technical interview questions: Old school (no LLMs allowed) vs new school (LLMs strongly encouraged). Someone under 25 (30?) is probably already making great use of LLMs to teach themselves new things about programming. This reminds me of when young people (late 2000s/early 2010s) began to move away from "O'Reilly-class" (heh, like a naval destroyer class) 500 page printed technical books to reading technical blogs. At first, I was suspicious -- essentially, I was gatekeeping on the blog writers. Over time, I came to appreciate that technical learning was changing. I see the same with LLMs. And don't worry about the shitty programmers who try to skate by only using LLMs. Their true colours will show very quickly. Can I ask a dumb question? What are some drawbacks of using a hash map? Honestly, I am nearly neck-bearded at this point, and I would be surprised by this question in an interview. Mostly, people ask how do they work (impl details, etc.) and what are some benefits over using linear (non-binary) search in an array.
- 2y ago
- vanceism7_ 2y agoWow, that was a great write up. Can I interview with you? Lol, everything you wrote was really spot on with my own interview experiences. I tend to get super nervous during interviews and have choked up on many interviews asking for live coding on crazy algorithm problems. It state of hiring seems to be really bad right now. But I'll take your advice and try to get in contact with some recruiters
- throwaway2037 2y ago> Put the candidate at ease - nervous people don't interview well This is great advice. I have great success with it. I give the same 60 second speech at the start of each interview. I tell candidates that I realise that tech interviews are stressful -- "In 202X, the 'tech universe' is infinitely wide and deep. We can always find something that you don't know. If you don't have experience in a topic that we raise, let us know. We will move to a new topic. All, yes, all people that we interviewed had at least one topic where they had no experience, or none recent." Also, it helps to do "interview ramp-up", where you start with some very quick wins to build up confidence with the candidate. It is OK to tell them "I will push a bit harder here" so they know you are not being a jerk... only trying to dig deeper on their knowledge.
- dmoy 2y agoPutting candidate at ease is definitely important. Another reason: If you're only say one of four interviewers, and you're maybe not the last interviewer, you really want the candidate to come out of your interview feeling like they did well or at least ok enough, so that they don't get tilted for the next interview. Because even if they did really poorly in your interview, maybe it's a fluke and they won't fail the rest of the loop. Which is then a really difficult skill as an interviewer - how do you make sure someone thinks they do well even if they do very poorly? Ain't easy if there's any technical guts in the interview. I sure as shit didn't get any good at that until I'd conducted like 100+ interviews, but maybe I'm just a slow learner haha
- biztos 2y agoAs someone with a pretty long career already, and who's comfortable talking about it, I was a bit surprised that in three interviews last year nobody asked a single thing about any of my previous work. One was live coding and tech trivia, the other two were extensive take-home challenges. To their credit, I think they would have hired "the old guy" if I'd aced their take-homes, but I was a bit rusty and not super thrilled about their problem areas anyway so we didn't get that far. And honestly it seems like a decent system for hiring well-paid cogs in your well-oiled machine for the short term. Your method sounds like what we were trying to do ten years ago, and it worked pretty well until our pipeline dried up. I wish you, and your candidates, continued success with it: a little humanity goes a long way these days.
- palerdot 2y agoSo, did you find a company that you are happy with (interviewing or otherwise)? I would be really interested to know how you are dealing with tech landscape changes lately, and your plans for staying in tech ... Wishing you all the best for your career!
- jkaplowitz 2y agoHow does that process handle people who have been out of work for a few years and can pass a take-home technical challenge (without a LLM) but cannot remember a convincing level of detail on the specifics of their past work? I’ve been experiencing your style of interview a lot and running up against this obstacle, even though I genuinely did the work I’m claiming to have done. Especially people with ADHD don’t remember details as long as others, even though ADHD does not make someone a bad hire in this industry (and many successful tech workers have it). I do prefer take-home challenges to live coding interviews right now, or at least a not-rushed live coding interview with some approximate advance warning of what to expect. That gives me time to refresh my rust (no programming language pun intended) or ramp up on whichever technologies are necessary for the challenge, and then to complete the challenge well even if taking more time than someone who is currently fresh with the perfectly matched skills might need. I want the ability to show what I can do on the job after onboarding, not what I can do while struggling with long-term unemployment, immigration, financial, and family health concerns. (My fault for marrying a foreigner and trying to legally bring her into the US, apparently.) And, no, my life circumstances do not make it easy for me to follow the common suggestion of ramping up in my “spare time” without the pressures of a job or a specific interview task. That’s completely different from when I can do on the job or for a specific interview’s technical challenge.
- fhd2 2y agoI can't say I've interviewed someone to which this applies - unfortunately! Probably just doesn't get surfaced by my channels. I would definitely not expect someone out of work for a while to have any meaningful side projects. I mean, if they do, that's cool, but I bet the sheer stress of not having a job kills a lot of creativity and productivity. Haven't been there, so I can only imagine. For such a candidate, I'd probably want to offer them a time limited freelance gig rather quickly, so I can just see what they work like. For people who are already in a job, it's more important to ensure fit before they quit there, but your scenario opens the door to not putting that much pressure on the interview process.
- jkaplowitz 2y agoThanks for being understanding and compassionate about the situation! I like your idea of a time limited freelance gig, though immigration obstacles do sometimes make that quite complicated (as in my current situation). It's way better than not considering that people might have a reason for a resume with gaps or other irregularities which is not being a bad employee. Beyond immigration types of obstacles, somehow recruiters and hiring managers rarely consider how many bad managers, bad executives, and bad companies there are when evaluating gaps and short tenures in an employee's resume. But equally, discussing those matters during an interview risks being seen as unprofessional and unreasonably negative. "Why did you leave this company?" "Oh, the warnings I got about the leadership from a former employee before I joined turned out to be true, and they didn't want to hear professionally presented necessary feedback about emotional safety in an emergency incident response situation, so they fired me without a single meaningful 1:1 discussion other than trying to assign blame." / "Oh, the CEO was enough of a problem that the investors eventually replaced him in a subsequent funding round despite him being the majority shareholder, but that was long after I had resigned or been fired due to that CEO's particular problems." / "Oh, they communicated in a very idiosyncratic way which didn't work for me and which I haven't seen at any company before or since." / etc. Most of that doesn't fly in an interview, but equally, even if it did, saying too much of that sounds like making up excuses for oneself even when it's 100% true. Same thing for why a job search doesn't succeed quickly. Ours is a messy and imperfect industry, and it sucks that interview candidates have to pretend otherwise to seem like they'll be reasonable employees. Meanwhile the companies and executives that act in those ways get to present whatever positive and successful image they want, and they get to praise each other for firing fast or cutting costs with attrition or layoffs.
- joshvm 2y agoI’ve done the “at home” test for ML recently for a small AI consulting firm. It's a nice approach and got me to the next round, but the way the company evaluated it was to go through the questions and ask "fundamental ML bingo" questions. I don't think I had a single discussion about the company in the entire interview process. I was told up front "we probably won't get to the third question because it will take time to discuss theory for the first two". If you're a company that does this, please dog food your problems and make sure the interview makes the effort feel valued. It also smells weird if you claim it's representative of a typical engineering discussion. We all know that consultancy is wrangling data, bad data and really bad data. If you're arguing over what optimiser we're choosing I'd say there's better ways to waste your customer's money. On the other hand I like leetcode interviews. They're a nice equalizer and I do think getting good at them improves your coding skill. The point is to not ask ludicrously obscure hard problems that need tricks. I like the screen share + remote IDE. We used Code which was nice and they even had tests integrated so there wasn't the whiteboard pressure to get everything right in your head. You also know instantly if your solution works and it's a nice confidence if you get it first try, plus you can see how candidates would actually debug, etc.
- neilv 2y ago> 2. Do either no take home test, or one that takes at most two hours. I do discuss the solution candidates came up with, so as long as they can demonstrate they know what they did there, I don't care too much how they did it. If I do this part, it's just to establish some base line competency. You need to do this to establish some baseline competency... for junior hires with no track record?
- silverlake 2y agoIf they pass step 2, the first technical interview is to extend the solution to add/modify features.
- giantg2 2y ago"Use recruiters and network: " Recruiters have been notoriously bad in my experience. Relying on network has the potential to create bias and avoid good candidates that simply don't have an "in".
- coldtrait 2y agoAre you hiring now?
- hnlurker22 2y agoI would never show an interviewer how I code. Let alone allow them to give me 2 hours to solve a problem. It's contradicting that you know that developers "mostly shine when not under pressure", yet you set 2 hours to solve a problem (Sounds like you don't want to pay them for the take home). The positive feedback you're getting for your flawed process just shows how worse other, more common, recruiters are.