Just talk to people. Seriously. If you're "an expert", then >80% of the time you can figure out if someone is an expert in the same topic just by talking to them. See how they think and problem solve. That's the skills they'll be using on the job anyways.
Here's the traditional engineering interview script:
Ask the candidate how they'd solve a problem you either recently solved or are currently working on. Where does their mind go? What questions do they ask? Do they make the same mistakes you made? Are they different? Do those complement one another? Are they excited?
Honestly, one of the best things to do is get people to talk about their passions. For a lot of engineers their passion is related to their work. You WANT this as a business. They'll work hard because they're having fun doing the work. They'll learn more on the side and get a lot of expertise and ideas you wouldn't have on your own. If you make the job interesting and fun, they'll stay despite offers of higher pay too! But all of that depends on managers. A good manager participates and their most important job is preventing engineers from spending too much time in rabbit holes. You need to go down some but some unravel forever and your engineer will get stuck in an infinite loop.
I’ve interviewed enough people to staff a company and I disagree.
You really really need to go through an actual code exercise with them. It’s staggering how many people I’ve interviewed who can talk the talk but when confronted with with a 50 line class full of glaring issues for a code review exercise, they can’t find any of the actual problems. The great thing about it is that the good people will spot the super obvious ones in about 5 seconds and you can just move on from it very quickly.
We’re talking c++ programmers with a decade of experience not spotting basic RAII, missing pointer checks and straight up logic bugs for the domain that we interview for and hire in (games).
I came across a version of a "just talking" interview which did work. You asked them to provide bring in a representative body of their code to the interview. During the interview, you ask them to give you any overview of what the project was supposed to do, how well it worked, what they would change in retrospect. As they do so you're scanning it looking for interesting or quirky bits. Then you ask them to explain the reasoning behind those particular lines in detail.
This lets you get a feel for their coding style, comments, unit testing and so on. The "explain why you did it the quirky way" is for proof of authorship. You may learn something from it as well.
It's a bit of work for interviewer, but far less stressful for the applicant than coding tests. But it's easier for the interviewer in some ways too, as you don't need conversation starters - the "tell me about this project" step is a perfect way to find out about their previous experience.
As you say, the charlatans are very good. I even tried bring in sales, with explicit instructions that their job was to spot the bullshitter. They were no better at it than we engineers.
I didn't say "no code" and I'm definitely not against some screener type of questions. But I am against having 6 rounds of interviewing and at least 3 of those being coding challenges where there's right answers to be gamified and made into a website or book for people to pay to memorize.
I wonder how many of them would do fine not under pressure though. You're not (necessarily) weeding out experienced people who can't find actual problems in a 50 line class full of glaring issues, you're weeding out those who can't under pressure in an interview setting.
I like these types of interview problems. I did one in Python once. We also had it so that persistence to Postgres indicated that the DB was in a very de-normalized state, so they could comment on that for bonus points.
I had one of those "spot the issues" quizzes on an interview once. I didn't do that well on it just because I was nervous as hell. In retrospect, it was a good thing they didn't want to hire me. But it was a dumb request to place on someone "hey look at this class from our codebase and tell us what's wrong with it!" I'm thinking: "Should I just praise how good it is? What are they asking me here?"
> when confronted with with a 50 line class full of glaring issues
Would this work with any language other than C++? In almost every other language the only ways the code can actually be broken is if there's undefined variables or something. Sure, any language can have logic bugs, but that would require more than 50 lines to be certain of.
I mean, even if the code says something like `total /= 0`, yeah, it looks wrong, but, I'm not 100% certain it's wrong with just 50 lines of context.
Were these programmers lying about their decades of experience? Or did they really get by with writing broken C++ all those years without knowing the basics? What a language! I think C++ is a special case when it comes to interviews.
I agree. I've interviewed loads of people, without ever giving a job to someone who couldn't do the work.
I just have a deep technical conversation. If they run out of things to say, they are not right for the job. They run out of BS, because I keep the conversation on specific things that you can't make up, yet keep it open enough that you have to bring your own experience.
That's it, (spoiler alert!) it's like the great reveal in Kung Fu Panda.
> For a lot of engineers their passion is related to their work.
This is the guy you find with this method. He can talk forever, because he loves what he does and can't not keep doing it.
No my passion isn’t my job. I have a long list of things I do for fun. Sitting at a computer is not one of them. My job is transactional - an exchange of labor for money.
I can’t exchange “passion” for food clothes or shelter.
I’m 51 now and can afford to choose work life balance over money. But if I were younger and it’s advice I give all younger graduates in CS is to “grind leetCode and work for a FAANG (or equivalent paying company)” and by pay I mean cash and RSUs in publicly traded companies not “equity” that will statistically be worthless.
If you’re in an interview, you’ve already agreed to an hour of your time talking to someone. Few technical interviewers expect their problem to be your passion. But I think it’s concerning if you can’t show interest in a specific problem and have a good technical discussion about solutions for an hour.
That's cool and all but you do realize that with this attitude you really need to blow interviewer's socks off with how good you are or be like really really cheap, right? Especially in this market. Probably not the best advice to median candidate applying...
individual manager discretion produces widely variable outcomes at scale, a lot of (most?) managers are promoted “by default” because the company is growing quickly, or lost a key person, and there is no better choice available, and it would be hard work to go find and recruit a better choice and nobody wants to do that work. So we add process and structure to help underqualified personnel not totally screw it up, which produces fine results for a while until hierarchy and process gets too heavy and marginal returns start to decay, and viola. Leetcode and AI screening.
This would be a nice explanation if my last round of interviewing with a few big tech companies didn't involve interviewing with technical people. In fact, except for the first phone screening interview I exclusively interviewed with technical people.
But if you need someone to show up and code every day, you also need someone who is willing and able to do that. I don’t think a passionate chat can demonstrate that.
Probably unpopular opinion on this forum but with this strategy you'll quickly realize that nobody who's applying is an expert and then you're back to basically testing for iq which is what your typical interview challenges are actually doing
Everyone calls them Interviews but they are not really interviews. They are exams.
Oral exams, live coding exams, system architecture exams, take-home exams, behavioral examinations, code review exams, extended essay writing exams, case study exams, sample work trials.
You can't be a real professional if you have to take exams in every job change.
In serious professions, people take exams early in their careers for being certified. Sometimes they take additional exams to renew their certificates. And that's all.
They don't take exams from random people in random companies that know nothing about evaluating knowledge. They take official, standardized exams prepared by professional testers/educators.
Engineering jobs can't be standardized. Engineering and required skills and knowledge is too broad for that.
An interview is not an exam. It's a meeting. The interviewer asks questions to learn about the candidate. The interviewer may ask some questions to learn about the company and the position. That's all. That's the universal definition of a job interview. All the other things are additional tests and exams.
Do they need to do those exams for better selection? Probably not. Their "hiring process"es are not backed by any science. Then why are they doing that? They have to filter somehow. If there are 1 to 100s ratio of candidates for each position, they need to filter hard. Exams are the standard method for ranking and filtering.
Indeed, and ridiculous exams at that. Imagine being at school and they had a several question exam from anything across a four year degree. No information on what area to focus on, because there’s no focus on purpose.
Quarter of a million dollars in a suitcase, loaded gun, and a copper ticking clock on the table next to you. Picture of your kids that need new school clothes.
Miss one question and you fail. Must also be confident, friendly, and not too old while doing it.
—> “I can’t find anyone that can pass my simple test, they must all be frauds.”
This is not how proper exams work, and for good reason.
> In serious professions, people take exams early in their careers for being certified. Sometimes they take additional exams to renew their certificates. And that's all.
The field of programming emerged from mathematics, not engineering unfortunately. So we lack any useful certification processes.
At many schools, CS departments emerged from Electrical Engineering departments. Some (MIT, Berkeley, ...) even have a combined EECS department, while others (Stanford) are part of the school of engineering.
However, it does not seem to be common practice for computing professionals to acquire professional engineering certification. (Perhaps graduation from an accredited program is considered to be equivalent?)
There do seem to be Professional Engineer (PE) certifications for computer engineering at least:
The only issue is that Software Engineering (is that the term we use?) does have more churn and change than other types that have PEs like Civil.
Not saying it’s not possible to focus on fundamentals that have only changed superficially in decades (like the networking stack or data structures), but it is more difficult in this field.
I don't mean to be harsh, but as an engineer you owe it to yourself to try and get better at interviewing. Does it suck? Yeah absolutely. Is it an annoying process? Definitely. But even if you have an easy and stable job things can change quickly at any company. You're only closing doors on yourself.
If you get nervous, the main thing you can do is more interviews. My personal anxiety peaks right before the start time, luckily my bathroom is next door to my office! But after doing dozens of interviews I settle in once it gets rolling.
If you hate leetcode, well just get good at it. Yeah it is kinda dumb but it is straightforward to practice. And there is a lot more to a leetcode interview than knowing tricks - you need to communicate well.
Take homes? Yeah they are time consuming. If you really need a job do them, otherwise pass on the company!
Overall as a candidate you really need to try and go one level up on selling yourself - not just why you are a great candidate (which you are of course!), but why you would succeed at this role in particular.
I'm happy to provide feedback for anyone reading this - Mock interviews or code challenge reviews. No guarantee it's helpful but I'm not a black hole at least!
Yeah companies generally won't provide feedback, there is no benefit to them and many times candidates will just argue about it anyways.
For better feedback there are some good mock interview companies out there, or you can ask a friend or mentor. I've also had really good luck just talking to Gemini/Chat GPT.
Not a huge AI guy but this is something LLMs can do quite well (less so before gpt-5 because that model was a sycophant) but I learned a lot about personality interviews by simply having the AI throw questions at me and then taking my answers apart.
I disagree. I know when I get questions right, or can't do them. In my experience, either I screwed up a question and legit didn't get the job, or I was fine and the interview process is just a bit random. Sometimes it's the interviewer's fault for asking bad questions. Most commonly it's: "how do you light a fire?" "with a match" "but you don't have any matches" "a lighter" "no lighter either" "flint" "no flint" "stick and bow" "all the wood around you is wet" "I give up" "you use a magnifying glass of course!"
You can actually ask for feedback and usually they'll give it. In the EU they have to tell you what they wrote about you in their internal system under GDPR (or at least my company's lawyers believed that)!
The one time I got really great feedback unprompted from a hiring guy it was basically "they were disappointed you didn't know X" and I was like "weird, I do know X!". Very interesting to see it from the other side but I don't think it was very actionable.
As much as I dislike leetcode style interviews, if I fail one of those, I learn what I can and move on.
Failing a take-home is an entirely different thing. It's a huge loss in time and mental energy.
I've only done 3 of those in my career and only because the projects sounded interesting. 1 of those 3 resulted in a job offer which I can now confidently say in hindsight was the worst job in my career (...so far!).
I'm now leaning towards just filtering out companies that do take-homes because it signals to me that they don't care about their candidate's time and how a company treats its candidates is usually a good indicator of how they treat their employees.
I've had the complete opposite experience, and feel the complete opposite way. What is there to learn from failing a leetcode? It feels like luck of the draw - I didn't study that specific problem type and so failed. Also, there is an up front cost of several months to cover and study a wide array of leetcode problems.
With a take home I can demonstrate how I would perform at work. I can sit on it, think things over in my head, come up with an attack plan and execute it. I can demonstrate how I think about problems and my own value more clearly. Using a take home as a test is indicative to me that a company cares a bit more about its hiring pipeline and is being careful not to put candidates under arbitrary pressures.
Would you rather do 10 take-homes or 10 leetcode questions?
Either way, when you fail, chances are that you will not get any meaningful feedback other than "we have decided to move forward with other candidates".
If you had done a take-home, how could you know where you went wrong?
If you had done a leetcode question, you can look up the question after the interview and usually learn from your mistakes.
With leetcode you usually don't need the interviewer's feedback to improve. You don't even need the interview. And after a certain point you won't need that much time to prepare.
I feel the complete and total opposite. With leetcode-esque ones it's just a luck of the draw that you can conjure up the memory for whatever it is they're asking you to do. The decent ones are the ones that at least are somewhat realistic, but the truly terrible ones are those where you have to remember how to do an algo of some sort but you have no access to outside tools of any kind. I've never come out of a leetcode and felt like I learned anything or could've done something better, not to mention the artificially crafted high stress environment. I feel like they also literally never reflect anything even approaching the actual work, either, and basically test your memory more than anything else. There's a reason there's a billion books out there about how to "crack" the leetcode style interviews.
On the other hand, with takehomes I get to approach a project as if it were my own little hobby thing. I get to approach it in ways that are comfortable for me to work, with my music on, in my own editor, on my own setup, with no time pressure (or at least very light time pressure, just like during the actual job). I always use it as an opportunity to try out something new as well, so I'm also learning in the process even if I don't get the job. And in my experience even when rejected, I've always gotten detailed feedback for areas of improvement, which has never happened in leetcode interviews for me.
With all those leetcode acers, why is software slow as molasses? You would think they pattern match for the most efficient algo with all this training.
In my experience the more impressive somebody is at leet code, the worse their production code. Full of bugs, no error handling. Assuming the inputs never stray from the happy path.
Not saying it's always the case of course. But I did interview almost 400 people over my career.
On the other hand, most people cannot code to save their life. So I have no answers. Only more questions.
Interviews need to give signal to the employer. Having a couple decades experience now, working high scale, highly available services, and having designed interviews for thousands of candidates and given hundreds of interviews across half a dozen software engineering orgs, leetcode is poor signal.
Good signals comes from questions that uncover attributes that will grow your team snd fill deficits.
The best method yet for a technical interview is a work sample test based on recent work actually performed by the team. I've never encountered a leetcode problem in the wild. Data structures and algorithms, of course. Leetcode? Nope.
But leetcode is easy to administer and someone else already wrote the question. The big companies don't even try to differentiate between those who clearly have practiced the given leetcode problem type vs someone who derives a solution by working the problem.
I don't get it, every job I have interviewed for since 2013 has had a take home. A couple of them waived it in my case but otherwise they all had take homes. Where are these jobs where people don't get given take homes?
When you are rapidly hiring, giving a candidate 2 weeks to complete a take home is a huge drag on the process. Instead, sandwiching 3 interviews (resume walk, leetcode, system design) into a 3 hour time period lets candidates move through the process faster.
I can't speak to developer roles specifically. But the last job I had (for a long time), I just dropped an email to someone who was a client. I think a fair number of the developers at the company came through internships or referrals and AFAIK takehomes weren't a thing.
The problem is that the more we go in that direction, the more hiring in this industry rewards gamifying and grinding, and that bleeds into the profession as a whole. And at that point it’s just not worth working there
What if it's an appropriately scoped take-home assignment? 1-2 hours max. I would say that's fair and gives people with interview anxiety more of a chance.
> interviews should: be applicable. reflect the actual job duties
No, it doesn't matter that much what task the candidate is doing in the interview. It matters what the interviewer is looking at. I'm sure plenty of interviewers don't understand this, and I think this is often missed when people debate about Leetcode interviews - including in this article.
> most interview questions have very little to do with day-to-day responsibilities
You're missing what the interview questions are. Yes, one part of the interview is "here is a puzzle, can you solve it?", but many of the other questions should be things like "explain why this doesn't work", "why did you start with this approach?" and "are you sure that is the best name for that function?"
Leetcode interviews are perfectly "applicable", as long as the interviewer is using them as a convenient frame to see how you think, communicate, and write/read/edit code and isn't trying purely to assess your skill at quickly solving leetcode puzzles.
> cannot distinguish a senior programmer from a marketer using chatGPT
This is empirically false, because companies haven't suddenly lost all their hiring signal since ChatGPT came out. But if a company has this problem, they suck at interviewing.
(I admit the style of interviewing I'm describing has its own problems, and in particular doesn't address what I think is the biggest issue: the fact you're partly testing people's ability to (appear to) perform under acute pressure.)
The problem with leetcode is time. If you know a good solution to a puzzle, or can instantly come up with it, you have the time to write it down, make it work, discuss, improve, etc. If you spend extra 10 minutes on a wrong approach, you're very strained, and if you spend 15 minutes, you're toast.
But knowing the good solution by heart is not the point! For that reason, when I ran code interviews, I often gave hints to the candidate, or sometimes just stated that a particular algorithm is a good solution, and it's usually implemented using this and that. ("Use BFS. You'll need a queue.")
This is where the demand for realistic conditions kicks in: at work, you're not going to invent an algorithm, you'll ask the machine what works in a situation like yours, consider, and choose. Doing otherwise would be imprudent.
> but many of the other questions should be things like "explain why this doesn't work", "why did you start with this approach?" and "are you sure that is the best name for that function?"
This is important and something more interviewers should do. The blind adherence to leetcode doesn't tell you much, especially if you're silent during the interview instead of having a short back-and-forth every 15 minutes or so. The problem solving process is more important than the problem solved.
>you're partly testing people's ability to (appear to) perform under acute pressure
You are also testing people's endurance. I once did an on-site interview with Google, and it was a solid 6 hours of leet-style puzzles, one after the other.
> I admit the style of interviewing I'm describing has its own problems
We need to be clear, ALL styles of interviewing has problems. There's no global optima for problems like this. It's important to say this because people will point out problems as reasons not to switch while ignoring the existing ones. The answer entirely depends on "what are you optimizing for?" Be precise
Also worth pointing out, the style you describe is the traditional engineering interview. Leetcode type problems were initially done this way. It is also easy to make an effective system worse by trying to improve it. This often happens by trying to apply hard metrics to noisy problems. You don't improve your accuracy, you are just fitting a certain type of noise better (and encouraging Goodhart's Law).
> companies often over-index on crystallized knowledge over fluid intelligence.
another way to say this: focus on aptitude. in my hiring funnel, this is a core tenet. you need to be able to capture polyglots and systems thinkers. its still pretty hard to design a process that balances this all very well. combine that with an absolute glut of applicants and you have a very challenging problem.
i am a data engineer (2 yoe) who speaks multiple languages and thinks in systems. i am looking to switch jobs as the problems i work on at my job are not as interesting as i would hope. also i am underpaid. can you point me to your hiring funnel?
2. At home coding challenge. Candidates can pick one from 2 coding challenges. But we try to keep them engaging and fun, but still complex in details. Sometimes people don’t want to invest this time. That’s acceptable, but in this case you have to show os some of your work from the past, so we can discuss this.
3. Interview with 2 engineers from the team. We are doing coding challenges as a base for this interview. It’s just a way to get people talking with each other on technology and how they work.
4. Make an offer or say no to the candidate. Everyone involved in this process from our side has a veto right. So if one person says no - it’s a No.
5. Send contract to the candidate, if they accept the offer. This is the first time in the process where HR is involved. Everything else before was done by the Dev Team.
I think this is the most important part, show respect by taking care of the process by yourself and communicating with the candidate.
When does the CTO has time to be the first unit in the pipeline? How much applicants do you have?
From our experience just posting a junior web developer job gets up to 1000 resumes into our inbox. And we just a small company without an established name.
The only possible first step for us is to automatically send everyone an at home coding challenge. This narrows down the list to only about 50 developers that would reply. Only 10 of them would send working code. And only at that point we can actually start to interview.
I won't do a coding challenge unless you do mine too. Don't they always say interviewing should be mutual evaluation?
Here's the deal: You give me your standard coding challenge, then we reverse roles for an equivalent one I prepared. We do this for the full interview duration.
If you can't solve mine, that tells us something important about the technical bar at your company. After all, if coding puzzles are truly predictive of job performance and essential for determining candidate quality, then presumably everyone on your team, and especially those making hiring decisions should excel at them... ;-)
If your coding challenges are going to determine my professional future, and your company claims it only hires "the best," then you should have zero problem demonstrating that same level of excellence. I wouldn't want to work somewhere where the interviewers can't meet the standards they are imposing on candidates.
Either these challenges are meaningful indicators of ability (in which case you should welcome the chance to prove your team's competence), or they are arbitrary hoops and in that case, why are we doing this?
I'd be totally down with that! I always hated Codility, but before I gave them out to candidates I wrote my own version of it, usually in a language I wasn't as familiar with. I got several takedown notices from github because I posted my solutions on my personal account! Seems Codility didn't take kindly to that at all!
I honestly disagree with the veto right because it makes it too easy to be abused. In my opinion, a supermajority (66% or even 75%) agreement should be sufficient.
They said that Liberum Veto rotted the Polish-Lithuanian parliament.
What worked best in my experience is having a roundtable discussion between all the interviewers about their experience, and any concerns or objections they have. i.e. soft veto.
The hiring manager had the ultimate say, though. But he/she had to acknowledge, address, and own any objection and take personal responsibility for it if the candidate was hired.
When you have a good team who is earnestly focused on preserving a good team, it works really well. Red flag objections were pretty much never ignored, and were effectively vetoes. Minor objections or slight concerns about experience or aptitude, if they were overridden, prompted hiring managers to take extra time and care to help ensure the new hire's success.
I won't do an at home coding challenge, that is, unless you pay me. It's not about time investment, it is that we need to respect one another. You also have to realize a lot of places will use these "challenges" to get free work done. I'm sure this isn't what you're doing, but how is the person interviewing supposed to know? It is definitely a red flag. Built from good intentions, but a red flag nonetheless.
Personally I love take home challenges because I can destress compared to coding in front of someone and I can prove what I’m made of. Got me jobs that has. It’s a part of life.
It seems fair and appropriate to pay applicants (or employees for that matter) to compensate them for the additional time required for a take-home assignment, even if it's not actual production work for the company.
(I do the interviews at our company, but I'm just a regular dev and not in management or HR or anything like that)
I get where you're coming from, and I've tried to fight to get people paid to do our take homes because I also feel it's only fair if we're expecting them to spend ~3 hours of their own time, but you also end up in situations where people will do the interviews just for the money. We had a small trial run with a pretty laughable sum, something like 40 bucks just to test the waters and see how people reacted (this was for a very high paying role, mind you), and we got a staggering amount of people who clearly didn't care at all about the role and just wanted the free money. Like literally would just post a link to a random repo or whatever, completely unrelated to the takehome, and you as the company don't really want to be in the situation where you argue with candidates about what constitutes a "real assignment" for the purposes of payment.
It's one of those situations where a handful of dickheads can ruin a good thing for the decent folk.
At least personally, I dedicate as much time to reviewing the takehomes as the candidates themselves put in. I write extremely detailed feedback covering every single line they present us and we supply that feedback to candidates regardless if we're moving forward with them or not. Also importantly, in the candidate gives us an actual assignment, we always move them through to the discussion part of the interview, except for cases where the assignment was basically not done at all or was egregiously terrible. I feel mixed on this one, because sometimes it's clear from the assignment that chances are slim for the candidate, but I've also seen some pretty bad takehomes end up with super strong hires at the end (and vice versa!) from the discussions.
HR even tells me that a few candidates reached out and wanted to thank me personally for the feedback I gave them even when they didn't end up getting hired, so at least from what I can tell people don't mind the way we do it. I personally fucking hate doing interviews, regardless of which side of the interview table I'm on, so at least when I'm the one doing the breathing-down-the-neck thing, I try to make it as good of an experience as I possibly can.
IMO it's the fairest interview method, and the one I personally prefer to do when I'm the one interviewing (as in, when I interview for jobs). In my experience it's always been pretty obvious that the takehomes aren't for any actual work (obviously I can't speak for everyone here, I'm sure it does happen) and it's always a pretty made up scenario that is loosely tied to what the domain is. I know that it can be unfair for people with a lot on their plate, at least I've been lucky enough that 2-4 hours out of my week is pretty doable, and especially compared to something like leetcode (which most people still have to study for, so the 2-4 hour thing is pretty moot IMO) it's just incomparably better. I've tried doing "just talking" types of interviews, but there are a lot of good bullshitters out there, so there has to be some type of actual programming just to weed them out.
Surely a 15 minute phone screen at the beginning with an HR rep would help thin the field, no? Just something quick for them to show that they know how to act appropriately, dress professionally, show up on time, and speak the language. Plus it provides an opportunity for the HR rep to show a roadmap of the process and the candidate an opportunity to ask broad details in case they need to back out.
Caveat: I hate the concept of HR and the phone screen is an excuse to waste their time instead of mine. Also none of this applies if you have < 100 employees.
Dressing professionally is not important for software development jobs. People at my company wear a wide range of clothing, and I haven't seen anyone making an issue of it.
2. "...but in this case you have to show os some of your work from the past, so we can discuss this."
That is not always possible. There is always an NDA in contracts.
Imagine me going around and revealing the code I have done for your company...
3.
Are you going to pay extra those two engineers of your company for doing something
that is clearly outside what they were hired for at beginning or outside their competences?
4.
The same as 3.
Are you going to pay those employees for doing manager work instead?
Or the managers of your company are paid for doing nothing while showing doing something and soon ready,
as in your message, to download their responsibilities to simple engineers (company's leaves )?
Maybe that attitude works in a big company, but it won't fly in a smaller one. I'm a software engineer and I write plenty of code, but I also help out with interviews, packing, sales demos and proposals, customer support, general IT support, etc. Hell, I've fixed the coffee machine! I'd absolutely hate it if writing code was my only task.
2. Then they do the take home challenge, or you hire another candidate.
3. No, normal wage and is expected of them.
4. That’s not manager work. It’s a tech talk, it needs to be with the tech people.
It’s really not that weird to have the team decide who they want to join their team
I get paid to bring my knowledge and skills about computers and systems to bring business value to the company - to make them money or to save them money.
During the past decade, that has been as a “senior” employee of some sort. By senior I don’t mean just “I codez real gud”.
That has meant:
- Being on calls or flying out to a customer’s site to support sales in closing deals when I was working with B2B companies and later full time working at consulting companies.
- Interviewing candidates
- leading teams and come project management work.
- hands on keyboard coding
- DevOps [sic] setting up architecture for empty AWS accounts.
But I’m always up front about tradeoffs to management. If they want me to do one thing on the list, there is an expectation that something else on the list won’t get done. I don’t put in more than around 40 hours a week aside from the infrequent business travel.
> Are you going to pay extra those two engineers of your company for doing something that is clearly outside what they were hired for at beginning or outside their competences?
Why is it outside (and not just outside, but clearly outside) of what they were hired for or what their competencies are? Engineers work on the product. Engineers review each other's code. Engineers are a stakeholder in this whole process — after all, the candidate may become their future colleague, and engineers are best positioned to know what they want to see in a prospective colleague. Engineers can appreciate whether their peers have the desired skills.
Why does this activity require a higher pay than developing a new feature with your teammates?
The OP thinks that candidates spending a lot of time on applications is OK, as long as the company shows respect by spending a lot of time themselves. I think this is mistaken - I care about how much time I have to spend, and am a lot less concerned about how much time the company takes.
There's a trade-off: if a company spends more time / requires more effort on an interview process, they can get a better signal on the candidate's abilities, but then they'll lose out on candidates who are unwilling / unable to commit this time. This might just be a hard trade-off in recruiting.
Excellent point. And for anyone who’s been a hiring manager / recruiter, you know how many candidates you will have to sort through. And you want to waste as little of your engineers’ time making them do interviews if possible.
Internet applications have made it so easy to apply to a position, companies have to find (usually arbitrary) ways of filtering the pipeline.
It’s a very difficult problem to solve - Coinbase had 500k applications for 500 positions.
Edit: I’m very concerned about AI tools flooding the pipelines even more by sending out tons of automated applications. This is going to cause an arms race where the companies have to use more arbitrary methods to sort through candidates, and it will only make it harder to find good ones.
But, yeah, it's not that, back in the day, I didn't post a ton of application resumes and form cover letters to HR departments out of school--and even got non-form responses from a number (and an offer from one sight unseen though I ended up going with someone else even after insisting on an in-person visit). But my sense is that, as you say, there's more of an arms race as you put it going on today where--if you don't have some way of cutting trough the noise, such as through your network, it's a tough slog. Which is one reason the anecdotal evidence at least suggests it's tougher for people who have't developed a network yet.
>The OP thinks that candidates spending a lot of time on applications is OK, as long as the company shows respect by spending a lot of time themselves
if I spend 6 hours and the company has 1000 employees does that mean they spend 6000 hours? If so I might consider it a reasonable line of argument, but I guess they don't spend anywhere near that.
I think it's reasonable to make a donation on behalf or provide an honorarium if someone makes it far enough into the process. Something like a $250 gift card or equivalent.
Not enough to make it worth farming interviews for compensation, but enough to show that the company appreciates that you spent 2-4 hours working on their take home.
Readit News
Here's the traditional engineering interview script:
Ask the candidate how they'd solve a problem you either recently solved or are currently working on. Where does their mind go? What questions do they ask? Do they make the same mistakes you made? Are they different? Do those complement one another? Are they excited?
Honestly, one of the best things to do is get people to talk about their passions. For a lot of engineers their passion is related to their work. You WANT this as a business. They'll work hard because they're having fun doing the work. They'll learn more on the side and get a lot of expertise and ideas you wouldn't have on your own. If you make the job interesting and fun, they'll stay despite offers of higher pay too! But all of that depends on managers. A good manager participates and their most important job is preventing engineers from spending too much time in rabbit holes. You need to go down some but some unravel forever and your engineer will get stuck in an infinite loop.
You really really need to go through an actual code exercise with them. It’s staggering how many people I’ve interviewed who can talk the talk but when confronted with with a 50 line class full of glaring issues for a code review exercise, they can’t find any of the actual problems. The great thing about it is that the good people will spot the super obvious ones in about 5 seconds and you can just move on from it very quickly.
We’re talking c++ programmers with a decade of experience not spotting basic RAII, missing pointer checks and straight up logic bugs for the domain that we interview for and hire in (games).
This lets you get a feel for their coding style, comments, unit testing and so on. The "explain why you did it the quirky way" is for proof of authorship. You may learn something from it as well.
It's a bit of work for interviewer, but far less stressful for the applicant than coding tests. But it's easier for the interviewer in some ways too, as you don't need conversation starters - the "tell me about this project" step is a perfect way to find out about their previous experience.
As you say, the charlatans are very good. I even tried bring in sales, with explicit instructions that their job was to spot the bullshitter. They were no better at it than we engineers.
Would this work with any language other than C++? In almost every other language the only ways the code can actually be broken is if there's undefined variables or something. Sure, any language can have logic bugs, but that would require more than 50 lines to be certain of.
I mean, even if the code says something like `total /= 0`, yeah, it looks wrong, but, I'm not 100% certain it's wrong with just 50 lines of context.
Were these programmers lying about their decades of experience? Or did they really get by with writing broken C++ all those years without knowing the basics? What a language! I think C++ is a special case when it comes to interviews.
Dead Comment
I just have a deep technical conversation. If they run out of things to say, they are not right for the job. They run out of BS, because I keep the conversation on specific things that you can't make up, yet keep it open enough that you have to bring your own experience.
That's it, (spoiler alert!) it's like the great reveal in Kung Fu Panda.
> For a lot of engineers their passion is related to their work.
This is the guy you find with this method. He can talk forever, because he loves what he does and can't not keep doing it.
Dead Comment
I can’t exchange “passion” for food clothes or shelter.
I’m 51 now and can afford to choose work life balance over money. But if I were younger and it’s advice I give all younger graduates in CS is to “grind leetCode and work for a FAANG (or equivalent paying company)” and by pay I mean cash and RSUs in publicly traded companies not “equity” that will statistically be worthless.
Deleted Comment
Oral exams, live coding exams, system architecture exams, take-home exams, behavioral examinations, code review exams, extended essay writing exams, case study exams, sample work trials.
You can't be a real professional if you have to take exams in every job change.
In serious professions, people take exams early in their careers for being certified. Sometimes they take additional exams to renew their certificates. And that's all.
They don't take exams from random people in random companies that know nothing about evaluating knowledge. They take official, standardized exams prepared by professional testers/educators.
Engineering jobs can't be standardized. Engineering and required skills and knowledge is too broad for that.
An interview is not an exam. It's a meeting. The interviewer asks questions to learn about the candidate. The interviewer may ask some questions to learn about the company and the position. That's all. That's the universal definition of a job interview. All the other things are additional tests and exams.
Do they need to do those exams for better selection? Probably not. Their "hiring process"es are not backed by any science. Then why are they doing that? They have to filter somehow. If there are 1 to 100s ratio of candidates for each position, they need to filter hard. Exams are the standard method for ranking and filtering.
But we are professional engineers, not students.
Quarter of a million dollars in a suitcase, loaded gun, and a copper ticking clock on the table next to you. Picture of your kids that need new school clothes.
Miss one question and you fail. Must also be confident, friendly, and not too old while doing it.
—> “I can’t find anyone that can pass my simple test, they must all be frauds.”
This is not how proper exams work, and for good reason.
Hey, that's my PhD entrance exams!
Most devs are doing work that more closely resembles pipe fitting or carpentry than any engineering discipline.
We do exist, but as you said very rare. There were 12 of us in my graduating class in 2004.
Yet plumbers and carpenters (and electricians) are all licensed.
The field of programming emerged from mathematics, not engineering unfortunately. So we lack any useful certification processes.
However, it does not seem to be common practice for computing professionals to acquire professional engineering certification. (Perhaps graduation from an accredited program is considered to be equivalent?)
There do seem to be Professional Engineer (PE) certifications for computer engineering at least:
https://ncees.org/exams/pe-exam/electrical-and-computer/
https://ncees.org/wp-content/uploads/2025/01/FINAL_PE-Electr...
There are also company-specific certifications (from Microsoft, Cisco, etc.) but those are less general.
Not saying it’s not possible to focus on fundamentals that have only changed superficially in decades (like the networking stack or data structures), but it is more difficult in this field.
If you get nervous, the main thing you can do is more interviews. My personal anxiety peaks right before the start time, luckily my bathroom is next door to my office! But after doing dozens of interviews I settle in once it gets rolling.
If you hate leetcode, well just get good at it. Yeah it is kinda dumb but it is straightforward to practice. And there is a lot more to a leetcode interview than knowing tricks - you need to communicate well.
Take homes? Yeah they are time consuming. If you really need a job do them, otherwise pass on the company!
Overall as a candidate you really need to try and go one level up on selling yourself - not just why you are a great candidate (which you are of course!), but why you would succeed at this role in particular.
For better feedback there are some good mock interview companies out there, or you can ask a friend or mentor. I've also had really good luck just talking to Gemini/Chat GPT.
There's never been a single one that went poorly and I didn't know exactly why without a word of feedback from the company I was interviewing with.
You can actually ask for feedback and usually they'll give it. In the EU they have to tell you what they wrote about you in their internal system under GDPR (or at least my company's lawyers believed that)!
The one time I got really great feedback unprompted from a hiring guy it was basically "they were disappointed you didn't know X" and I was like "weird, I do know X!". Very interesting to see it from the other side but I don't think it was very actionable.
Failing a take-home is an entirely different thing. It's a huge loss in time and mental energy.
I've only done 3 of those in my career and only because the projects sounded interesting. 1 of those 3 resulted in a job offer which I can now confidently say in hindsight was the worst job in my career (...so far!).
I'm now leaning towards just filtering out companies that do take-homes because it signals to me that they don't care about their candidate's time and how a company treats its candidates is usually a good indicator of how they treat their employees.
With a take home I can demonstrate how I would perform at work. I can sit on it, think things over in my head, come up with an attack plan and execute it. I can demonstrate how I think about problems and my own value more clearly. Using a take home as a test is indicative to me that a company cares a bit more about its hiring pipeline and is being careful not to put candidates under arbitrary pressures.
Either way, when you fail, chances are that you will not get any meaningful feedback other than "we have decided to move forward with other candidates".
If you had done a take-home, how could you know where you went wrong?
If you had done a leetcode question, you can look up the question after the interview and usually learn from your mistakes.
With leetcode you usually don't need the interviewer's feedback to improve. You don't even need the interview. And after a certain point you won't need that much time to prepare.
On the other hand, with takehomes I get to approach a project as if it were my own little hobby thing. I get to approach it in ways that are comfortable for me to work, with my music on, in my own editor, on my own setup, with no time pressure (or at least very light time pressure, just like during the actual job). I always use it as an opportunity to try out something new as well, so I'm also learning in the process even if I don't get the job. And in my experience even when rejected, I've always gotten detailed feedback for areas of improvement, which has never happened in leetcode interviews for me.
Get good at it and you can do hundreds of interviews with no prep.
Take homes are a proxy for hiring most desperate ppl who can spend most time on it.
In my experience the more impressive somebody is at leet code, the worse their production code. Full of bugs, no error handling. Assuming the inputs never stray from the happy path.
Not saying it's always the case of course. But I did interview almost 400 people over my career.
On the other hand, most people cannot code to save their life. So I have no answers. Only more questions.
>with no prep.
You contradicted yourself in the same sentence. You can't get good at leetcoding interviews with no prep
Good signals comes from questions that uncover attributes that will grow your team snd fill deficits.
The best method yet for a technical interview is a work sample test based on recent work actually performed by the team. I've never encountered a leetcode problem in the wild. Data structures and algorithms, of course. Leetcode? Nope.
But leetcode is easy to administer and someone else already wrote the question. The big companies don't even try to differentiate between those who clearly have practiced the given leetcode problem type vs someone who derives a solution by working the problem.
Basically all big companies doing industrial scale hiring ( and firing) that don't have time or patience for take homes.
No, it doesn't matter that much what task the candidate is doing in the interview. It matters what the interviewer is looking at. I'm sure plenty of interviewers don't understand this, and I think this is often missed when people debate about Leetcode interviews - including in this article.
> most interview questions have very little to do with day-to-day responsibilities
You're missing what the interview questions are. Yes, one part of the interview is "here is a puzzle, can you solve it?", but many of the other questions should be things like "explain why this doesn't work", "why did you start with this approach?" and "are you sure that is the best name for that function?"
Leetcode interviews are perfectly "applicable", as long as the interviewer is using them as a convenient frame to see how you think, communicate, and write/read/edit code and isn't trying purely to assess your skill at quickly solving leetcode puzzles.
> cannot distinguish a senior programmer from a marketer using chatGPT
This is empirically false, because companies haven't suddenly lost all their hiring signal since ChatGPT came out. But if a company has this problem, they suck at interviewing.
(I admit the style of interviewing I'm describing has its own problems, and in particular doesn't address what I think is the biggest issue: the fact you're partly testing people's ability to (appear to) perform under acute pressure.)
But knowing the good solution by heart is not the point! For that reason, when I ran code interviews, I often gave hints to the candidate, or sometimes just stated that a particular algorithm is a good solution, and it's usually implemented using this and that. ("Use BFS. You'll need a queue.")
This is where the demand for realistic conditions kicks in: at work, you're not going to invent an algorithm, you'll ask the machine what works in a situation like yours, consider, and choose. Doing otherwise would be imprudent.
This is important and something more interviewers should do. The blind adherence to leetcode doesn't tell you much, especially if you're silent during the interview instead of having a short back-and-forth every 15 minutes or so. The problem solving process is more important than the problem solved.
You are also testing people's endurance. I once did an on-site interview with Google, and it was a solid 6 hours of leet-style puzzles, one after the other.
Also worth pointing out, the style you describe is the traditional engineering interview. Leetcode type problems were initially done this way. It is also easy to make an effective system worse by trying to improve it. This often happens by trying to apply hard metrics to noisy problems. You don't improve your accuracy, you are just fitting a certain type of noise better (and encouraging Goodhart's Law).
another way to say this: focus on aptitude. in my hiring funnel, this is a core tenet. you need to be able to capture polyglots and systems thinkers. its still pretty hard to design a process that balances this all very well. combine that with an absolute glut of applicants and you have a very challenging problem.
1. 60 minutes interview with the CTO.
2. At home coding challenge. Candidates can pick one from 2 coding challenges. But we try to keep them engaging and fun, but still complex in details. Sometimes people don’t want to invest this time. That’s acceptable, but in this case you have to show os some of your work from the past, so we can discuss this.
3. Interview with 2 engineers from the team. We are doing coding challenges as a base for this interview. It’s just a way to get people talking with each other on technology and how they work.
4. Make an offer or say no to the candidate. Everyone involved in this process from our side has a veto right. So if one person says no - it’s a No.
5. Send contract to the candidate, if they accept the offer. This is the first time in the process where HR is involved. Everything else before was done by the Dev Team.
I think this is the most important part, show respect by taking care of the process by yourself and communicating with the candidate.
From our experience just posting a junior web developer job gets up to 1000 resumes into our inbox. And we just a small company without an established name.
The only possible first step for us is to automatically send everyone an at home coding challenge. This narrows down the list to only about 50 developers that would reply. Only 10 of them would send working code. And only at that point we can actually start to interview.
I won't do a coding challenge unless you do mine too. Don't they always say interviewing should be mutual evaluation?
Here's the deal: You give me your standard coding challenge, then we reverse roles for an equivalent one I prepared. We do this for the full interview duration.
If you can't solve mine, that tells us something important about the technical bar at your company. After all, if coding puzzles are truly predictive of job performance and essential for determining candidate quality, then presumably everyone on your team, and especially those making hiring decisions should excel at them... ;-)
If your coding challenges are going to determine my professional future, and your company claims it only hires "the best," then you should have zero problem demonstrating that same level of excellence. I wouldn't want to work somewhere where the interviewers can't meet the standards they are imposing on candidates.
Either these challenges are meaningful indicators of ability (in which case you should welcome the chance to prove your team's competence), or they are arbitrary hoops and in that case, why are we doing this?
I honestly disagree with the veto right because it makes it too easy to be abused. In my opinion, a supermajority (66% or even 75%) agreement should be sufficient. They said that Liberum Veto rotted the Polish-Lithuanian parliament.
The hiring manager had the ultimate say, though. But he/she had to acknowledge, address, and own any objection and take personal responsibility for it if the candidate was hired.
When you have a good team who is earnestly focused on preserving a good team, it works really well. Red flag objections were pretty much never ignored, and were effectively vetoes. Minor objections or slight concerns about experience or aptitude, if they were overridden, prompted hiring managers to take extra time and care to help ensure the new hire's success.
Which is a reasonable stance to take! But not if you want to be paid for take homes, but not for interviews.
I get where you're coming from, and I've tried to fight to get people paid to do our take homes because I also feel it's only fair if we're expecting them to spend ~3 hours of their own time, but you also end up in situations where people will do the interviews just for the money. We had a small trial run with a pretty laughable sum, something like 40 bucks just to test the waters and see how people reacted (this was for a very high paying role, mind you), and we got a staggering amount of people who clearly didn't care at all about the role and just wanted the free money. Like literally would just post a link to a random repo or whatever, completely unrelated to the takehome, and you as the company don't really want to be in the situation where you argue with candidates about what constitutes a "real assignment" for the purposes of payment.
It's one of those situations where a handful of dickheads can ruin a good thing for the decent folk.
At least personally, I dedicate as much time to reviewing the takehomes as the candidates themselves put in. I write extremely detailed feedback covering every single line they present us and we supply that feedback to candidates regardless if we're moving forward with them or not. Also importantly, in the candidate gives us an actual assignment, we always move them through to the discussion part of the interview, except for cases where the assignment was basically not done at all or was egregiously terrible. I feel mixed on this one, because sometimes it's clear from the assignment that chances are slim for the candidate, but I've also seen some pretty bad takehomes end up with super strong hires at the end (and vice versa!) from the discussions.
HR even tells me that a few candidates reached out and wanted to thank me personally for the feedback I gave them even when they didn't end up getting hired, so at least from what I can tell people don't mind the way we do it. I personally fucking hate doing interviews, regardless of which side of the interview table I'm on, so at least when I'm the one doing the breathing-down-the-neck thing, I try to make it as good of an experience as I possibly can.
IMO it's the fairest interview method, and the one I personally prefer to do when I'm the one interviewing (as in, when I interview for jobs). In my experience it's always been pretty obvious that the takehomes aren't for any actual work (obviously I can't speak for everyone here, I'm sure it does happen) and it's always a pretty made up scenario that is loosely tied to what the domain is. I know that it can be unfair for people with a lot on their plate, at least I've been lucky enough that 2-4 hours out of my week is pretty doable, and especially compared to something like leetcode (which most people still have to study for, so the 2-4 hour thing is pretty moot IMO) it's just incomparably better. I've tried doing "just talking" types of interviews, but there are a lot of good bullshitters out there, so there has to be some type of actual programming just to weed them out.
Ask yourself why not
Dead Comment
Caveat: I hate the concept of HR and the phone screen is an excuse to waste their time instead of mine. Also none of this applies if you have < 100 employees.
That is not always possible. There is always an NDA in contracts. Imagine me going around and revealing the code I have done for your company...
3.
Are you going to pay extra those two engineers of your company for doing something that is clearly outside what they were hired for at beginning or outside their competences?
4.
The same as 3. Are you going to pay those employees for doing manager work instead? Or the managers of your company are paid for doing nothing while showing doing something and soon ready, as in your message, to download their responsibilities to simple engineers (company's leaves )?
Edited.
It’s really not that weird to have the team decide who they want to join their team
During the past decade, that has been as a “senior” employee of some sort. By senior I don’t mean just “I codez real gud”.
That has meant:
- Being on calls or flying out to a customer’s site to support sales in closing deals when I was working with B2B companies and later full time working at consulting companies.
- Interviewing candidates
- leading teams and come project management work.
- hands on keyboard coding
- DevOps [sic] setting up architecture for empty AWS accounts.
But I’m always up front about tradeoffs to management. If they want me to do one thing on the list, there is an expectation that something else on the list won’t get done. I don’t put in more than around 40 hours a week aside from the infrequent business travel.
Why is it outside (and not just outside, but clearly outside) of what they were hired for or what their competencies are? Engineers work on the product. Engineers review each other's code. Engineers are a stakeholder in this whole process — after all, the candidate may become their future colleague, and engineers are best positioned to know what they want to see in a prospective colleague. Engineers can appreciate whether their peers have the desired skills.
Why does this activity require a higher pay than developing a new feature with your teammates?
There's a trade-off: if a company spends more time / requires more effort on an interview process, they can get a better signal on the candidate's abilities, but then they'll lose out on candidates who are unwilling / unable to commit this time. This might just be a hard trade-off in recruiting.
Internet applications have made it so easy to apply to a position, companies have to find (usually arbitrary) ways of filtering the pipeline.
It’s a very difficult problem to solve - Coinbase had 500k applications for 500 positions.
Edit: I’m very concerned about AI tools flooding the pipelines even more by sending out tons of automated applications. This is going to cause an arms race where the companies have to use more arbitrary methods to sort through candidates, and it will only make it harder to find good ones.
But, yeah, it's not that, back in the day, I didn't post a ton of application resumes and form cover letters to HR departments out of school--and even got non-form responses from a number (and an offer from one sight unseen though I ended up going with someone else even after insisting on an in-person visit). But my sense is that, as you say, there's more of an arms race as you put it going on today where--if you don't have some way of cutting trough the noise, such as through your network, it's a tough slog. Which is one reason the anecdotal evidence at least suggests it's tougher for people who have't developed a network yet.
if I spend 6 hours and the company has 1000 employees does that mean they spend 6000 hours? If so I might consider it a reasonable line of argument, but I guess they don't spend anywhere near that.
Not enough to make it worth farming interviews for compensation, but enough to show that the company appreciates that you spent 2-4 hours working on their take home.