Great job on further eroding the trust from a prospective employer.
Require a formal degree in CS? That's gatekeeping.
Need to pass a whiteboard exam? Not representative of the actual work.
Live coding session? Biased against people who don't perform well under pressure.
Take home project? It's too much work to do for free.
Showcase a personal portfolio? Not fair to people with families or other obligations.
Either you enforce a minimal level of competency upfront in the form of an academic degree, industry-standard exams such as a PE Exam, etc. OR you push the entire responsibility of vetting prospective applicants downstream to the employer—which is exactly why interviews are multiple week long gauntlets.
The tech world likes to complain about all of this but other occupations 100% DO have high standards - it's just that it's paid up-front.
Want to become a lawyer? - You've got to pass the LSAT, get into law school, and pass the bar.
Want to become a doctor? - You've got to pass the MCAT, get into medical school, and do residency.
Want to become a pilot? - You've got to get your PPL, pass your check ride, do your IFR, multi-engine, commercial rating, ATP
God there are some days that I ABSOLUTELY HATE THIS INDUSTRY.
The pushback is precisely because paying the high standards up front pulls up the ladder that made tech such an attractive option to people without traditional academic skills who managed to be computer whizzes.
Take home projects and personal portfolios are the options that are the best. Those are the ones where candidates are given the time to show their best work and don't require the debt of a college degree in a specific major (whose knowledge is probably largely irrelevant to your day-to-day coding).
If your hiring process is broken by people using AI then the process is either not evaluating the right things, or maybe it's fine because realistically speaking you're hiring a dev who's going to be using AI anyway.
Interviews seek to estimate long-term job performance. Since they cannot measure this directly, they measure attributes that correlate with performance. If you interfere with these measurements (e.g. through fraud), you break those correlations. This doesn't mean the interviews are measuring the wrong thing, or that people who cheat on the interviews will meet the performance bar in the actual job.
If someone uses AI to defeat a CAPTCHA, does that mean the CAPTCHA was poorly designed because "the bot is just as valid a user as any human"? Of course not - the CAPTCHA's entire purpose was to establish that correlation between "can solve this" and "is human," and breaking that correlation through automated tools defeats its purpose entirely.
Unfortunately real life problems involve a lot of context and introducing that to interviews is hard.
It either requires a long conversation where someone might lose track, or involve writing a large ish code base and getting them to work on that (which is a lot of work, and once again they don’t have context).
In my experience if a problem simple enough to be completed in an hour, it’s simple enough for AI.
I work in infra. I don’t want an incident to be the time that I find out my coworkers don’t actually know how anything works, and are frantically posting questions to ChatGPT.
That said, I also don’t know how to adequately test, other than to carefully watch people’s eyes during questions; even that isn’t foolproof.
I find this all rather intriguing because to me it says more about the employers/interviewers than the applicants.
Over the years I've interviewed many people for technical positions and there are many ways of getting to the core of a prospective employee's competence.
Of course there are questions about training, past experience, qualifications and those about the work you expect them to perform but other matters also enter the equation and they're almost as important (the person's demeanor, confidence, etc.). By letting the person do most of the talking—explaining things about themselves and their work—you can learn a great deal.
Stating the obvious, interviewers ought to be on top of the job they're hiring for but from this story and from other anecdotal info I know that's not always so. In my case as head of the department I was pretty much up to speed on most aspects of the work, so it was clear to me when an applicant was spinning me BS. If they knew more than I did then they almost certainly got the job (life's easier when you've smart employees, for starters one can ask them questions instead of vice versa).
What's that leading up to? Well, when interviewing it was obvious to me (and to the other interviewers) within just the first few minutes whether the person was worth considering. It's uncanny how good one can become at doing this (and my record speaks for itself, I was pretty pleased with those employees I hired).
Let me illustrate with an example: some decades ago I had an applicant apply for an electronics job. He spoke only Chinese and a few broken words in English and none of us on the interview panel spoke Chinese. BTW, he turned up with a Chinese/English dictionary in hand.
I dispelled with many of the questions I usually asked and showed him a somewhat complex circuit diagram with many subsections that performed very different functions (if I showed this at all then it was usually towards the end of an interview).
Within seconds of looking at the diagram he progressed logically through the processes from beginning to the end (note the processes/stages were not drawn in linear progression and consisted of many branches). He did this mainly by pointing.
It was immediately obvious to both my independent technical assessor and me that this guy knew his subject very well. The only point was a minor objection from the nontechnical employment officer who questioned if we'd manage to communicate adequately with someone who didn't speak English. I didn't see that as a significant issue.
He turned out to be an excellent employee who knew his work very well. And within six months his English was good enough not to be an issue.
In summary, if AI is a problem now then it will be more so in the future and that needs to be tackled. That said, I find it hard to accept that an experienced interviewer can't quickly cut to the core even when an interviewee puts up smoke screens and distracting noise.
Like, Popper's falsifiability it doesn't take much to knock a BS or inconsistent argument off its pedestal when one has enough data, refutability usually works well.
That said, one must always keep in mind that just because an applicant can get some things wrong it doesn't mean that he/she isn't the best person for the job. All that tells me is that I have to probe a little deeper.
Edit: asking awkward or trick questions usually ought to be avoided. An interviewee is usually already under considerable stress and can easily be flummoxed when asked them (even if they know the answers they can bind up and not spell them out).
Usually, it's immediately obvious when an interviewee doesn't know an answer to a question or is struggling with it because of stress—body language alone usually makes that abundantly clear. It's then best to gently segue to another question. If the question is really relevant to the job then one can return to it at the end of the interview when the person is more at ease. By then, it's pretty clear to the panel whether the applicant is in the running or not. If not, then do not return to the question.
> Require a formal degree in CS? That's gatekeeping.
Selecting people for a job is literally gatekeeping. The company has the equivalent of a gate (or perhaps an actual one), and most people are kept out of it by the fact that they are not employees or authorized visitors.
No part of would-be employee screening can be faulted for being gatekeeping; i.e. being that which it is.
There’s an argument to be made that by the time your business runs out of vetted candidates to hire you’re already staffed at some of the highest levels by corporate parasites who got there by gaming the system, and you can tolerate adding more elsewhere.
> Biased against people who don't perform well under pressure.
I think performance under pressure is a virtue. An important job is never going to be entirely free from stress - you want somebody reliable who will take that in their stride, you don't want someone who will buckle when things get difficult.
I'm all for in-person live collaborative problem solving, be it on a whiteboard or just a discussion. You see first-hand exactly what the person has in their memory, their problem solving techniques, how quickly they get things, their communication skills, and yes, their ability to work under pressure. If done correctly and collaboratively, you get a dry-run of a real design meeting and have some feeling of what it would be like to work with the person.
> I think performance under pressure is a virtue. An important job is never going to be entirely free from stress - you want somebody reliable who will take that in their stride, you don't want someone who will buckle when things get difficult.
Some people experience extraordinary high levels of stress in an interview setting. From your comment, I suspect that you are not one of them and might have trouble imagining what these levels of stress feel like.
I prefer our current system over the industry standards exam system you seem to be advocating for. It’s more flexible. Different companies care about different things. Different employees have different strengths. It all works out.
I'm a little confused about your reasoning that take home projects are too much work to do for free. Aren't lawyers and doctors expected to spend a ton of time studying and taking the licensing exams without being paid (I assume even having to pay for it)? My gut feeling is that's more work than a take home project.
Live coding session? Biased against people who don't perform well under pressure.
No, it's biased against people who perform perfectly well (sometimes exceptionally well) under real, actual pressure. But who do not take kindly to the bullshit / theatrical pressure typical of the standard interview context, these days. And to companies that just can't tell the difference (or are under the delusion that performance in the latter category is in some way predictive of performance in the former).
Take home project? It's too much work to do for free.
It's more that the companies simply abuse the process in various callous and careless ways -- either by assigning projects with inadequate specification and/or unknown goalposts (or plainly unrealistic expectations of the actual time required, given these ambiguities); or simply assigning scores of these assignments (often automatically to every candidate who applies) when in fact they have no intention of even looking at the vast majority of the submissions.
Easily ameliorated by simply paying people for their time.
Shut the fuck up. We'll stop cheating when these corps stop making us solve binary search algorithms to interview for front end React roles. Probably 80% of all technical interviews I've had were completely irrelevant to the actual daily work. They engineered this shitty game, we're just playing the game. No one's making you play this game.
Feels like in some sections of the US like big tech, the talent vetting process has evolved into some adversarial battle of attrition where the idea is to grind down the pool of candidates until only a few are left rather than find some potential new colleagues. Tools like this have emerged as a direct response to that process.
What a bizarre way to begin a working relationship.
Sadly, these sorts of “practical interviews” aren’t just limited to Big Tech. There’s been an arms race for thirty years now between applicants and employers, the latter creating new hurdles to overcome and the former finding new ways to bypass unnecessary hurdles.
Employers demanded applications instead of resumes, so candidates used copy machines. Then they wanted block lettering, so candidates used type writers. ATS systems could search for keywords, so candidates flooded their resumes with them. Then employers allowed online applications, and the floodgates opened proper - applications from all over the world, desperate for good employment. So they made you create an account, and applicants wrote or used bots to automate it - which became site features like “Quick Apply” on LinkedIn and Indeed. Practical interviews used to be a single round for only the most senior roles, but then employers wanted everyone to be as qualified as those roles but not pay them that much, which started the cheating arms race.
Ultimately, the problem remains a glut of qualified talent demanding salaries to pay the bills, and employers who want to pay as little as possible. The two sides are adversaries by default, and few companies do the work of mending the relationship into something more cooperative.
This is all fully explained by salaries going up, and the pool of young applicants getting bigger faster than the number of jobs available, while the pool of highly qualified applicants remains small. Jobs at Facebook, Google, Microsoft, Intel, Nvidia, are all legitimately competitive, and because more people are applying, those companies have the freedom to be choosier and the incentive to compete for the good ones. Because salaries have gone up (or even simply the perception of salaries), and because salaries are high compared to other jobs, more and more bright-eyed kids are hoping to punch above their weight in interviews, which is why companies are flooded with low-quality applications and don’t have a choice about needing to sift them efficiently.
This is the natural state of a competitive environment, and interviews will get “better” for candidates when there are more jobs than good candidates. But be careful what you wish for; if the job market gets less competitive for candidates, salaries and benefits and working conditions go with it.
While there might be some truth it to, framing it as an arms race is a mentality that will not help the average candidate, and might do them harm. Employers always have and always will want to pay as little as possible, obviously, that’s the definition of a company. But they do actually compete with each other for good talent, and they do pay a lot relative to other jobs, and some companies’ definitions of pay as little as possible is still to pay enough that employees are well compensated and don’t leave.
this does NOT match my experience as an interviewer. Our company went through piles of candidates who were not qualified and it took us months to find a good fit after going through hundreds of resumes and scores of interviews.
I hope the folks we hired are paid enough to retain because there were was absolutely no glut of talent. It was hard to find the folks we wound up hiring. There was a glut of applications, yes, but the vast majority were totally unqualified.
As an employer, I know candidates use LinkedIn’s “Apply in one click” in bulk. When we contact them, half of them notice they don’t even fit the criteria in our ad (be a Java developer, for starters).
The move away from on-the-job training has played a role. If a company doesn't provide any early guidance and mentorship (which everyone could use regardless of industry experience), then that has to be replaced by finding the perfect candidate who can immediately be productive.
I've recently been studying leetcode (for reasons) and went through an interview process.
It was, by far, the most boring interview I've ever had to participate in. The leetcode problem was easy (detect if two strings are anagrams; solved with O(n) solution in < 10 LOC; then aggregate sets of anagrams). System design was easy because it is to the point that it is largely "formulaic". It feels like those rhythm games where you need to know when the trigger is coming and the pattern to hit those triggers (talk about functional requirements -> talk about non-functional requirements -> write some API routes -> draw a load balancer (because of course, there's always a load balancer) -> draw a service -> draw Redis/Memcached -> draw a database). It's comically laughable how it's just like a rhythm game at this point.
What I don't understand is why teams don't just "get to the point". A lot of times, the assessment is looking for specific notes. Why not just ask about those notes directly? A friend recently went through an interview where he was docked for not using C# `yield` when implementing an `IEnumerable`. But had the interviewer asked "What is `yield` and why would you use it?", the interviewer would have gained the same exact insight in 15 seconds with one question.
I think what's also striking is how slow orgs are to adapt their interview process to account for AI. There's a distinct lack of focus on code reviews as part of the assessment. If the future of coding is AIs for productivity, then teams should be adding code reviews into their process (check for correctness, check for defects, check for performance, check for security, etc).
| distinct lack of focus on code reviews as part of the assessment
"Writing code is easy, reading code is hard"
An interview based on reading, explaining and critiquing complicated code would give a better window into a candidate's skills than having them solve the kind of coding challenge that can be completed in a short interview.
Also, being able to identify which algorithms would be useful in solving a unique problem and explain what the pros & cons are would go further than implementing an algorithm abstractly.
As somebody that gives systems design interviews most weeks, you’d be surprised how many candidates don’t put the api gateway but magically go from the TCP load balancer to the services inside the cluster, or how basically nobody is ever able to explain how a CDN works (as in, put the CDN behind the API gateway, note I have seen this in a company in production too). Or how some candidates will have redis and Postgres and do magical cross storage transactions.
And these are all candidates with 5+ years experience, sometimes 10+. I hate the leetcode gauntlet, but I also am really surprised how much worse candidates are now on average that they used to be (I’ve been around for about 25 years now), and how the minute you try to dig a little deeper to see if they know how things really work, the more it seems that they have no understanding whatsoever of the basics and somehow treat computers as magical black boxes.
I do understand I am privileged by having grown with the technology, starting in the 8-bit era, through an electronic engineering degree, and now in k8s etc. but with so much educational material available for free you’d think that even people in their 20s/30s now should be able to have a better idea of how things work.
The ideal purpose of hiring is to find a skilled candidate who will be a good fit and maybe even bring talent and energy to the role. The hiring entity will ideally provide mentoring and training to ensure a successful investment and relationship.
But the catch is... the people doing the hiring must themselves ideally be talented, energetic, skillful mentors who envisage building a positive culture.
I have a theory that job search sights have an incentive to make the application/recruiting process so much of a slog due to (1) the hundreds of applications many people have to send out and (2) the hundreds of applications that companies have to sort through, as a way to justify their own existence.
On one hand, that’s what it always was, by definition - a company is looking for the best candidates it can get with a given budget, and the best-case scenario for the company is there’s a large pool of candidates to choose from.
On the other hand, from my perspective and experience on both sides of the interview table, to me it seems like the perception that this is adversarial is coming primarily from young candidates whinging on the internet in large numbers about interviews being unfair or “broken” or doing it the wrong way. Every time this comes up on HN, there are hordes of comments demanding we stop whiteboarding in interviews, or claiming anything not exactly in the job description is out of bounds, or decrying the abuse that coding live inflicts. There are blog posts every week about how to fix the problem, where the problem is usually the interviewee’s comfort, and not the company’s efficiency or effectiveness.
The truth is that companies need people, and the employees there do want new colleagues. If you truly understand that, and also that the selection process is unavoidable and working as designed, then it will help you navigate the selection process and appeal to the company, it will help you get the job.
I’m well aware of the fears young candidates have, since I was one. Getting a job can be hard, and it might even be getting harder over time. But to me it’s also funny that software engineers looking for 6-figure salary jobs complain about interviews and competition and having to demo their skills for an hour or two. Don’t forget to look around at other industries and ask whether it’s really better over there. People in music and films and advertising and art have to grind for years, suffer low-wage or historically unpaid internships. Doctors have to do residency, grad school, and get licensed. Most people make less money, many people have to do labor. Most jobs have much bigger downsides than what we have to do in our interviews as software engineers.
We have opportunity and privilege and with the right practice and attitude and with reasonable expectations, it’s really not that hard to do well in interviews and land a good job. Many kids are hearing stories of FAANG and million dollar salaries and expecting to somehow land their first job out of school in one of the top 5 most coveted and competitive companies. I know this because I just spent a day at a university career fair a few weeks ago talking to hundreds of graduating seniors, most of whom are all expecting to shoot the moon for the same 3 jobs, and most of whom are not very eager to consider the idea of starting at a smaller company and working their way up for a few years. FAANG feels adversarial only because it’s actually legitimately super competitive, but as a candidate, figuring out how to have a non-adversarial approach is the key to getting the job. Tools like this are the opposite of what they need.
key insight. the factors influencing this are a couple I can think of. the first is just the sheer volume of applicants made possible by the internet and the mobility of workers, where you get hundreds of profiles to sort through for any job and use a coarse technical funnel to sort them. the second is we can't just pick good colleagues because the regulatory and litigation environment imposes selection criteria where we have to evaluate all these applicants equally.
these aren't justifications for the confrontational interview filter, but some upstream factors that are worth picking at to see if something better could become a solution to them.
Literally all the engineers at the company went through the same process. For all the bitching and complaining an interviewee does, there’s probably a hundred people who just went through the process and got hired.
Suck it up, it’s part of the job. If you can’t do it, you don’t belong. Simple as that.
That's actually a good point.
I believe that BigTech these days look for conformists, not superstar SWEs. If you agree to waste your time on preparation to meaningless LeetCode style interview then you are one of them and ready to be a part of the company. I do believe that is actually one of the things that being tested by such an interview, it's not a proxy for IQ, it's a proxy for candidate's readiness to eat dull corporate BS and not complain about it.
> who just went through the process and got hired.
You say that as if there's The One True Interview Routine™ and it doesn't change from team to team, person to person, month to month. I actually would bet that no single organization interviews with the consistency you're describing, not even FAANG with their holier-than-thou grinders
If it wasn't such a monster drain on human productivity, I think it'd be funny if there was "rolling interviews" where each new hire got to send prior hires though "the process" on the yearly anniversary of those prior hires
I’m reasonably certain that I interviewed someone using this or something like it in the last few days.
Lots of eye scanning while looking above the window they’d been typing into. Pauses. Big pastes. One of my excellent colleagues noticed that the candidate made use of exciting C++ casts before ever defining the variable’s types. Complete inability to explain or debug the code just written.
So. Frustrating in two dimensions. First a waste of time for everyone. Second, occasional signs of real ability make me think the candidate might’ve made it work honestly. The fool.
This, and this alone, makes me pine for in-person interviews. But I suspect those won’t be back for some time. (For good reasons that are out of scope here.)
It sounds like you want sympathy but it just shows that some people just don't understand the power dynamics of an interview.
I believe live coding is a scourge and we should get rid of it altogether.
Get a tiny open ended project, which requires more design/architecture skills than actually finishing the solution. You do it at your own time and shouldn't take more than 1-2h. You submit it and provide your mental process in writing.
We then hop on a call and we can dicuss it further, talking about possible issues and what to do to get it released if a requirement changed last minute.
If you can do that, come across amicable, knowledgeable and experienced enough given the seniority of the role, and feel like you are not reading from an hidden ai window then you pass.
"Exciting casts" are absolutely worthless in real life, everyone has to balance shipping vs code artistry.
> I believe live coding is a scourge and we should get rid of it altogether.
I would take an hour of live coding any time over a take-home task that is one hour only on paper and takes you three in reality.
Engineering is collaboration, and it's fair to expect candidates to talk, solve problems, and explain their solutions.
Where we could do better as an industry is the type of problems we give to people. I'm not a fan of LeetCode-style questions, especially when multiple ones are asked. Something closer to Earth would be better. But even if you have to ask something algorithmical, I'd prefer the style of "Advent of Code" exercises where the same problem has variations and multiple levels of complexity.
> Get a tiny open ended project, which requires more design/architecture skills than actually finishing the solution. You do it at your own time and shouldn't take more than 1-2h. You submit it and provide your mental process in writing.
I used to really like the idea of take homes, then I had kids and discovered just how hard it is to find time to do these (particularly for multiple applications while working).
Don't get me wrong, I think that they're generally a better test for the actual role, but they're not perfect, and they're game-able by spending way more time on them.
Interviewing is hard. Like, ideally, we'd just centralise the administration of these tests and you'd do a few every year (so formal CPD rather than an expectation that people do it in their off time) but that is never gonna happen in the tech industry for various good and bad reasons.
Your comment is excessively dismissive. The irony is that parent actually did what you’re suggesting, tried to talk about the interviewee’s solution and found that they didn’t come across as knowledgeable and experienced enough even though their code suggested otherwise. Whether it’s live coding or take-home is mostly irrelevant.
Your proposed alternative is absolutely subject to the same problem, AI-written code and LLM-written mental process. Think more carefully about whether it solves anything and exactly what problem it solves, because it does not solve the problem of people trying to game interviews with AI, your suggestion is potentially worse on that axis. The whole point of doing it live is to get to the talking part that you suggested more quickly.
Wouldn’t you rather be discussing your thinking immediately and get a sense for what the real questions are and how you’re doing, and have the opportunity to talk about it, than waste several hours doing it at home trying to write something up without getting clues along the way or being able to ask questions, only to have the next guy get hired because they used AI, or because they’re fine with live coding, or because they’re better at writing than coding, or because they got lucky?
You have to live code on the job. Do take a moment to consider what the hiring manager needs and whether take-home problems are either more effective or more efficient for the company. Managers want to find the best candidates, and best involves more than coding, it involves communication and collaboration skills too. Live coding can give some indicators of those things, and take-home problems cannot.
The core issue here is the sheer volume of applicants. Microsoft opened 30 new-grad software engineering positions. Care to guess how many applications they got within 24 hours? 1,000? 10,000?
Nope.
100,000 applications. In under a single day.
With that kind of applicant pool, I’m honestly not sure what the best approach is—even though, in a perfect world, your suggestion would be the more appropriate route. The reality, however, is that these numbers are just absurd.
I did that for my previous job and I loved it. Had plenty of time to get over my nerves and then build something cool. And then brag about my choices in writing.
Absolutely not. In my standard intro material I explicitly say otherwise, tell them that actual work involves checking external references, and that I want the interview to be as near to a collaborative experience as it can be in the odd circumstances.
I also tell them that they should tell me when they're checking external resources (the CPP reference is what I mostly have in mind, but StackOverflow or whatever is fine with me) so that I understand how they go about solving problems. Because that's the actual important bit. All the coding and the questioning is a proxy for that.
Why bother with this style of interview where the candidate is under extreme time pressure and isn’t allowed to use any of the research tools they would normally use in their job? What is this controlling for?
It barely made sense when these were conducted in person, and it’s completely inane over video meeting.
Instead of grilling people, talk to them. Give them meaningful take-home exercises that you can discuss together during the interview. If they can explain the decisions they made and discuss alternatives and trade-offs, that’s a much better indicator of job performance than pretending to invent a leetcode party trick algorithm in 10 minutes.
Live interviews control for wasting the candidate time in a way that take home exercises don't.
Both the candidate and the interviewer need to take time out of their day for the interview. If it's an in-person interview, the candidate also takes travel time etc, which could be more disruptive.
But it takes almost no time to give a take home problem, so there's potential for a significant assymetry in time spent between candidate and employer.
I let candidates use the Internet (except AI tools) during coding interviews. All I care is if given a problem can they do the necessary research to solve it. It usually involves making them use a library which they are not already familiar with. This is more than enough for most of the programming jobs.
How do you find an apartment rental in a large city with thousands of options?
You can’t expect to visit them all. And you certainly can’t come up with increasingly bizarre torture tests for landlords to pass (“I might rent from you if you can answer enough trick questions about tenant law within 15 minutes”).
To find the apartment, you probably sample enough of the options to form a picture of what’s available, and then make a decision knowing that you didn’t have perfect information but you had to move ahead. The same applies to hiring.
Just in case this repo isn't a joke and some job seekers are seriously thinking of this tactic...
Companies already know about cheat methods like this and candidates still have to demonstrate skills in-person on a whiteboard in a 2nd round of tech interviews.
A high-paying FAANG job isn't going to hire candidates based on just one remote Zoom tech interview.
That still may not deter some folks and they'll try to continue to find some cheating technique to use in front of the whiteboard. In that case, some creativity is going to be required. E.g. : https://www.google.com/search?q=chess+cheating+anal+beads
The issue is that "chess board moves" is very low bandwidth and can be efficiently encoded into pseudo-quasi- Morse Code vibration schemes. However, if you're asked to "invert a binary tree" or any other open-ended random puzzles, it's more difficult to compress a secret 2-way high-bandwidth communication with ChatGPT into a hidden butt plug. (But then again, if a candidate is actually able to fool people with hidden ChatGPT hacks in a face-to-face interview, maybe FAANG should hire them based on that alone.)
Keep on the lookout for a github repo with ChatGPT butt-plug communication.
FAANG jobs absolutely hire engineers over zoom. It’s not just one interview, but the whole process is done remotely over video. It typically includes somewhere between 5 to 10 sessions covering coding, architecture and behavioral.
Source - work at a FANG which engineers exclusively via remote video call.
The problem today is not that to get into FAANG you've got to jump through hoops and loops like a well-trained cage animal (aka fresh graduate) but that this is getting applied more and more to literally any startup under the sun, even some with 0 funding.
As a first engineer for a tiny startup, show me some past projects and let's grab a (virtual) coffee talking tech, that's all.
Now it's like McDonald's requesting to perform Michelin level dishes under 45 minutes with Gordon Ramsey in the room while still ending up flipping burgers minimum wage at the end of it all.
If this keeps going and getting worse, I wouldn't mind a butt-plug communication, as long as I can pick my favourite AI (I personally kind of prefer Claude right now over ChatGPT.)
“Flipping burgers…”. This made me laugh because it is so true. My last involvement in interviewing candidates was for a position for an ETL developer. One of the other team members who was part of the interviewer schedule proudly announced that he had discovered a great source of tricky SQL puzzles that he intended to use. My comments were along the lines of “you do you, but I’m more interested in how someone would generally approach the 3 or 4 categories of tasks they will be routinely doing day-to-day”.
even if its not an app, everything is so cheap and small now, 1mm camera and microphone, and very tiny ear piece (invisible with longer hair), or even earless headphones, realtime whisper turbo and groq llama3.3 can absolutely pass most interviews and answer most questions
even without the tech, i am sure people are now cheating on face to face interviews as well
i worked at fairly big company, and did maybe 500 interviews, i never knew how the candidate would look in advance, so i dont see why cant someone else shows up to the interview, pass it and then the real person shows up for the job
>What do you think they do? One round of interviews was enough for my Google recruiter to congratulate me on getting a job there.
Your Google interview process might be different because you've previously said you were ex-FAANG from 2000s so your work history and street credibility puts you in the "experienced senior hire" bucket. The interview process may be different for that type of candidate.
My recent college grad friend's process went like this (2022 so post-COVID):
- an offsite remote interview over Google Meet using Google Docs as coding canvas. 45-minutes long
- 5 onsite interviews on same day: 4 technical and 1 behavioral
The in-person whiteboard interviews isn’t always a thing for all SDE rounds, but def there for SDE-2 and above I guess. Still, it’s just a matter of time before this is also solved.
I empathize with new grads. It can be hard to stand out especially at the beginning of your career.
But I predict this won’t do what the authors claim: it won’t fix anything, and it won’t change technical interviews that much. At most it might increase the number of companies that require remote candidates to fly in and interview in person to do the same practical coding problems they used to do online. Which would be the standard from just a few years ago, anyway.
Practical coding problems (also known as work simulation interviews) are the most effective and least biased tools available for evaluating candidates. Not every hiring manager does a good job using these tools, but if you see misuse, take it as a sign that the manager might not be good to work for.
I have trouble understanding the authors thinking here that anything would be worth the cost of this: it’s a trust-busting tool where people are deceiving their potential employer. Trust is foundational to everything, in work and in life. We need more trust in our society, not less.
Had something in the works when I first got to know about multimodal GPT and electron made it super simple to prototype something. Refined it a bit to even do the invisible window thing after feedback from my peers. Didn’t have the ahem courage to do it.
Also recently noticed there are actual companies around this space who are marketing this off as “interview assistance”. Two of them I’m aware of:
I’m sure the knee-jerk reaction from the tech industry to these tools would be:
1. Return to in-person interviews
2. Force install spyware/vanguard like crap to scan your whole personal computer before doing the interview
If you are a tech leader/senior engineer with influence on these matters, I *HOPE*, that this is not the path you take. It’s high time FAANG and others stop gatekeeping with these useless rounds that are equivalent to forcing people to hand-solve complex math equations instead of using calculators. I also partly blame the YT influencers who keep peddling this BS but they will stop if the companies themselves take a stance.
You can rather use the same 1 hour slots to have a conversation, pair program on a realistic problem required for the role you’re hiring for where you and the interviewee can both benefit from the knowledge transfer. I’ve tried this in many of the interviews I’ve conducted and always went away learning something from an excellent candidate or a candidate who didn’t meet the expectations, going out knowing where they fall short.
> 2. Force install spyware/vanguard like crap to scan your whole personal computer before doing the interview
People who professionally cheat on online exams just use an HDMI splitter/capture card to inject whatever image they need using a second computer. It’s a lost game.
For offline interviews there are hidden earpieces etc.
> If you are a tech leader/senior engineer with influence on these matters, I HOPE, that this is not the path you take.
On-site interviews should be the standard path to take to detect the frauds and cheaters before they become potential bad hires.
Online technical assessments now have little added value given that AI tools like finalround.ai, etc just make it easy for frauds to cheat the technical interview.
This is actually a strong argument to a return to on-site interviews and should just draw the line on this and detect the frauds altogether.
I might be calling obvious but if candidate uses something like this, is this not lying to potential employer?
I'd rather be rejected than got job I'm not qualified to do, that's why I never prepare for interview above studying the actual company- and that is more to give me proper signal if I want to work for them, I want to be motivated to make move on more than just money.
I also have never done leetcode, though I like competitive programming problems, especially bot programming contests on codingame.com
> I'd rather be rejected than got job I'm not qualified to do
As many people have pointed out, the interview process has diverged from real-world, day-to-day tasks you would be expected to accomplish once you get the job. Not actually being able to do a leetcode test (either due to lacking knowledge or interview stress) might not have any reflection on someones ability to succeed in the role they are interviewing for. How many people are dealing with sorting algorithms or traversing binary trees without access to the internet as part of their job?
> that's why I never prepare for interview above studying the actual company
You and me both. I just read a bit about the company before applying for the job. In the interview, I ask the interviewer only two questions: what’s the management style? Is it a servant leadership style with autonomous work, or is it a hierarchical task-based one? The second question is, what does an average day-to-day job look like? Sure, there are few stressful days and others are relaxed, but on average you can tell. Is it chaotic, always running against deadlines and having new tasks thrown at you, or is everything sorted out properly? Sometimes, I also ask about the meetings. I personally don’t like useless meetings. A lot of middle management uses meetings as part of the power dynamics and exerting power rather than actually discussing and solving issues.
Of course I would also want the information from your second question, but it never occurred to me that asking directly would get me that information. I guess if it's a leaf node they might just tell you the truth, but in general you'd expect the interviewer to say what they think you want to hear wouldn't you?
Readit News
Require a formal degree in CS? That's gatekeeping.
Need to pass a whiteboard exam? Not representative of the actual work.
Live coding session? Biased against people who don't perform well under pressure.
Take home project? It's too much work to do for free.
Showcase a personal portfolio? Not fair to people with families or other obligations.
Either you enforce a minimal level of competency upfront in the form of an academic degree, industry-standard exams such as a PE Exam, etc. OR you push the entire responsibility of vetting prospective applicants downstream to the employer—which is exactly why interviews are multiple week long gauntlets.
The tech world likes to complain about all of this but other occupations 100% DO have high standards - it's just that it's paid up-front.
Want to become a lawyer? - You've got to pass the LSAT, get into law school, and pass the bar.
Want to become a doctor? - You've got to pass the MCAT, get into medical school, and do residency.
Want to become a pilot? - You've got to get your PPL, pass your check ride, do your IFR, multi-engine, commercial rating, ATP
God there are some days that I ABSOLUTELY HATE THIS INDUSTRY.
Take home projects and personal portfolios are the options that are the best. Those are the ones where candidates are given the time to show their best work and don't require the debt of a college degree in a specific major (whose knowledge is probably largely irrelevant to your day-to-day coding).
If someone uses AI to defeat a CAPTCHA, does that mean the CAPTCHA was poorly designed because "the bot is just as valid a user as any human"? Of course not - the CAPTCHA's entire purpose was to establish that correlation between "can solve this" and "is human," and breaking that correlation through automated tools defeats its purpose entirely.
In my experience if a problem simple enough to be completed in an hour, it’s simple enough for AI.
That said, I also don’t know how to adequately test, other than to carefully watch people’s eyes during questions; even that isn’t foolproof.
Over the years I've interviewed many people for technical positions and there are many ways of getting to the core of a prospective employee's competence.
Of course there are questions about training, past experience, qualifications and those about the work you expect them to perform but other matters also enter the equation and they're almost as important (the person's demeanor, confidence, etc.). By letting the person do most of the talking—explaining things about themselves and their work—you can learn a great deal.
Stating the obvious, interviewers ought to be on top of the job they're hiring for but from this story and from other anecdotal info I know that's not always so. In my case as head of the department I was pretty much up to speed on most aspects of the work, so it was clear to me when an applicant was spinning me BS. If they knew more than I did then they almost certainly got the job (life's easier when you've smart employees, for starters one can ask them questions instead of vice versa).
What's that leading up to? Well, when interviewing it was obvious to me (and to the other interviewers) within just the first few minutes whether the person was worth considering. It's uncanny how good one can become at doing this (and my record speaks for itself, I was pretty pleased with those employees I hired).
Let me illustrate with an example: some decades ago I had an applicant apply for an electronics job. He spoke only Chinese and a few broken words in English and none of us on the interview panel spoke Chinese. BTW, he turned up with a Chinese/English dictionary in hand.
I dispelled with many of the questions I usually asked and showed him a somewhat complex circuit diagram with many subsections that performed very different functions (if I showed this at all then it was usually towards the end of an interview).
Within seconds of looking at the diagram he progressed logically through the processes from beginning to the end (note the processes/stages were not drawn in linear progression and consisted of many branches). He did this mainly by pointing.
It was immediately obvious to both my independent technical assessor and me that this guy knew his subject very well. The only point was a minor objection from the nontechnical employment officer who questioned if we'd manage to communicate adequately with someone who didn't speak English. I didn't see that as a significant issue.
He turned out to be an excellent employee who knew his work very well. And within six months his English was good enough not to be an issue.
In summary, if AI is a problem now then it will be more so in the future and that needs to be tackled. That said, I find it hard to accept that an experienced interviewer can't quickly cut to the core even when an interviewee puts up smoke screens and distracting noise.
Like, Popper's falsifiability it doesn't take much to knock a BS or inconsistent argument off its pedestal when one has enough data, refutability usually works well.
That said, one must always keep in mind that just because an applicant can get some things wrong it doesn't mean that he/she isn't the best person for the job. All that tells me is that I have to probe a little deeper.
Edit: asking awkward or trick questions usually ought to be avoided. An interviewee is usually already under considerable stress and can easily be flummoxed when asked them (even if they know the answers they can bind up and not spell them out).
Usually, it's immediately obvious when an interviewee doesn't know an answer to a question or is struggling with it because of stress—body language alone usually makes that abundantly clear. It's then best to gently segue to another question. If the question is really relevant to the job then one can return to it at the end of the interview when the person is more at ease. By then, it's pretty clear to the panel whether the applicant is in the running or not. If not, then do not return to the question.
Selecting people for a job is literally gatekeeping. The company has the equivalent of a gate (or perhaps an actual one), and most people are kept out of it by the fact that they are not employees or authorized visitors.
No part of would-be employee screening can be faulted for being gatekeeping; i.e. being that which it is.
I think performance under pressure is a virtue. An important job is never going to be entirely free from stress - you want somebody reliable who will take that in their stride, you don't want someone who will buckle when things get difficult.
I'm all for in-person live collaborative problem solving, be it on a whiteboard or just a discussion. You see first-hand exactly what the person has in their memory, their problem solving techniques, how quickly they get things, their communication skills, and yes, their ability to work under pressure. If done correctly and collaboratively, you get a dry-run of a real design meeting and have some feeling of what it would be like to work with the person.
Some people experience extraordinary high levels of stress in an interview setting. From your comment, I suspect that you are not one of them and might have trouble imagining what these levels of stress feel like.
At what point do you question an approach so easily gamed, or any derived metric?
No, it's biased against people who perform perfectly well (sometimes exceptionally well) under real, actual pressure. But who do not take kindly to the bullshit / theatrical pressure typical of the standard interview context, these days. And to companies that just can't tell the difference (or are under the delusion that performance in the latter category is in some way predictive of performance in the former).
Take home project? It's too much work to do for free.
It's more that the companies simply abuse the process in various callous and careless ways -- either by assigning projects with inadequate specification and/or unknown goalposts (or plainly unrealistic expectations of the actual time required, given these ambiguities); or simply assigning scores of these assignments (often automatically to every candidate who applies) when in fact they have no intention of even looking at the vast majority of the submissions.
Easily ameliorated by simply paying people for their time.
Deleted Comment
Dead Comment
What a bizarre way to begin a working relationship.
Employers demanded applications instead of resumes, so candidates used copy machines. Then they wanted block lettering, so candidates used type writers. ATS systems could search for keywords, so candidates flooded their resumes with them. Then employers allowed online applications, and the floodgates opened proper - applications from all over the world, desperate for good employment. So they made you create an account, and applicants wrote or used bots to automate it - which became site features like “Quick Apply” on LinkedIn and Indeed. Practical interviews used to be a single round for only the most senior roles, but then employers wanted everyone to be as qualified as those roles but not pay them that much, which started the cheating arms race.
Ultimately, the problem remains a glut of qualified talent demanding salaries to pay the bills, and employers who want to pay as little as possible. The two sides are adversaries by default, and few companies do the work of mending the relationship into something more cooperative.
This is the natural state of a competitive environment, and interviews will get “better” for candidates when there are more jobs than good candidates. But be careful what you wish for; if the job market gets less competitive for candidates, salaries and benefits and working conditions go with it.
While there might be some truth it to, framing it as an arms race is a mentality that will not help the average candidate, and might do them harm. Employers always have and always will want to pay as little as possible, obviously, that’s the definition of a company. But they do actually compete with each other for good talent, and they do pay a lot relative to other jobs, and some companies’ definitions of pay as little as possible is still to pay enough that employees are well compensated and don’t leave.
I hope the folks we hired are paid enough to retain because there were was absolutely no glut of talent. It was hard to find the folks we wound up hiring. There was a glut of applications, yes, but the vast majority were totally unqualified.
We're called freelance consultants. And we charge a high price for that service.
It was, by far, the most boring interview I've ever had to participate in. The leetcode problem was easy (detect if two strings are anagrams; solved with O(n) solution in < 10 LOC; then aggregate sets of anagrams). System design was easy because it is to the point that it is largely "formulaic". It feels like those rhythm games where you need to know when the trigger is coming and the pattern to hit those triggers (talk about functional requirements -> talk about non-functional requirements -> write some API routes -> draw a load balancer (because of course, there's always a load balancer) -> draw a service -> draw Redis/Memcached -> draw a database). It's comically laughable how it's just like a rhythm game at this point.
What I don't understand is why teams don't just "get to the point". A lot of times, the assessment is looking for specific notes. Why not just ask about those notes directly? A friend recently went through an interview where he was docked for not using C# `yield` when implementing an `IEnumerable`. But had the interviewer asked "What is `yield` and why would you use it?", the interviewer would have gained the same exact insight in 15 seconds with one question.
I think what's also striking is how slow orgs are to adapt their interview process to account for AI. There's a distinct lack of focus on code reviews as part of the assessment. If the future of coding is AIs for productivity, then teams should be adding code reviews into their process (check for correctness, check for defects, check for performance, check for security, etc).
"Writing code is easy, reading code is hard"
An interview based on reading, explaining and critiquing complicated code would give a better window into a candidate's skills than having them solve the kind of coding challenge that can be completed in a short interview.
Also, being able to identify which algorithms would be useful in solving a unique problem and explain what the pros & cons are would go further than implementing an algorithm abstractly.
And these are all candidates with 5+ years experience, sometimes 10+. I hate the leetcode gauntlet, but I also am really surprised how much worse candidates are now on average that they used to be (I’ve been around for about 25 years now), and how the minute you try to dig a little deeper to see if they know how things really work, the more it seems that they have no understanding whatsoever of the basics and somehow treat computers as magical black boxes.
I do understand I am privileged by having grown with the technology, starting in the 8-bit era, through an electronic engineering degree, and now in k8s etc. but with so much educational material available for free you’d think that even people in their 20s/30s now should be able to have a better idea of how things work.
if not Counter(str1) - Counter(str2): # success, they are anagrams
But the catch is... the people doing the hiring must themselves ideally be talented, energetic, skillful mentors who envisage building a positive culture.
On the other hand, from my perspective and experience on both sides of the interview table, to me it seems like the perception that this is adversarial is coming primarily from young candidates whinging on the internet in large numbers about interviews being unfair or “broken” or doing it the wrong way. Every time this comes up on HN, there are hordes of comments demanding we stop whiteboarding in interviews, or claiming anything not exactly in the job description is out of bounds, or decrying the abuse that coding live inflicts. There are blog posts every week about how to fix the problem, where the problem is usually the interviewee’s comfort, and not the company’s efficiency or effectiveness.
The truth is that companies need people, and the employees there do want new colleagues. If you truly understand that, and also that the selection process is unavoidable and working as designed, then it will help you navigate the selection process and appeal to the company, it will help you get the job.
I’m well aware of the fears young candidates have, since I was one. Getting a job can be hard, and it might even be getting harder over time. But to me it’s also funny that software engineers looking for 6-figure salary jobs complain about interviews and competition and having to demo their skills for an hour or two. Don’t forget to look around at other industries and ask whether it’s really better over there. People in music and films and advertising and art have to grind for years, suffer low-wage or historically unpaid internships. Doctors have to do residency, grad school, and get licensed. Most people make less money, many people have to do labor. Most jobs have much bigger downsides than what we have to do in our interviews as software engineers.
We have opportunity and privilege and with the right practice and attitude and with reasonable expectations, it’s really not that hard to do well in interviews and land a good job. Many kids are hearing stories of FAANG and million dollar salaries and expecting to somehow land their first job out of school in one of the top 5 most coveted and competitive companies. I know this because I just spent a day at a university career fair a few weeks ago talking to hundreds of graduating seniors, most of whom are all expecting to shoot the moon for the same 3 jobs, and most of whom are not very eager to consider the idea of starting at a smaller company and working their way up for a few years. FAANG feels adversarial only because it’s actually legitimately super competitive, but as a candidate, figuring out how to have a non-adversarial approach is the key to getting the job. Tools like this are the opposite of what they need.
these aren't justifications for the confrontational interview filter, but some upstream factors that are worth picking at to see if something better could become a solution to them.
Suck it up, it’s part of the job. If you can’t do it, you don’t belong. Simple as that.
You say that as if there's The One True Interview Routine™ and it doesn't change from team to team, person to person, month to month. I actually would bet that no single organization interviews with the consistency you're describing, not even FAANG with their holier-than-thou grinders
If it wasn't such a monster drain on human productivity, I think it'd be funny if there was "rolling interviews" where each new hire got to send prior hires though "the process" on the yearly anniversary of those prior hires
Lots of eye scanning while looking above the window they’d been typing into. Pauses. Big pastes. One of my excellent colleagues noticed that the candidate made use of exciting C++ casts before ever defining the variable’s types. Complete inability to explain or debug the code just written.
So. Frustrating in two dimensions. First a waste of time for everyone. Second, occasional signs of real ability make me think the candidate might’ve made it work honestly. The fool.
This, and this alone, makes me pine for in-person interviews. But I suspect those won’t be back for some time. (For good reasons that are out of scope here.)
I believe live coding is a scourge and we should get rid of it altogether.
Get a tiny open ended project, which requires more design/architecture skills than actually finishing the solution. You do it at your own time and shouldn't take more than 1-2h. You submit it and provide your mental process in writing.
We then hop on a call and we can dicuss it further, talking about possible issues and what to do to get it released if a requirement changed last minute.
If you can do that, come across amicable, knowledgeable and experienced enough given the seniority of the role, and feel like you are not reading from an hidden ai window then you pass.
"Exciting casts" are absolutely worthless in real life, everyone has to balance shipping vs code artistry.
I would take an hour of live coding any time over a take-home task that is one hour only on paper and takes you three in reality.
Engineering is collaboration, and it's fair to expect candidates to talk, solve problems, and explain their solutions.
Where we could do better as an industry is the type of problems we give to people. I'm not a fan of LeetCode-style questions, especially when multiple ones are asked. Something closer to Earth would be better. But even if you have to ask something algorithmical, I'd prefer the style of "Advent of Code" exercises where the same problem has variations and multiple levels of complexity.
I used to really like the idea of take homes, then I had kids and discovered just how hard it is to find time to do these (particularly for multiple applications while working).
Don't get me wrong, I think that they're generally a better test for the actual role, but they're not perfect, and they're game-able by spending way more time on them.
Interviewing is hard. Like, ideally, we'd just centralise the administration of these tests and you'd do a few every year (so formal CPD rather than an expectation that people do it in their off time) but that is never gonna happen in the tech industry for various good and bad reasons.
Your proposed alternative is absolutely subject to the same problem, AI-written code and LLM-written mental process. Think more carefully about whether it solves anything and exactly what problem it solves, because it does not solve the problem of people trying to game interviews with AI, your suggestion is potentially worse on that axis. The whole point of doing it live is to get to the talking part that you suggested more quickly.
Wouldn’t you rather be discussing your thinking immediately and get a sense for what the real questions are and how you’re doing, and have the opportunity to talk about it, than waste several hours doing it at home trying to write something up without getting clues along the way or being able to ask questions, only to have the next guy get hired because they used AI, or because they’re fine with live coding, or because they’re better at writing than coding, or because they got lucky?
You have to live code on the job. Do take a moment to consider what the hiring manager needs and whether take-home problems are either more effective or more efficient for the company. Managers want to find the best candidates, and best involves more than coding, it involves communication and collaboration skills too. Live coding can give some indicators of those things, and take-home problems cannot.
Another one I like was having to code review a repo which had specific issues in it.
Then add some new features.
Then in the final stage of the interview you go through it.
Nope.
100,000 applications. In under a single day.
With that kind of applicant pool, I’m honestly not sure what the best approach is—even though, in a perfect world, your suggestion would be the more appropriate route. The reality, however, is that these numbers are just absurd.
Dead Comment
Are you expecting people to not reference external material, such as documentation or syntax, and only code from memory?
I also tell them that they should tell me when they're checking external resources (the CPP reference is what I mostly have in mind, but StackOverflow or whatever is fine with me) so that I understand how they go about solving problems. Because that's the actual important bit. All the coding and the questioning is a proxy for that.
an example of this, please?
Deleted Comment
It barely made sense when these were conducted in person, and it’s completely inane over video meeting.
Instead of grilling people, talk to them. Give them meaningful take-home exercises that you can discuss together during the interview. If they can explain the decisions they made and discuss alternatives and trade-offs, that’s a much better indicator of job performance than pretending to invent a leetcode party trick algorithm in 10 minutes.
Both the candidate and the interviewer need to take time out of their day for the interview. If it's an in-person interview, the candidate also takes travel time etc, which could be more disruptive.
But it takes almost no time to give a take home problem, so there's potential for a significant assymetry in time spent between candidate and employer.
I let candidates use X during coding interviews.
I've personally seen this evolve over the past 20 years
Whiteboard --> Text editor --> IDE --> ...?
Maybe "AI Coding Assistant" is next.
Deleted Comment
If a company wants me to do some leetcode crap I decline the job.
How do you find an apartment rental in a large city with thousands of options?
You can’t expect to visit them all. And you certainly can’t come up with increasingly bizarre torture tests for landlords to pass (“I might rent from you if you can answer enough trick questions about tenant law within 15 minutes”).
To find the apartment, you probably sample enough of the options to form a picture of what’s available, and then make a decision knowing that you didn’t have perfect information but you had to move ahead. The same applies to hiring.
How about you hire the first 1000 people who seem competent, and then tell everyone else you've filled the roles?
Companies already know about cheat methods like this and candidates still have to demonstrate skills in-person on a whiteboard in a 2nd round of tech interviews.
A high-paying FAANG job isn't going to hire candidates based on just one remote Zoom tech interview.
That still may not deter some folks and they'll try to continue to find some cheating technique to use in front of the whiteboard. In that case, some creativity is going to be required. E.g. : https://www.google.com/search?q=chess+cheating+anal+beads
The issue is that "chess board moves" is very low bandwidth and can be efficiently encoded into pseudo-quasi- Morse Code vibration schemes. However, if you're asked to "invert a binary tree" or any other open-ended random puzzles, it's more difficult to compress a secret 2-way high-bandwidth communication with ChatGPT into a hidden butt plug. (But then again, if a candidate is actually able to fool people with hidden ChatGPT hacks in a face-to-face interview, maybe FAANG should hire them based on that alone.)
Keep on the lookout for a github repo with ChatGPT butt-plug communication.
Source - work at a FANG which engineers exclusively via remote video call.
As a first engineer for a tiny startup, show me some past projects and let's grab a (virtual) coffee talking tech, that's all.
Now it's like McDonald's requesting to perform Michelin level dishes under 45 minutes with Gordon Ramsey in the room while still ending up flipping burgers minimum wage at the end of it all.
If this keeps going and getting worse, I wouldn't mind a butt-plug communication, as long as I can pick my favourite AI (I personally kind of prefer Claude right now over ChatGPT.)
How do you expect startups to make money if you think they aren’t even legitimate to see you program during an interview?
Oh, right, you don’t care about your employer’s finances.
even if its not an app, everything is so cheap and small now, 1mm camera and microphone, and very tiny ear piece (invisible with longer hair), or even earless headphones, realtime whisper turbo and groq llama3.3 can absolutely pass most interviews and answer most questions
even without the tech, i am sure people are now cheating on face to face interviews as well
i worked at fairly big company, and did maybe 500 interviews, i never knew how the candidate would look in advance, so i dont see why cant someone else shows up to the interview, pass it and then the real person shows up for the job
What do you think they do? One round of interviews was enough for my Google recruiter to congratulate me on getting a job there.
Did I get the job? No. But the process didn't include any other interviews. There's only one round.
Your Google interview process might be different because you've previously said you were ex-FAANG from 2000s so your work history and street credibility puts you in the "experienced senior hire" bucket. The interview process may be different for that type of candidate.
My recent college grad friend's process went like this (2022 so post-COVID):
- an offsite remote interview over Google Meet using Google Docs as coding canvas. 45-minutes long
- 5 onsite interviews on same day: 4 technical and 1 behavioral
Have FAANGs gone back to real onsites? I've only see virtual onsites since the pandemic.
But I predict this won’t do what the authors claim: it won’t fix anything, and it won’t change technical interviews that much. At most it might increase the number of companies that require remote candidates to fly in and interview in person to do the same practical coding problems they used to do online. Which would be the standard from just a few years ago, anyway.
Practical coding problems (also known as work simulation interviews) are the most effective and least biased tools available for evaluating candidates. Not every hiring manager does a good job using these tools, but if you see misuse, take it as a sign that the manager might not be good to work for.
I have trouble understanding the authors thinking here that anything would be worth the cost of this: it’s a trust-busting tool where people are deceiving their potential employer. Trust is foundational to everything, in work and in life. We need more trust in our society, not less.
Had something in the works when I first got to know about multimodal GPT and electron made it super simple to prototype something. Refined it a bit to even do the invisible window thing after feedback from my peers. Didn’t have the ahem courage to do it.
Also recently noticed there are actual companies around this space who are marketing this off as “interview assistance”. Two of them I’m aware of:
1. https://www.senseicopilot.com/
2. https://www.finalroundai.com/
——
I’m sure the knee-jerk reaction from the tech industry to these tools would be:
1. Return to in-person interviews
2. Force install spyware/vanguard like crap to scan your whole personal computer before doing the interview
If you are a tech leader/senior engineer with influence on these matters, I *HOPE*, that this is not the path you take. It’s high time FAANG and others stop gatekeeping with these useless rounds that are equivalent to forcing people to hand-solve complex math equations instead of using calculators. I also partly blame the YT influencers who keep peddling this BS but they will stop if the companies themselves take a stance.
You can rather use the same 1 hour slots to have a conversation, pair program on a realistic problem required for the role you’re hiring for where you and the interviewee can both benefit from the knowledge transfer. I’ve tried this in many of the interviews I’ve conducted and always went away learning something from an excellent candidate or a candidate who didn’t meet the expectations, going out knowing where they fall short.
People who professionally cheat on online exams just use an HDMI splitter/capture card to inject whatever image they need using a second computer. It’s a lost game.
For offline interviews there are hidden earpieces etc.
On-site interviews should be the standard path to take to detect the frauds and cheaters before they become potential bad hires.
Online technical assessments now have little added value given that AI tools like finalround.ai, etc just make it easy for frauds to cheat the technical interview.
This is actually a strong argument to a return to on-site interviews and should just draw the line on this and detect the frauds altogether.
I'd rather be rejected than got job I'm not qualified to do, that's why I never prepare for interview above studying the actual company- and that is more to give me proper signal if I want to work for them, I want to be motivated to make move on more than just money.
I also have never done leetcode, though I like competitive programming problems, especially bot programming contests on codingame.com
As many people have pointed out, the interview process has diverged from real-world, day-to-day tasks you would be expected to accomplish once you get the job. Not actually being able to do a leetcode test (either due to lacking knowledge or interview stress) might not have any reflection on someones ability to succeed in the role they are interviewing for. How many people are dealing with sorting algorithms or traversing binary trees without access to the internet as part of their job?
You and me both. I just read a bit about the company before applying for the job. In the interview, I ask the interviewer only two questions: what’s the management style? Is it a servant leadership style with autonomous work, or is it a hierarchical task-based one? The second question is, what does an average day-to-day job look like? Sure, there are few stressful days and others are relaxed, but on average you can tell. Is it chaotic, always running against deadlines and having new tasks thrown at you, or is everything sorted out properly? Sometimes, I also ask about the meetings. I personally don’t like useless meetings. A lot of middle management uses meetings as part of the power dynamics and exerting power rather than actually discussing and solving issues.
It's no different than if you had a much more technically competent friend off-screen feeding you the answers.