Ask HN: What is interviewing like now with everyone using AI?
Have you gone back to in-person whiteboards? More focus on practical problems? I really have no idea how the traditional tech interview is supposed to work now when problems are trivially solvable by GPT.
734 comments
[ 2.4 ms ] story [ 448 ms ] threadtightened market is one thing, the absolute insanity of the recruitment process in last couple years with now AI thrown into the mix is really something to behold, test these waters at your own peril
someone who actually wants to hire will want you and wants to do whatever they can to get a good candidate.
For some random SMB in shipping or something to be bashing people over the head with 10 step-leetcode-full-panel-10-hour-systems-design interviews they just don't get it. For starters they probably don't even have the talent to properly evaluate the prospect. So who are they helping?
- Much less resposnes
- For your sanity you want to make sure there aren't obvious signs of something being a ghost job, an H1B hire, an internal hire, or a farce because "we're always growing" (lying).
- expect longer processes. Hasn't happened to me but 7+ stage interview processes is not uncommon these days, even outside of tech
- accept that some processes will be frozen under your nose. especially because of longer processes crossing quarters
- expect less respect in the process. They feel like they do not want you. You are expendable
- don't bother negotiating in this market. You get a number and take it unless you already have a job. Even then they may simply pass you for someone more desperate. BTW wages are being suppressed; you're probably not getting pre 2023 salaries right now.
Yeah... if you're not being abused at work, I'd just weather it out.
"logically, necessarily" as Marc Andreessen says? https://futurism.com/the-byte/ai-investor-goal-crash-human-w...
Now if they could also crash factors like material, energy and profit... consumers could pay pennies using their centinaire incomes.
Even if you're using ChatGPT heavily it's your job to ensure it's right. And you need to know what to ask it. So you still need all the same skills and conceptual understanding as before.
I mean, I didn't observe interviews change after powerful IDE's replaced basic text editors.
I've done a lot of interviews over Zoom, and whenever someone cheats, by passing someone else's work off as their own (the weirdest thing I've ever encountered was someone having a friend on trying to feed them answers, which he admitted to later) it is so painfully obvious if you grill them a bit and throw a few curveballs.
It's the people who have no idea what the hell they're doing and who try to pass of a solution they can't explain and by definition those people you will catch if you know how to interview.
As a result, several of my friends who assist in hiring at their companies have already returned to "on-site" interviews. The funny thing about this is that these are 100% remote jobs - but the interviews are being conducted at shared workspaces. This is what happens when the level of trust goes down to zero due to bad actors.
As someone else noted, this used to be utterly standard. And frankly I’d probably just pass on someone who balked. Plenty of fish in the sea.
Then they emailed me a month later after my "invitation" expired. It looked like it was written by a human: "Hey, we're really interested in your profile, here's a new invite link, please complete this automated pre-screen thingie".
So I swallowed my pride and went through with that humiliating exercise. Ended up spending two hours doing algorithmic leetcode problems. This was for a product security position. Maybe we could have talked about vulnerabilities that I have found instead.
I was too slow to solve them and received some canned response.
The price of people bulk applying with no thought is I have to bulk filter.
[1]: Including but not limited to: having to manually fill a web form because the system couldn't correctly parse a CV; take-home coding challenges; studying for LeetCode interviews; sending a perfectly worded, boot-licking cover letter.
Once you get to the interview process, it's very clear if someone thinks they can use AI to help with the interview process. I'm not going to sit here while you type my question into OpenAI and try to BS a meaningful response to my question 30 seconds later.
AI-proof interviewing is easy if you know what you're talking about. Look at the candidates resume and ask them to describe some of their past projects. If they can have a meaningful conversation without delays, you can probably trust their resume. It's easy to spot BS whether AI is behind it or not.
If you do a rote interview that's easy to game with AI, it will certainly be harder to detect them cheating.
If you have an effective and well designed open ended interview that's more collaborative, you get a lot more signal to filter the wheat from the chaff.
I understood their point but my point is a direct opposition to theirs, that at some point with AI advances this will essentially become impossible. You can make it as open ended as you want but if AI continues to improve, the human interviewee can simply act as a ventriloquist dummy for the AI and get the job. Stated another way, what kind of "effective and well designed open ended interview" can you make that would not succumb to this problem?
People don't really call the police, nor sue over this. But they can, and have in the past.
If it gets bad, look for people starting to seek legal recourse.
People aren't developers with 5 years experience, if all they can do is copy and paste. Anyone fraudulently claiming so is a scam artist, a liar, and deserves jail time.
So you create an interview process that can only be passed by a skilled dev, including them signing a doc saying the code is entirely their work, only referencing a language manual/manpages.
And if they show up to work incapable of doing the same, it's time to call the cops.
That's probably the only way to deal with scam artists and scum, going forward.
It costs employers money to on board someone, not just in pay, but in other employees training that person. Obviously the case must be clear cut, but I've personally hired someone who clearly cheated during the remote phone interview, and literally couldn't even code a function in any language in person.
There are people with absolutely no background as a coder, applying to jobs with 5 years experience, then fraudulently misrepresenting the work of others at their own, to get the job.
That's fraud.
As I said, it's not being prosecuted as such now. But if this keeps up?
You can bet it will be.
Because it is fraud.
I won't name names, but there are a lot of Consulting companies that feed off Government contracts that are literally this.
"Experience" means a little or a lot, depending on your background. I've met plenty of people with "years of experience" that are objectively terrible programmers.
If the AI premise is true, then it's this or good programmers, and good companies will never meet.
In-person interviews, second round comes with a plane ticket. This used to be the norm.
Likewise with hiring; at a small company you're looking to fill an immediate need and are losing money every day the role isn't filled. You wouldn't bring in every viable candidate, you'd bring in the first viable candidate.
FAANG hiring practices assume a budget far past any exit point in your mind.
To put the whole concern in a nutshell: If AI was good enough to fool a seasoned engineer in an interview, that engineer would already be using the AI themselves for work and not need to hire an actual body.
To be fair, many humans do too, but many promising candidates even at the mid-level band of experience who thrive at organizations I've approved them into are able to eventually get to a good enough balance of many tradeoffs (technical and otherwise) with a pretty clean and compact amount of back and forth that demonstrates thoughtfulness, curiosity and efficacy.
If someone can get to that level of capability in a technical interviewing process using AI without it being noticeable, I'd be really excited about the world. I'm not holding my breath for that, though (and having done LOTS of interviews over the past few quarters, it would be a great problem to have).
My solution, if I were to have the luxury of having that problem, would be a pretty blunt instrument -- I'd instead change my process to actually have AI use of tools be part of the interviewing process -- I'd give them a problem to solve, a tuned in-house AI to use in solving the problem, and have their ability to prompt it well, integrate its results, and pressure check its assumptions (and correct its mistakes or artifacts) be part of the interview itself. I'd press to see how creatively they used the tool -- did they figure out a clever way to use it for leverage that I wouldn't have considered before? Extra points for that. Can they use it fluidly and in the heat of a back and forth of an architectural or prototyping session as an extension of how they problem solve? That will likely become a material precondition of being a senior engineer in the future.
I think we're still a few quarters (to a few years) away from that, but it will be an exciting place to get to. But ultimately, whether they're using a tool or not, it's an augment to how they solve problems and not a replacement. If it ever gets to be the latter, I wouldn't worry too much -- you probably won't need to do much hiring because then you'll truly be able to use agentic AI to pre-empt the need for it! But something tells me that day (which people keep telling me will come) will never actually come, and we will always need good engineers as thought partners, and instead it will just raise the bar and differentiation between truly excellent engineers and middle of the pack ones.
If you look solely at my GitHub you'd likely reject me right away.
I wish I had the time and energy for passion projects in programming. I so wish it was so. But commercial work has all but destroyed my passion for programming, though I know it can be rekindled if I can ever afford to take a properly long sabbatical (at least 2 years).
I'll more agree with your parent / sibling comments: take a look at the resume and look for bad signs like too vanilla / AI language, too grandiose claims (though when you are experienced you might come across as such so 50/50), or almost no details, general tone etc.
And the best indicator is a video call conversation, I found as a candidate. I am confident in what I can do (and have done), I am energetic and love to go for the throat of the problems on my first day (provided the onboarding process allows for it) and it shows -- people have told me that and liked it.
If we're talking passion, I am more passionate about taking a walk with my wife and discussing the current book we're reading, or getting to know new people, or going to the sauna, or wondering what's the next meetup we should be going to, stuff like that. But passion + work, I stand apart by being casual and not afraid of any tech problems, and by prioritizing being a good teammate first and foremost (several GitHub-centric items come to mind: meaningful PR comments and no minutiae, good commit messages, proper textual comment updates in the PR when f.ex. requirements change a bit, editing and re-editing a list of tasks in the PR description).
I already do too much programming. Don't hold it against me if I don't live on the computer and thus have no good GitHub open projects. Talk to me. You'll get much better info.
I would also add meticulous attention to documenting requirements and decisions taken along the development process, especially where compromises were made. All the "why's", so to speak.
But yes, commercial development, capital-A "Agile" absolutely kills the drive.
And yep I didn't want to make my comment too big. I make double sure to document any step-by-step processes on "how to make X or Y work", especially when I stumble upon a confusing bug in a feature branch. I go out of my way to devise a 100% reproducible process and document it.
Those, plus yours, and even others, are what makes a truly good programmer IMO.
And tbh, at the senior level they rarely care about personal projects. I must have had 60+ interviews and I feel a lack of a github cost me maybe 2 positions. When you job is getting a job, you rarely have the time for passion.I'm doing contract work in the meantime; prevents gaps from showing, more appealing than a personal project, and I can talk about that to the extent of my NDA (plenty of tech to talk about without revealing the project)
Same. I could afford not working throughout most of 2023 but I had to deal with ruined health + my leeway didn't last as long as I hoped so I was back on the treadmill just when I was starting to enjoy some freedom and a peace of mind.
> And tbh, at the senior level they rarely care about personal projects. I must have had 60+ interviews and I feel a lack of a github cost me maybe 2 positions.
I have no idea how much it costed me but I was told in no uncertain terms 10+ times that having a GitHub portfolio would have meant no take-home assignment, and skipping parts of the interview I already attended. So it definitely carries weight _and_ can help shorten hiring processes.
So I don't feel it was a deal-breaker for the people who interviewed me either but I think it would have netted me more points, so to speak.
Assuming you are graded and are the same person:
Without portfolio: 7/10
With portfolio: 8/10
...for example.
> I'm doing contract work in the meantime
Same x2, but it's mentally draining. No stability. That removes future bandwidth that would have been used for those passion projects.
TL;DR a lot of things conspire to rob you of your creative potential. :(
The long term goal should be that you should NOT be energetic, yet be able to pretend that you are. We'll see where you are at the 33 year mark :)
Also if you have a novel or disclosure sensitive passion project, GitHub may be avoided even as a very conservative bright line.
As stated above I think it can be good to find common points to enhance the interview process, but make sure to not use it as a filter.
That said, I'm waiting for an "interview assistant" product. It listens in to the conversation and silently provides concise extra information about the mentioned subjects that can be quickly glanced at without having to enter anything. Or does this already exist?
Such a product could be useful for coding to. Like watching me over the shoulder and seeing aha, you are working with so-and-so library, let me show you some key parts of the API in this window, or you are trying to do this-and-that, let me give you some hints. Not as intrusive as current assistants that try to write code for you, just some proactive lookup without having to actively seek out information. Anybody knows a product for that?
The only way I can see that working is if it spends hundreds of hours watching you to understand what you know and don't know, and even then it'll be a bit of a crap shoot.
This was 2-3 years ago in a remote interview. The candidate would hear the question, BS us a bit and then sometimes provide a good answer.
But then if we asked follow up questions they would blow those.
They also had odd 'AV issues' which were suspicious.
So you just subjectively say "this resume is too perfect, it must be bullshit"? How the fuck is any actual, qualified engineer supposed to get through your gauntlet of subjectivity?
I'm sure some small % of people get away with it by using LLaMA-FooQux-2552-Finetune-v3-Final-v1.5.6 or whatever, but realistically, the majority is going to be obvious to anyone that's been force-fed slop as part of their job.
I am imagining an AI saying my CV is AI-generated, when in reality, I do not even use Auto-correct or Auto-suggest when I (type)write! :-)
Generally, this is how to figure out if a candidate is full of crap or not. When they say they did a thing, ask them questions about that thing.
If they can describe their process, the challenges, how they solved the challenges, and all of it passes the sniff test: If they are bullshitting, they did crazy research and that's worth something too.
It's as if we were testing for replicants in Blade Runner: The AI response will rarely figure out you are aiming to look for something frustrating, that they are actually proud of, or figure out when you are looking for a hot take you can then disagree with.
The coding challenge is supposed to be solved with AI. We can no longer afford not to use LLMs for engineering, as it's that much of a productivity boost when used right, so candidates should show how they use LLMs. They need to be able to explain the code of course, and answer questions about it, but for us it's a negative mark of a candidate proclaims that they don't use LLMs.
Do you state this upfront or is it some hidden requirement? Generally I'd expect an interview coding exercise to not be done with AI, but if it's a hidden requirement that the interviewer does not disclose, it is unfair to be penalized for not reading their minds.
I am personally of the view you should be able to use search engines, AI, anything you want, as the task should be representative of doing the task in person. The key focus has to be the programmer's knowledge and why they did what they did.
They also take this approach of "whatever tool works," but their coding test is "here's some symptoms of the SVG generator misbehaving, figure out what happened and fix it," which requires digging into the commit history, issues, actually looking at the SVG output, etc.
Once you've figured out how the system architecture works, and the most likely component to be causing the problem, you have to convert part of the code to use a newer, undocumented API exposed by a RPC server that speaks a serialization format that no LLM has ever seen before. Doing this is actually way faster and accurate using an AI, if you know how to centaur with it and make sure the output is tested to be correct.
This is a much more representative test of how someone's going to handle doing actual work knocking issues out.
It's not a hidden requirement per se to use LLM assistance, but the candidate should have a good answer ready why they didn't use an LLM to solve the challenge.
Also, what is a good answer for not using one? Will you provide access to one during the course of the interview? Or I am just expected to be paying for one?
We are providing an API key for LLM inference, as implementing the challenge requires this as well.
And I haven't heard a good answer yet for not using one, ideally the candidate knows how to mitigate the drawbacks of LLMs while benefiting from their utility regardless.
Again, what would be a good answer? Or are you just saying there isn’t one?
"I considered various approaches for solving this problem. Initially, I thought about using an LLM, as it's great for natural language processing and generating text-based solutions. However, for this particular challenge, I felt that a more algorithmic or structured approach was more appropriate, given the problem's nature (e.g., the need for performance optimization, a specific coding pattern, or better control over the output). While LLMs are powerful tools, they may not always provide the precision and control required for highly specific, performance-critical tasks, so I chose to solve the problem through a more traditional method. That said, if the problem had been more open-ended or involved unstructured data like text generation, I would definitely consider leveraging an LLM."
This answer reflects the candidate's ability to critically assess the problem and use the right tools for the job, showing maturity and sound judgment.
- GP, probably
"LLM-esque AI, especially in my industry, is under heavy scrutiny and I want to wait for the dust to settle before exploring options with such tools."
I was never asked as such, but I do have an answer to that.
Frankly, if an interviewer told me this, I would genuinely wonder why what they're building is such a simple toy product that an LLM can understand it well enough to be productive.
You ask a rote question and you'll get a rote answer while the interviewee is busy looking at a fixed point on the screen.
You then ask a pointed question about something they know or care about, and suddenly their face lights up, they're animated, and they are looking around.
It's a huge tell.
I just tried and it's: hard. It feels like being ask to keep one's breath like writing something.
I need to focus too much on keeping my eyes closed, I don't have enough bandwith left to thing about anything relevant.
Is everyone writing a "Projects" section by rewording what they wrote in "Experience"?! For me, "Projects" should strictly be personal projects. If not, maybe that's what I'm missing.
They don't have to be public to the whole world, you can have links that are only in your resume.
But if they're on GitHub, they have to be public, since there aren't unlisted repositories.
An unlisted repository would be one that is public to those who know the URL.
https://leetcodewizard.io/
I’ve also been asked for the first time in ages to come to the companies office to do interviews.
Last time I did this they told me it is but that they are at late stages of interviewing so I shouldn't bother applying for that one, but they got down my details and had other jobs that matched what I was looking for. Recruiters are sales people and you just reversed cold called them making their job easier. The majority of applications are AI bots and people who don't live in the country the job is listed in. By making a phone call you are up the top of the list of "most likely to be a legitimate applicant".
This even applies to businesses in some cases. You trying to walk in and talk to someone is a security threat compared to the times where you could do that and walk out with a job offer. US companies absolutely hate unsolicited calls from non-businesses.
I'm too busy doing actual paid work for companies for that.
that'd be a huge issue for most candidates (and basically all top candidates) because "exactly what you want to hire you for" is probably not open source code to begin with.
>If you are one of the 1 in 4000 applications who gets an interview then you're already 70% likely to get an offer and the interview is mostly a formality.
That has not been my experience at all in 2023/2024.
And I had made it clear that they should use their own words.
- share your screen
- download/open the coding challenge
- you can use any website, Stack Overflow, whatever, to answer my questions as long as it's on the screenshare
My goal is to determine if the candidate can be technically productive, so I allow any programming language, IDE, autocompleter, etc, that they want. I would have no problem with them using GPT/Copilot in addition to all that, as long as it's clear how they're solving it.
Either way, screen sharing beats whiteboards. Even if we throw our hands up and give up, we'll be firing frauds before the probationary period ends.
Interviewing just needs to adapt such as by assessing one's open source projects and contributions. Not much more is needed. And if the candidate completely misrepresents their open source profile, this can be handled by an initial contract-to-hire period.
There is if you’re asked not to.
Open source contributions is a bad metric for interviewing too. People have lives outside a computer, if they aren’t doing open source contributions in their free time outside of work I wouldn’t hold that against them. If someone has those that’s great and I’d take a look, but I’m not disqualifying someone else for not working for free. Someone doing OSS as an interviewing badge of honor is a chump in my book. At least do it for principled reasons.
It proved to be awkward and clumsy very quickly. Some candidates resisted it since they clearly thought it would make them judged harsher. Some candidates were on the other extreme and basically tried asking ChatGPT the problem straight up, even though I clarified up front "You can even use ChatGPT as long as you're not just directly asking for the solution to the whole problem and just copy/pasting, obviously."
After just the initial batch of candidates it became clear it was muddying things too much, so I simply forbade using it for the rest of the candidates, and those interviews went much smoother.
Unfortunately in our industry it's pretty much all personal anecdotes on what works better and what doesn't.
The challenge should be in determining if ChatGPT is correct.
But yeah, the point is that once I applied it in practice it did quickly become confusing, so now I know from experience not to use it.
I think the other suggestions in this thread about how to use it are good ones, but they would present their own meta challenges for an interview too. Just about finding whatever balance works for you I guess.
But for me, it's just not how my brain works. If someone is watching me, I'll be so self-conscious the entire time you'll get a stream of absolute nonsense that makes me look like I learned programming from YouTube last night. So it's not worth the time.
You want some good programming done? I need headphones, loud music, a closed door and a supply of Diet Coke. I'll see you in a few hours.
Whereas my natural approach would be to take a long shower, workout etc and let my brain wander a bit before digging into it. But that wouldn’t fly during an interview..
That said, now we're just talking about take home challenges for interviews and you always hear complaints about those too. And shorter, async timed challenges (something like "Here's a few hours to solve this problem, I'll check back in later") are now going to be way more difficult to judge since AI is now ubiquitous.
So I really don't think there's any perfect methodology out there right now. The best I can come up with is to get the candidate in front of you and talk through problems with them. The best barometer I found so far was to set up a small collection of files making up a tiny app and then have candidates debug it with me.
This is a great one! I wish more companies tried that.
In an interview, the coding challenge is often to produce something new from scratch while being closely monitored by people you don't know, who control your financial future.
When working with a "junior," you'd already be fairly familiar with the code base, build system, and best practices. And with a junior, you're not likely to be solving things that require deep concentration, like never-before-seen problems or architectural work (or screwball interview-tests). And, unlike an interview, if something does require all my focus, it's very easy to defer. Take a break and think about it alone.
No, it's not "obvious" whatsoever. Actually it's obviously confusing: why you are allowing them to use ChatGPT but forbidding them from asking the questions directly? Do you want an employee who is productive at solving problems, or someone who guess your intentions better?
If AI is an issue for you then just ban it. Don't try to make the interview a game of who outsmart who.
> If AI is an issue for you then just ban it.
Yes, that was the conclusion I just said we rapidly came to.
- You get to see how they then review the generated code, do they spot potential edge cases which the AI missed? - When I ask them to make a change not in the original spec, a lot of them completely shut down because they either didn't understand the code generated well enough, or they themselves didn't really know how to code.
And you still get to see people who _do_ know how to use AI well, which at this point is a must for its overall productivity benefits.
if i see anything remotely challenging i dip out. interviewing is just a numbers game nowadays so i dont waste time on interviews if they seem like they're gonna burn me out for the rest of the day. granted i have 11 years experience
Too many people are the opposite that I would literally never tell you
And this works.
what can we do to help that?
I’ve had interviews where AI use was encouraged as well.
but so many casual tirades against it dont make me want to ever try being forthcoming. most organizations are realistically going to be 10 years behind the curve on this
Some of the questions in our interview loop have been posted in github... which means every AI has trained on them specifically. They are, therefore, useless if you have AI turned on. And if you interview enough people, someone will post on github, and therefore your question will have a pretty short shelf life before it's in training and instantly solved.
I do not want AI. The human is the value add.
I understand that people won't feel super comfortable with this, and I try not to roast the candidate with leetcode. It should be a conversation where I surface technical reality and understanding.
I think it ultimately comes back to impact (like always) which has remained largely unchanged.
If they can talk through the technology and code fluently, honestly, I don't care how they do the work. Honestly I feel like the ability to communicate is a far more important skill than the precise technology.
This is of course presumes you have a clue about the technology you're hiring for.
The story is completely different for airgapped dark room jobs, but if you know you know.
That would be a bit awkward with my 32:9 primary monitor.
Not like I'd do anything. I use one screen to work, one for video, and one for work visuals. Seeing one screen would show if I had any hidden windows anyway.
The candidate’s first response? “Memory updated”. That led to some laughs internally and then a clear rejection email.
This is because my brain couldn't fathom what is likely the reality here -- that someone was just pumping your email thru AI and pumping the response back unedited and unsanitized, and so the first thing you got back was just the first "part" of the AI response.
...Christ.
Unfortunately what we end up doing is have to make some assumptions. If something seems remotely fishy, like that “Memory updated” or typeface change (ChatGPT doesn’t follow your text formatting when pasting into your email compose window), it raises a lot of eyebrows and very quickly leads to a rejection. There’s other cases where your written English is flawless but your phone interview indicates you don’t understand the English language compared to when we correspond over email/Indeed/etc.
Mind you, this is all before we even get to the technical knowledge part of any interview.
On a related hire, I am also in the unfortunate position where we may have to let a new CS grad go because it seemed like every code change and task we gave him was fully copy/pasted through ChatGPT. When presented with a simple code performance and optimization bug, he was completely lost on general debugging practices which led our team to question his previous work while onboarding. Using AI isn’t against company policy (see: small team with limited resources), but personally I see over reliance on ChatGPT as much, much worse than blindly following Stack Overflow.
Long live plain text email.
1. The manual was mostly a bunch of phrases that were grammatically correct, but didn't really convey much meaning
2. The second half of the manual talked about a different machine than the first half
3. It was full of exceptionally bad mistranslations, and to this day "trained signaturee of the employee" is our inside joke
Imagine asking ChatGPT to write a manual except ChatGPT has down syndrome and a heart attack so it gives you five pages of complete bullshit. That was real manual that got shipped a 100 000€ or so machine. And nobody bothered to proofread it even once.
But yes, I read it the same way. Pretty funny way to respond to a recruiter after they say "no AI please".
It is really important to watch people code.
Anyone can fake an abstract overview.
When I was part of interviews on the other side for my former employer, I encountered multiple candidates who appeared to be using AI assistance without notifying the interviewers ahead of time or at all.
Ask even the shallowest question and they are lost and just start regurgitating what feels like very bad prompt based responses.
At that point it's just about closing down the interview without being unprofessional.
AI doesn't just change the interviewing game by making it easy to cheat on these interviews, it should be changing your hiring strategy altogether. If you're still thinking in terms of optimizing for cogs, you're missing the boat—unless you're hiring for a very short term gig what you need now is someone with high creative potential and great teamwork skills.
And as far as I know there is no reliable template interview for recognizing someone who's good at thinking outside the box and who understands people. You just have to talk to them: talk about their past projects, their past teams, how they learn, how they collaborate. And then you have to get good at understanding what kinds of answers you need for the specific role you're trying to fill, which will likely be different from role to role.
The days of the interchangeable cog are over, and with them easy answers for interviewing.
"talk about their past projects, their past teams, how they learn, how they collaborate"
You have now excluded amazing engineers who suck at talking about themselves in interviews. They may be great collaborators and communicators, but freeze up selling themselves in an interview.
- “big” tech companies like Google, Amazon, Microsoft came up with these types of tech interviews. And there it seems pretty clear that for most of their positions they are looking for cogs
- The vast majority of tech companies have just copied what “big” tech is doing, including tech interviews. These companies may not be looking for cogs, but they are using an interview process that’s not suitable for them
- Very few companies have their own interview process suitable for them. These are usually small companies and therefore the number of engineers in such companies is negligible to be taken into account (most likely, less than 1% of the audience here work at such companies)
Bugs need to be fixed. Features need to be implemented. If it weren't for cogs, you'd have people just throwing new projects over the fence and dropped 6 months after release. Don't want to be another cog? Join a startup. Plenty of those hiring. The reality is that when you work at a large company, you're one of 50,000 people. By definition, only 1% are in the top 1%.
Someone has to wash the dishes and clear the tables. Let's stop looking down at jobs just because it's not hot and sexy. People who show up and provide value is great and should be appreciated.
The interview process being a circus of how many hoops you'll jump through. Which in this case is upwards of 3 months of trivia, beauracracy, and politics. And these days they don't even give you the grace of a response; they may just ghost you.
But being a cog itself is personally fine. Work to live, not live to work. But leading people on to drop them on the tip of a hat is disrespectful of everyone's time. At least a 1-2 stage interview for a dishwasher or table busser is only wasting a few hours per role applied. Time is the most valuable resource we have, of course people want to use it carefully.
Human cogs are going to be phased out. I'm not an AI doomer who thinks engineers are going to be replaced across the board, but the need for a human being who functions like a robot is going away fast. We need humans to do what humans do well, and humans don't do well as cogs in a machine—machines are better at that role.
The days of leetcode interviews are numbered not because they're too easy to cheat at, but because they were always optimizing for the wrong traits in most companies that cargo culted them, and even the companies that used them correctly (Big Tech) are going to rapidly need a different type of interview for the new types of hires they need.
The council itself is made of "busywork" worker bees. Slave hiring slaves - the vast majority of IT interviewers and candidates are idiot savants - they know very little outside of IT, or even realize that there is more to life than IT.
This was the norm until perhaps for about the last 10-15 years of Software Engineering.
I didn't say that. I said that this style of interview was designed to hire pluggable cogs. As others have noted, that was the correct move for Big Tech and was cargo culted into a bunch of other companies that didn't know why their interviews were shaped the way they were.
> there would be "out of the box thinkers" who would go against your ideas and cause dissent. At that point, guess what? You're going to figure out how to hire compliant people who will execute on your strategy.
In answer to your original question: yes, I'm actively involved in hiring at a 100+ person engineering org that hires this way. And no, we're not looking to figure out how to hire compliant people, we're hiring engineers who will push back and do what works well, not just act because an executive says so.
> You have now excluded amazing engineers who suck at talking about themselves in interviews. They may be great collaborators and communicators, but freeze up selling themselves in an interview.
Only if you suck at making people comfortable and at understanding different (potentially awkward) communication styles. You don't have to discriminate against people for being awkward, that's a choice you can make. You can instead give them enough space to find their train of thought and pursue it, and it does work—I recently sat in on an interview like that with someone who fits your description exactly, and we strongly recommended him.
This is the job of a good interviewer. I've run the gauntlet from terrible to great answers to the exact same questions depending on the interviewer. If you literally just ask that question out of the blue, you'll either get a bad or rehearsed response. If you establish some rapport, and ask it in a more natural way, you'll get a more natural answer.
It's not easy, but neither is being on the other side of the interviewer, and that's never been accepted as an excuse
That’s exactly what we always needed, long before LLMs arrived. That’s why all the interviews I’ve seen or give already were designed to have conversations.
I’m agreeing with you, but I’ve never seen these ‘interchangeable cog’ interviews you’re talking about.
The interview is a chance to see how a candidate performs in a work like environment. Let them use the tools they will use on the job and see how well they can perform.
Even for verbal interviews, if they are using ChatGPT on the side and can manage the conversation satisfactorily then more power to them.
There's nothing wrong with a candidate going "Normally I'd prompt ChatGPT and get a skeleton project going" or saying "Look, I don't run around with the entire standard library in my head. I look that stuff up and sometimes that's with an LLM". The problem is when they can't go through the steps of solving a program, without the AI. I don't care about the details, or if you ask Copilot to do the API query code, because you don't want to write the error handling, that actually fairly reasonable, but if you can't prompt it to add the logic for a HTTP 403 then what's the point? In that case I'd rather hire someone who takes longer, but who knows that the 403 should probably redirect an unauthenticated user to the login page.