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 happy to work with them and advise them just as I would with any colleague. 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 encouraged the candidate to teach me something unrelated to our work, or 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 my email 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.
I can't fathom how making the whole process being all hostile makes any real sense!
We all want that great person to show up and really help, not just cope or put up a facade to survive.
Yet, that is exactly what happens. People that other people expect to bond with get put through the wringer....
Seems counterproductive to me.
Agreed. I have been through technical interviews where at the end, my feeling as a candidate was "I don't want to work with this asshole".
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".
And I'm sure you're going to get different questions about different aspects of the things you're trying to teach from different interviewers. The wonderful thing about this is that it models trying to teach a concept to a fellow coworker. How you handle the questions during the teaching time says a lot about the candidate.
Or would it train people to choose topics very carefully, such that a little teaching skill goes a long way?
It's not like the interviewer getting a lesson in tuning a harmonica is going to bust out a harmonica and start putting his newfound knowledge to work, or revisit the subject in 6 months to see if he's retained the knowledge, or bring in a panel of harmonica tuning experts to check there weren't any major gaps or mistakes in the lesson.
If someone didn't want to do it, that's fine and wouldn't be held against them. In practice, I think one person out of 20 chose not to do it.
And if they weren't a great teacher, that was fine too!
The purpose of the segment is to give the candidate a chance, if they want, to shine at something they are interested in, and help put them at ease by letting them start out being the expert.
And then when they were teaching me, I made sure to pay attention, ask questions about anything I didn't understand - not to judge their teaching skills but to show I was interested and listening.
What if I decide to teach you something about the Quran and you don't hire me?
Perhaps this is just urban legend but from the stories I've heard hiring for FAANG-type companies there are people out there interviewing with their only goal being baiting you into a topic they can sue you over.
Worst instance I have heard of is when an interviewer asked about the books the candidate liked to read (since the candidate said they're an avid reader in their resume) and he just said that he liked to read the Bible. After not getting hired for failing the interviews he accused the company of religious discrimination.
I'm by no means an expert in US law and don't know the people this happened to directly so maybe it's just one big fantasy story but it doesn't seem that far fetched that
- If you are a rich corporation then people will look to bait you into a lawsuit
- If you give software engineers (or any non-lawyers) free rein on how to conduct interviews then some of them can be baited into a situation that the company could be sued over way more easily than a rigid leetcode interview
I think nothing came of the fellow who liked reading the Bible but I would imagine the legal department has a say in what kind of interview process a rich company can and can not use.
There is literally no way to prevent a candidate from disclosing a protected characteristic during an interview. Some obvious examples: they might show up to the interview in a wheelchair, they might be wearing a religious garment, they might be visibly pregnant, and so on...
What legal doesn't want, is you asking questions directly intended to elicit that kind information when the candidate didn't volunteer it. Asking the candidate a direct question like "are you planning to have kids?" makes it sound like that information will be used in the hiring decision.
As you can see from the examples I gave, what they taught me was completely up to them.
It was just a fun exercise that I and every candidate enjoyed.
Forgive me, but I just don't see the problem here.
If you did decide to teach you something about the Quran, that would be great!
I don't know enough about these holy books, and I always welcome a chance to learn more.
There is no problem. But some people will create problems out of thin air, when there is none.
Completely unrelated, but I find that other people will create problems by making an off-colour statement, something mildly offensive, or disrespectful and then when they get a reaction they say "why are you making a problem where none exists".
DARVO/gaslighting behaviour, and I wish it was rarer than it is.
Secondly, share that place by example. Radiating non fear can do wonders for the people around us, as can honest and frank conversation.
When all members of a team, or even small companies come to understand not all environments are about blame and shame, magic happens!
Don't have anything else to add, but that I agree with you.
It's somewhat overblown - obviously anyone can try to submit a demand letter about anything. My experience with legal in the hiring process is they want to avoid obvious own goals, and document the process so that clear reasoning can be expressed. Then, unless you really do something obviously discriminatory, you can tell people who claim they've been discriminated against to go pound sand.
There are lots of good tactical reasons to settle claims like that, so lawyers may advise you to settle, but if you're of the "we don't negotiate" mindset, in my experience most lawyers are quite happy to gear up for a fight with the right groundwork in place.
Simple, don't pick subjects, such as religion, sexuality, etc. It's not that deep.
a candidate that pulls the religious thing now is one that's going to drag their crazy shit into the office later. or complete misread the room / culture now, and in the future.
like it's a technical job interview, talk about something vague technical, even if it's just how the convection settings work in your oven.
You just need a small file, like a point file. Any gasheads remember those? And a single edge razor blade or the like to lift the reed.
To raise the pitch, you file the end of the reed, making it lighter so it vibrates faster.
To lower the pitch, you file near the attached end of the reed. I am not sure on the physics of this and would appreciate anyone's insight.
The specific tuning I've done many times is to convert a standard diatonic harp (the Richter tuning) to what is now called the Melody Maker tuning.
The Richter tuning was apparently designed for "campfire songs". You could just "blow, man, blow" and all the chords would sound OK.
Later, blues musicians discovered that you could emphasize the draw notes, the ones that are easy to bend to a flat note to get that bluesy sound. This is called "cross harp". For example, in a song in G you would use a C harp instead of one tuned in G.
The problem with cross harp is that the 7th is a minor 7th and you have no way to raise it up to a major 7th if that would fit your song. And the 2nd is completely missing! In fact you just have the tonic (G in this case) on both the draw and blow notes where you might hope to hit the 2nd (A). There is no A in this scale, only the G twice.
To imagine a song where this may be a problem, think of the first three notes of the Beatles song All My Loving. It starts with 3-2-1. Oops, I ain't got the 2. Just the 1 twice.
This is where the file comes in. You raise the blow 1st to a major 2nd. And you raise the minor 7th to a major 7th in both octaves.
Now you have a harp with that bluesy sound we all love, but in a major scale!
It's pretty clear why that's the opposite of filing off material close to the tip, so obviously the tone goes lower.
In my mental image, filing close to the base of the reed gives the reed a similar shape as putting extra material next to the tip (thinner at the base, thicker next to the tip), and that's why it behaves the same.
The solder on the tips reminds me of a doctor visit years ago. I thought I may have broken a finger, and when I got to the doctor's office I mentioned to the receptionist that I had a high-deductible (HSA-compatible) insurance plan.
The physician's assistant said, "We could send you over for an X-ray, but since you're paying out of pocket, we can start with a simple test." He pulled a contraption out of his desk drawer and asked, "Do you know what this is?"
I said, "Yeah, a tuning fork. And based on the size and those heavy weights on the tips, it must be tuned to a rather low frequency."
It looked like this one:
https://www.stethoscope.com/adc-tuning-fork-128hz-500128/
He said, "Yep. So we get it vibrating and then touch the base to your finger. If you have a fracture, it will hurt because of the broken bone ends jiggling against each other. Then we will go for the X-ray to get more details. If it doesn't hurt, you are good to go. Is that OK?"
"Sounds good to me!"
It didn't hurt at all, and I just had to pay for a simple office visit instead of an expensive X-ray.
Once we are there, it then is all about techniques. Working from first principles is going to get us there, but there are likely pitfalls, traps, all manner of gotchas laying in wait...
And there we now have a basis for further discussion.
https://chatgpt.com/share/67a2aade-5870-8012-b211-1bd749a2d7...
The opening question is a copy of what was done before (probably by someone who doenst work at IBM anymore) and all the new stuff is stolen from outsiders.
I am tempted to take some offense at your comment. But I have to assume that you mean well.
You are correct that I don't work for IBM any more. What does that have to do with anything?
Thanks for sharing.
My take is the negatives may just be people leaning hard on, "if it seems too good to be true...
I don't know that many programmer/developer jobs where you can just put your headphones on and code without ever talking to another person.
Being able to explain/teach your work is part of "doing the job well" for a developer (IMO).
... Classic interviewing techniques of "explain how X algo works" or "write code to solve Y" will unfairly bias against interviewees that don't test well under pressure, but would otherwise be a good coworker.
... "Teach me something interesting to you" or "tell me stories about past experiences" will unfairly bias against interviewees that are shy, soft spoken, or are mildly socially awkward, but would otherwise be a good coworker.
Given the above awareness of where bias can emerge, how should the interview be done in order to get a candidate that knows what they're doing, and works well with the rest of the team?
Other comments mention relying more on recruiters and referrals, but that isn't always an option.
It takes time, money and people to bring someone in, and hiring is actually quite a risk for many companies (unless they're huge and/or in a hiring frenzy).
If a candidate doesn't work out, that's a lot of time and money down the drain, and potentially lost work, and disruption to teams and timelines, etc..
Most people don't get this part, and I think that's why they don't understand why interview processes are structured the way they are.
You really want to do the best possible evaluation, on all fronts, at the start. The longer a bad candidate stays in your pipeline or company, the more expensive and disruptive it gets.
As a wishlist I like it, I just don't see how you're going to assess all that in an interview. You'll notice that the technique of the day ("teach me something") doesn't address any of the dot points and that holds for ... pretty much any technique. Interviews are a weak process for assessing anything.
His name was Richard Feynman.
https://www.youtube.com/watch?v=nYg6jzotiAc
(Highly recommended video.)
I should also note that "teach me something" was intended to give the candidate a chance to be the expert at the beginning the interview.
It wasn't something they would be judged on, it was an ice-breaker. And a fun one, based on the feedback I got from candidates.
It is a nerd test. You can get every nerd talking if you ask them to tell you about a special skill or project they really care about.
I remember quite a lot of these lunch conversations:
Me: Hey, what's up? Do you like the salad?
Introvert Nerd: Mmmm-Hmmm.
Me: Great weather outside!
Introvert Nerd: Mmmm-Hmmm.
Me: I was hiking last weekend in the mountains and got caught in a storm.
Introvert Nerd: Mmmm-Hmmm.
Me: Does your work project proceed well?
Introvert Nerd: Mmmm-Hmmm.
Me: I've heard that you regularly cook medieval dishes and you created a food medievality detector using a Raspberry Pi and a horseshoe?
Introvert Nerd: Oh, yes! You know, measuring the medievality of a dish is not as simple as it sounds! Obviously, there are no American foods like tomatoes or potatoes allowed, but did you ever think which spices were common in Europe in the High Middle Ages and why that changed in the Late Middle Ages... ...
I find interviews quite tense and I generally dislike having them (on both sides of the table), but throwing in a few disarming questions here and there throughout really takes the edge off. A conversational, or more cerebral, approach like that can suit some people far better than live code tests or quick-fire Q&A.
I wish more bosses were like you.
I am grateful that so many people in this thread found the ideas useful.
I work as a developer and as an interviewer (both freelance). Now I want to integrate your point 3. into my interviews, but not to choose better candidates, just to learn new stuff I never thought about before.
It is your fault that I see now this risk in my professional life, coming at me. I could get addicted to "teach me something". 'Hey candidate, we have 90 minutes. Just forget about that programming nonsense and teach me cool stuff'
I especially like that you're prepping them very clearly in advance, giving them every opportunity to succeed, and clearly setting a tone of collaboration.
In person design and coding challenges are a pressure cooker, and not real-world. However, giving people the choice, seems like a great way to achieve the balance.
Honestly, I'm really just commenting here so that this shows up in my history, so I can borrow heavily from this format next time I need to interview! :) Thanks again for sharing.
But I digress!
Asking them what they wanted or would teach me was very illuminating and frankly, fun all around! I was brought a variety of subjects and not a single one was dull!
Seems I had experiences similar to yours.
One of my questions was influenced by someone who I respected highly asking, "what books are on your shelf at home?"
This one almost always brought out something about the candidate I would have had no clue about otherwise. As time advanced, it became more about titles because fewer people maintain a physical book shelf!
IBM conducted a mass layoff a few months ago, and as our little team lost our only customer at the time (this is public information), many of us were let go. Ah well.
One door closes, another opens.
If anyone out there is curious about "who is this guy with the strange and interesting ideas about interviewing", you can find my LinkedIn and other contact info in my HN profile.
> // 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."
> I feel like take home tests are meaningless and I always have. Even more so now with LLMs
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.
The drawback is that elements in a hashmap can’t be sorted and accessing a specific element by key is slower then accessing something in an array by index.
Linear search is easier to implement.
These are all trivial questions you ask to determine if a person can develop code. The hard questions are whether the person is the cream of the crop. The amount of supply of developers is so high most people don’t ask trivial questions like that.
> What if I use an LLM but I understand the code?
For most companies, the better strategy would be to explicitly LET them use LLMs and see whether they can accomplish 10X what a coder 3 years ago could accomplish, in the same time. If they accomplish only 1X, that's a bad sign that they haven't learned anything in 3 years about how to work faster with new power tools.
A good analogy of 5 years ago would be forcing candidates to write in assembly instead of whatever higher level language you actually use in your work. Sure, interview for assembly if that's what you use, but 95% of companies don't need to touch assembly language.
Do you seriously expect a 10x improvement with the use of LLMs vs no LLMs? Have you seen this personally, are you 1 10th the developer without an LLM? Or is the coding interview questions you ask or get asked, how to implement quicksort, or something?
Let's make it concrete, do you feel like you could implement a correct concurrent http server in 1/10th the time with an LLM than what you could do it without? Because if you jut let the LLM do the work I could probably find some issue in that code or alternatively completely stump you with an architectural question unless you are already familiar with it, and you should not be having an LLM implement something you couldn't have written yourself.
Absolutely fucking yes.
Concidering this would probably at most take a days work to get at least a workable prototype done if not a full implementation, using an AI you should be able to do it in a lunch break.
And yet this interviewing problem seems to only affect tech companies.
When you're operating a huge furniture company, you want every dowel and every hole the same size. Then any fool can assemble it, and you don't have to waste time and space on a collection of slightly-too-large dowels.
To scale up often means focusing on consistency and precision, and less on expert judgement and care.
The literal only way to get rid of that is quantitative tests.
In the past Google made a lot of hires where they first give people a phone screen, then five in-person whiteboard interviews, then the interviewers send a dossier to a committee, then that committee decides whether to hire or not, then "team matching" lets hiring managers see the resumes.
So the interviews are basically conducted by random people, who have no idea what team the candidate will end up on.
Of course if you look at the number of employees Google has, and the average tenure, you can see why they make hires like Ikea makes chairs.
Usually what happens in a large org is (1) a department gets allocated a head count, and it eventually trickles down to team allocations; (2) a team needs a role that they can’t backfill from the rest of the company; (3) the team lead puts out an ad, receives resumes (directly or through HR), schedules interviews, and makes the hiring decision themselves. Exactly the same as a small company or startup in the last step.
But hiring is nowhere near my full time job, thankfully :D
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.
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.
Uhhh yeah. That would really piss me off. Like reviewbombing glassdoor type of pissed.
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?
In reality they need to look at this like onboarding a new team member.
> Put the candidate at ease - nervous people don't interview well
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
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.
Wishing you all the best for your career!
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.
If nothing else, it's a useful tool when doing reviews with your manager, or when you're trying to evaluate your personal growth.
It comes in really handy when you're interviewing or looking for a new job.
Julia Evans calls it a "brag doc": https://jvns.ca/blog/brag-documents/
It doesn't have to be super detailed either. I tell people to write 50% about what the work was, and 50% about what the purpose/value of the work was.. That tends to be a good mix of details and context.
Writing in it once a month, or once a sprint, is enough. Even if it's just a paragraph or two..
dude maintained a "me wall" of achievements, commendation medals, etc. plus a file full of other crap. he mentioned he got a lot of promotions because you have a section to fill out where you describe all the shit you did over the least year, and he always came with examples...
Honestly, putting those details in writing in a way that I retrain after leaving might leave me vulnerable to claims of violating my corporate NDA. But legalities aside, yes, it would help with these kinds of interview issues - prospectively only of course, not retrospectively.
Annoyingly, it's also exactly the kind of doc that's difficult for people with ADHD to create and maintain rigorously, even though people with ADHD are more likely than average to need the reminders of those details. A lot of ADHD problems are that kind of frustrating catch-22, especially when interacting with a world that is largely designed around more typical brain types.
If I can ask a follow-up question: Is it the act of writing it down, or the whole recall aspect of it that is challenging? Or something else?
I've personally starting using audio transcription with a voice recorder to capture ideas more easily when I'm not at my computer (I hate typing on my phone keyboard) and that has made building these kinds of diary/log/notes documents a lot easier because I can just speak my ideas into the recorder whenever it is convenient for me, instead of waiting until I'm at a computer.
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.
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.
One of the problems I see in big corporates is that feedback cycles for bad policy can be so long, whoever caused something is far away when the effects hit. AKA nobody really cares. But to be fair, I've always tried to care, and worked with many others who do.
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.
You need to do this to establish some baseline competency... for junior hires with no track record?
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".
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.