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.
Sounds like one of the many, many alternatives which "works" by just targeting a different subculture. This "representative body of code" idea is very strange to me - I don't have any such thing that I could bring to interviews, it's never occurred to me to write one, and my areas of specialization offer me no opportunity to generate one organically.
If this were the standard interview process, of course, I'm sure I could figure it out. There would be a site called "Leetportfolio", and I'd prep for interviews by implementing dozens of Leetportfolio mediums, and people would come to HN to complain about the obnoxious companies that expect you to include some Leetportfolio hards. For me this sounds significantly more time consuming and no less artificial or frustrating than Leetcode grinding.
After about 150 interviews, I could do the "just talking" thing without needing any samples or anything else. If they were working on Java, I would ask what versions, what issues they had run into, what their experiences had been with various frameworks they mentioned on their resume, I would bring up recent events to see if they knew about them, just stuff like that could tell me whether someone was senior level or not.
Recent events in... Java? It seems entirely reasonable for a senior developer, at least in a company that's large enough they're not writing their own development environment, to not know what versions they've used or keep up to date with Java language news.
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.
15m recruiter screen
(1hr Take home goes here if you’re doing it)
30m hiring manager call
1hr tech interview
1hr team fit
And a go/no go at that point. You can put the hiring manager call at the end if the hiring manager is a senior enough person that you need to protect their time.
The tech test should be actual code, but not evaluated for syntax. I like a code review test but we’ve also done problem solving and writing pseudo code in the past. No let code, no algorithms and no tricky formulas. If you want one of those you should provide the formula. A good tech interview should be open ended enough that you can dig into whatever direction the candidate goes - if they go hard onto concurrency then follow that track, or if they go into testing then follow that track.
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 don’t necessarily disagree but anyone who is a c++ programmer and sees
class foo {
public:
foo() {
ptr = new other();
}
~foo() {
}
};
And doesn’t immediately question it doesn’t instil confidence.
Interviews are inherently high pressure situations for the candidate, the only way to avoid that is to just let people try out on the job and fire them if it isn’t working out. That’s unfair to everyone.
The glaring bug here is that ptr is - or rather the object being pointed to is - on the heap and allocated in the constructor, but the deconstructor doesn't free it?
I would assume the interviewer messed up and forgot to declare it and if I just not pretend to assume it was "left out for brevity" I would fail the interview as a smart ass.
There are so many layers to interviewing and you kinda need to guess what the intervoewer wants to hear.
In my defence, this is a HN comment thread and not an actual interview. I wrote that on my phone at 6pm on a Sunday.
We have an actual question, a snippet of code that is copied and shared to the candidate, and everyone who asks this question has undertaken this exercise. The interviewer has the list of (known) issues and a handful of stylistic things that can be talked about too. If we actually did share this snippet with someone and they said "should this be declared in the class body", I would say "oops yeah, thanks for catching", and update our template.
>you kinda need to guess what the intervoewer wants to hear
Interviewers are human, and I've done tech screens for probably 250 candidates over the past few years, and I've designed tech screens that have been used for probably 5x that. We have good days and bad days, and it's super tough to give an evaulation of someone in an hour. The main thing I'm looking for (and I tell people this) is someone that I think would be a good fit on the team. To me that means that their own read on their level is roughly equivalent to my read on their level (a senior engineer who says they understand concurrency but doesn't understand what a mutex or atmoic is is a fail, for example), and that they're not a giant pain in the ass. If you've managed to annoy me in an hour by assuming every single thing I do is an attempt to catch you out, we're not going to get along and I'm going to pass on you for that reason.
If ptr is some kind of global, then it makes sense for it not to be deallocated by the destructor? It’s apparently not really managed by this class, so why would its lifetime be tied to it?
I mean it’s psychotic to half-manage it like this but I don’t think the lack of a destructor is suspicious here; in fact I think it’s correct once the global pointer was introduced
IMHO, there are two review branches to discuss in this example:
First, if `ptr` is declared in the translation unit before and outside defining `class foo`, then there is no check for previous initialization and thus is likely a run-time defect.
Second, if `ptr` is not declared in the translation unit before and outside defining `class foo`, then it is likely a missing member definition and is a compile-time defect.
How could you ever know whether that’s the case? Obviously it makes sense to try to conduct the interviewer with a low-pressure tone, and perhaps make accommodations for people who seems especially nervous, but at the end of the day I don’t think a job interview has meaningfully higher pressure to perform than, say, the first few months of a new job.
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?"
> I didn't do that well on it just because I was nervous as hell.
The problem is everyone gets nervous. The only way to avoid that is paid work trials and to decide whether you want to keep hem after 90 days. But that requires the person to quit their job.
> "hey look at this class from our codebase and tell us what's wrong with it!"
Ours is a self contained example, littered with absolutely obvious errors that anyone who has written the language being interviewed for (C++) should be able to spot a least 2-3 issues with. There are absolute glaring fundamental issues in about 50 lines of code and you are explicitly told there are numerous errors with it.
> 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.
It’s a self contained class that is littered with basic errors and doesn’t actually do what it’s supposed to do. There’s about 15 things wrong - missing pointer checks, uninitialised variables, public variables with private get/set functions, a memory leak, logic bugs that don’t do what the prompt says it’s supposed to do, subtle behavioural issues that come up in edge cases. We’re not looking for every single one, but there is an alarming number of people who cannot identify even the most glaring issues of “there’s a new in the constructor and not a delete in the destructor”.
> Or did they really get by with writing broken C++ all those years without knowing the basics?
Having inadvertently hired a handful of people, it’s this. They write shonky c++, it just about works, but they spend all their time patching up the mess they’ve left behind rather than doing it right in the first place
> I'm not 100% certain it's wrong with just 50 lines of context.
These are blatant issues that we would expect a reviewer to catch in isolation. It’s also an interview, we expect you to ask questions. You’re told as part of the brief to ask questions if you’re unsure. It’s not a trick, we’re looking to see if you can actually write the code or if you just can rattle off some of the rules.
A good example is DIY. How do you install a shelf - you drill a few screws into the wall and stick a piece of wood on it. Being able to tell you that is very different to being able to do that level on a wall. I can tell you “use SQL to select the name of the users who have used X resource without any duplicates”, but I might not actually be able to write that query (“select name from table group by X where Count(X) > 1”)
> I think C++ is a special case when it comes to interviews.
I disagree. Give me a language and I can give you 50-100 lines of code that just about does what it’s supposed to do but is littered with issues. Offhand I could write the same thing for C#, go, python and SQL with very little issue.
Thanks for the additional detail. It sounds like a great interview question; it's both easier, and yet more real-life, than something like "write fizz-buzz".
> even if the code says something like `total /= 0`
In what context would this not be wrong?
I mean... it might run or compile but our best case scenario is what, javascript where it returns infinity? But I'd certainly take issue with any program where I saw an explicit division by zero. If you were just trying to create an infinity there's got to be a good explanation for doing it that way.
It could trigger an exception which is caught elsewhere, or round the number to Inf or -Inf. It's a "clever" (aka, stupid) way to do these things, but it might not technically be wrong. It is possible to have well behaved and reliable code doing such a thing, unlike UB in C++.
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.
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...
I'm 52 and as soon as they figure that out it is pretty much over, anyways. I'm not looking right now, even. I think my career is closed down, but not totally sure yet. I was passionate about my work for a long time, but after awhile I realized the same issues were grinding me down repeatedly and one of them was the average quality of new staff was becoming pretty bad. There would be like one truly inspired developer amongst 10 or 20 so-so ones and that inspired one usually had some kind of work ethic issues, e.g. serious apathy about everything in life. I'm not saying I'm great, because I had times where I wasn't too motivated, either, but I bounced back from burnout 2-3 times and was truly on point for a lot of years at some pretty un-charming companies. So it goes, so it goes.
Then don’t be the median candidate? If you are the median candidate in today’s market randomly submitting your resume to an ATS and trying to get by based on your ability to grind leetCode and reverse a btree on the white board, you’re screwed anyway.
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.
I don’t think I’ve ever even proffered “passion” about software development or whatever random B2B SaaS vertical the company was doing.
I show proficiency, professionalism, expertise, and the ability to bring that to a job.
I’ve had 10 jobs everything from startups, random big enterprise, and BigTech.
Am I suppose to show passion about - bill printing? Field services sending technicians to people’s houses? Railroad car repair?
Admittedly my first job as an architect was for a company that managed sending nurses to the homes of special needs kids and the next two were in the health care industry, but after that it was dealing with cloud consulting (full time jobs) first at AWS directly then other consulting companies (currently a staff architect at a 3rd party cloud company)
I can talk about technical solutions, be a post sales architect, lead implementations and do system design and coding all day long without being “passionate” about the business. It’s just professionalism and my addictions to food and shelter
Passion can show itself in many ways. Why did you pick programming of all things? There's something there, right? If you can dig into a topic, that's a form of passion. If you're willing to put in hard work, that's a form of passion. These may not be the same thing as the person who gets excited about these problems, but something did drive you. And no one is so excited about coding that they are never dispassionate and never frustrated. The thing you're looking for is why should I trust that you have these skills? If there's nothing you can rant about, then I'd find that odd, even if you see it as a paycheck.
I picked programming because I was a short (still short), fat (I got better) kid with a computer in the mid 80s.
You can “trust” I have those skills because I can talk about my past experiences, you can throw any architectural or business problem at me and I can talk through it including tradeoffs and why I made the decisions I made. How I deal with organizational challenges, etc.
My being able to dig into a topic is not “passion”. It’s my job. I get paid to know my subject matter deeply and to be able to ramp up fast on technology and the business domain.
The deal is if I work at your company, you agreed to give me $x amount of money, benefits and for me remote work and in exchange I agreed to give your company all of my expertise gained over 30 years of working for 40-45 hours a week.
You need me to code those 40 hours a week? You got me. You need me to be on a zoom call or fly to a client site? No problem. You want me to do pretty diagrams and spit out 40 page requirement documents or business proposals? I can do that too. Along with leading projects, cloud architecture, etc.
Just understand, you get 40-45 hours a week. You don’t get late nights, you don’t get on call, you don’t get weekend work, and my bullshit tolerance level is relatively low before I am looking for another job - ask my last nine employers.
Okay, so it seems like for the most part we agree in concept but disagree about the words used to convey them? Do I have that right?
I laid out what __I__ consider different forms of passion and while explaining yourself you met some of that criteria. So I'm not sure where the anger is coming from. I hope you're doing okay and I really hope we can have fewer abusive employers. I'm really empathetic to that, and have quit several jobs because situations like you mention.
It’s not anger. I get tired of employers taking advantage of naive younger developers who have “passion” and underpay them and overwork them, expect them to have open source contributions and as you said yourself, if someone is “passionate” money isn’t as important.
These are the people who don’t show “passion” unless when they get off of work they are doing side projects related to software development and usually end up getting burned out.
I’ve also avoided burn out, stress over work and I am able to survive in the industry for 30 years because I understand the transactional nature of the job and set boundaries.
Someone who does there job well doesn’t mean they are “passionate”, they are “professional”.
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.
This is an interesting point. Most US universities are accredited overall, but their individual engineering programs aren't always accredited by engineering accreditors.
For example, UC Berkeley's EECS department lost its ABET accreditation in 2020 (which it had maintained since 1983.) Stanford University lost its ABET accreditation in Electrical Engineering in 2014 (which it had maintained since 1936.) In contrast, nearby Santa Clara University and San José State University both have ABET-accredited EE and CS programs. So, consider hiring some of their graduates!
Many computing professionals are members of professional societies such as ACM or IEEE (and many are not since they don't see the value in the expensive dues.)
What has also not been widely adopted, and has even been opposed, is standardized professional engineering certification (exams, licensing, continuing education requirements, etc.) for computing professions such as software development.
I think this may be related to the computing industry's remarkable success in avoiding liability and associated regulation, particularly for software and online services.
> 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.
And on the plus side that liability also provides people a lever with which they can push back against stupid managerial decisions. My father was an aeronautical engineer, and his favorite word to say to management was "No". Yes, the engine inspection takes a long time. No, I cannot cut corners in any way just to save you some money (No idea if this is just one of his stories or a real situation, but you get the idea :p ).
I don't know why people are so against it in this field
In general, licensing is for regulatory reasons (e.g. signing off on drawings). Engineers don't generally do it unless there is some industry requirement to do so (especially in civil engineering). And there mostly isn't in software.
I started the engineer-in-training track when I was in the offshore drilling industry but then I left and never went back.
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.
Poorly is different then hitting 90% (maybe?) of the way there but still rejected. Or conflicting responses from different interviews. Like you did great on the coding then the next company thinks you did poorly.
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.
I would probably adjust my original post to say you cant better without useful feedback.
I always ask for feedback after an interview, its almost always useless. And conflicting between company interviews.
Its pretty rare for me to totally bomb an interview to the point i don't know the question. Usually the situation is I answered the coding question, handled the follow ups, wrote working code and still get the feedback that the coding portion didn't go well. How do you use that feedback? Useless imo.
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.
> In my experience the more impressive somebody is at leet code, the worse their production code.
Used to think this too, until I met some truly impressively bad engineers where I'm pretty sure they would not have passed a leetcode screen either. People acing leetcode is at the minimum a good signal for people having the patience to sit down and learn non-trivial things over a somewhat longer time period by themselves.
After getting good at it, there is no "additional" prep time, unlike take homes, where you would need to spend hours for every individual assignment. Is that so hard to understand?
Do you know the "use it or loose it" phrase? How long do you stay good at leetocde to not require anymore prep whenever you interview again?
For some people, doing an AI assisted take home might take less time than having to restudy and re-exercise leetcode for months which they won't use again. Plus a lot of people suck at live coding when put on the spot due to anxiety, which means even more time investment for something not related to work.
>Is that so hard to understand?
I understood just fine, I'm calling it out as being incorrect for a lot of people.
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.
yes agreed leetcode as interview technqiue sucks but its great for interviewers. i am just a powerless cog playing the game trying to provide for my family.
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
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.
hmm most of the take homes I ever got had a 1 week to complete but I guess I see it, I don't think I've ever been trying to get on a company that is hiring more than a small time at any time.
In Australia, AWS dev position in 2021 had a take home. Microsoft contract position before that didn’t but they were desperate to fill seats on a poorly executed gov contract.
GitHub (pre-microsoft at least) and Crowdstrike both did. Amazon didn't have a take home so much as a "prove you can write code with this simple problem" though that was also pre-AI days as well.
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.
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.
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 think any reasonable person can interpret that there is a meaningful difference between an hour of work and several. The same way you might drive your friend across town for free but you're probably going to ask them for gas money and some beers if they ask you to help them move across state. An hour of my time is just less valuable than my entire day.
(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.
Usually dressing professionally refers to standards that are quite different from that, so if one wants to say that they're checking for things like that it would be best to make that clear.
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.
However, here we are talking about at the general level. Not a single instance as your experience.
Engineers are hired for engineering jobs not for manager jobs or mopping the
floor.
On the other side, if a lately hired person wasn't find himself comfortable inside the team,
I, _as manager_, can always complain the team and accuse them being guilty because they weren't
able to say NO at interview level or because they said YES at the wrong candidate.
Do you see the faulty thought of our time?
I as manager earn a lot for managing people but in reality I download my
responsibilities of not being able to interview a candidate and so find the right person _downloading_
that on the team that actually is not responsible for new hired person. Fantastic.
Than's the meal they want you digest in some cultures.
In mine, as manager, I decide who is on board, and I clarify clearly the roles of every one.
No space for interpretation.
I din't come out from a manager school, but I started from the ground and I put myself _every time_
in the shoes of who is managed by me.
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
2. Then they do the take home challenge, or you hire another candidate.
This is not kindergarden anymore. We're taling adult stuff here.
If the manager is not able to interview, analyse and understand who is in
front of him, then it is time to change job.
Iff the candidates has personal work to show then it is considered a plus, but it is not
madnatory.
3. No, normal wage and is expected of them.
A hired person is supposed to fill a role and not a double or more roles just because the manager is not able to subdivides tasks, roles etc. I don't expect engineer or technical
roles to do manager job.
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
It might work in your culture.
in my culture, who is going to take a manager role _manages_ technical people _and_
as such he _must_ know the technical stuff to a certain degrees otherwise the job is not for him.
Here managers don't download their responsibilities to engineers they manage.
At the same time, engineers are not supposed to judge or like or dislike their coworkers. Working
in a team is a prerequisite that they have to accept, either you like it or not. Full stop.
There is no space for interpretation or for leisure. They have tasks and they finish their tasks.
Full stop.
2. With us it is. Not for seniors, but juniors, interns, people out of college, we want to see how you program so we know how much effort the training is going to be.
3. We do not fill multiple roles. But if a person might join your team, the team gets to talk with the candidate. This always also becomes a tech talk because we’re developers and we like talking about it. That’s not a second job role at all.
4. Our managers are tech people. They are not always actual developers though, or might’ve been 20 years ago.
In general it goes like this:
Junior?
- talk with manager and tech lead of the team, just about who you are, what you’ve done and what you’re looking for. All to see if you are a match personality wise.
- if we liked the talk you get invited for a technical interview. You go sit with the team as they work, you get to do some challenge. We’ll help you and discuss your solutions
- we all together decide yes or no
For experienced developers we have the same, minus the coding challenge. The talk with the team is more about the personal match, but it usually is about tech stuff or what we’re working on because the candidate is curious.
I find it very natural and relaxed. The team eventually decides themselves which candidate they prefer.
Also I have no idea what you mean by there not being time for leisure. With us there definitely is, and liking the team you work in is very important to us. If you don’t like it or it’s not working we might place you in a different team where you match better. Or maybe you don’t think the apps we work on are interesting, but those of another team are. Why shouldn’t working somewhere be enjoyable?
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.
Historically, I'm not sure that isn't fairly normal.
But compared to maybe the decade plus prior to a couple years ago for (especially junior) software developers, it seems like a tough market based on a lot of conversations irrespective of overall unemployment rates.
Last time I was looking, a year or so ago, I sent out dozens of applications and got zero interviews. Last time I switched jobs, in 2022, I sent out the same amount of applications and >50% led to one or more interviews (and eventually two offers).
In 2023, I was Amazoned after 3.5 years and found myself looking for a job. Even worse, by then I had moved to an area that was tourist heavy, but not really tech heavy and was looking for remote only jobs. The remote role at AWS just kind of fell into my lap.
Plan A: Leveraging my network. This led to two offers both architect level positions - one over the architecture and migration to AWS at f500 company and the other over the architecture of PE owned company that was doing rollup acquisitions (been there done that).
Plan B: targeted outreach to companies looking for expertise in a niche of AWS
where at the time, I was one of the industry experts and was a major contributor to a popular official “AWS Solution” in its niche.
This led to two interviews and one offer.
I basically had three offers and a side contract within ten days of looking.
I’m not bragging, I’m old. I should have a network to lean on and a reputation. The point is that even with my experience, if that well above had run dry, I might have been screwed.
I also applied for hundreds of jobs during those two weeks while going through the interview process with my first hits. I heard crickets and for every job I applied to, it had hundreds of applications and my application wasn’t even viewed by most and my resume was only downloaded once (LinkedIn Easy Apply shows both).
I was not some old guy (well I am) with outdated skills. At the time I had over ten years of software development experience (on my resume) and 7 years of AWS experience including 3.5 working at AWS (ProServe) leading relatively complex projects.
>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.
Not sure if they're still doing it, but GitLab does the code review interview, and I too really liked it.
Before the interview, you clone the repo and get the app running on your machine.
For the first half of the interview, you review a pull request in real time. There's a mix of obvious and non-obvious callouts. And the second half, you actually implement your suggestions.
Honestly the code review portion alone is a great indicator of a dev's experience and soft skills.
The situation is not going to improve as long as business stakeholders and engineering managers (some closer to MBAs than actual engineers) think of software engineers as construction workers. They think we are fungible, they don't understand the craft of programming etc, and have very short term mindsets. Took me a while but then I realised that I needed to interview my prospective employers as much as they were interviewing me, and to just ignore those not worth working for.
> I realised that I needed to interview my prospective employers as much as they were interviewing me
This is so important, and most of the “fit” problems working I’ve experienced are because I didn’t weigh something heavily enough in the interview.
If you are even the slightest bit concerned with an employer, that is a red flag in your long-term prospects there.
For example:
- If your future boss seems even a little clueless about the job itself, you may be lucky to find adequate structure or information available to do your job well.
- If your future boss seems guarded, they may be hiding something; they may not be equipped for the job or could be a psychopath.
- If they have greater than average benefits or the recruiter calls you a rockstar, it may be some form of hell, and you won’t find that out until a few weeks in.
- If more than one person seemed like they were afraid to say something during the interview and were very quiet, either the environment there will be weird or it may be a serious hell and/or there is no chance to be able to fill the shoes of the person that left.
- If you sense that they overestimated your ability or you overstate something accidentally in the interview, you may not overcome that as much as you want to believe in yourself. No, you can’t make up for years of experience with hard work. Your LinkedIn profile description must be essentially you, with the burrs removed and buffed up a little; It’s not just to get past a machine or recruiter.
- If anyone you interview with is an arse, even if they work in a different team, that’s not a good sign.
- If you are ___, and no one else there is, that may be a serious problem. This is age, sex, religion, politics, number of kids and ages, pets, what they do/don’t do socially, emotion, humor, tech stack, clothing, what vehicles they drive, style of workplace, and everything else that either you won’t like or they won’t like about you. Diversity is a sham if you’re the only one different, though I know that some may not ever realistically find a place to fully fit in.
- If you join when they’re hiring others for your team at the same time, and the business itself isn’t growing significantly, that can be a bad sign.
- Claims that they don’t fire people are a lie or a hope.
None of these are absolute rules, but find your people, and if anything doesn’t seem right or seems too good to be true, it probably is. Weigh that extra salary against the impact of having to find another job if you quit or are let go later.
> If you are ___, and no one else there is, that may be a serious problem. This is age, sex, religion, politics, number of kids and ages, pets, what they do/don’t do socially, emotion, humor, tech stack, clothing, what vehicles they drive, style of workplace, and everything else that either you won’t like or they won’t like about you. Diversity is a sham if you’re the only one different, though I know that some may not ever realistically find a place to fully fit in.
This is impossible to satisfy below a certain company size. And beyond the things that can't realistically be hidden, I would prefer not to know a lot of that about my coworkers, and would prefer them not to know those things about me.
We are fungible. Most software development is not rocket science. If any of us got hit by a bus tomorrow HR would send our next of kin “thoughts and prayers”, a flower and tell them how to collect our life insurance and then immediately open a req and get flooded with hundreds of probably good enough replacements.
It sounds like what you're arguing for is that companies ought to have employees that are irreplaceable. Wouldn't that impose a huge risk to the company? If said employee gets hit by the proverbial bus or leaves, the company should just fold?
Companies need to build systems where everyone is replaceable to de-risk the business and not because they don't get programmers.
If a company doesn't have irreplaceable people, then that company is not doing anything interesting. Conversely, if replaceable people can produce your (software) product, then any other company can also do it.
As much as I don't like LLMs that much personally, do you think ChatGPT was produced with replaceable people?
> Companies need to build systems where everyone is replaceable...
No they don't. They need to build systems where everyone is happy with their job and don't need to constantly hop jobs for better salary, environment, etc.
The way to mitigate the bus factor is not to make everybody replaceable; it is to have a process to develop more irreplaceable people with overlapping expertise in their areas.
Overlapping expertise is another form of replacing someone. At a basic level, employees need to go on vacation, parental leave and all sorts of other personal leave. If you were irreplaceable, you couldn't go on leave.
Companies who develop these systems successfully are able to allow employees to go on leave for 4-6 months and have them easily come back. This is a good thing.
But they ( companies ) don't. Looking back at my career, what you do get is, various ranges of alignment to an idea ( whatever it may be ). Some companies do it better than others. Usually, the smaller the company, the easier it is for the owner/founder/main guy to make sure his vision is appropriately enforced, but that gets so much harder in bigger ones so the systems they generate get progressively less sensible. And yes, I don't think search for absolutely replaceable employees shows any kind of faith in one's company. It does, however, show an interesting frame of mind that I personally like to avoid.
For all the talk about innovation, you don't get that by making everyone an interchangeable cog. You want at least some people, who are difficult to be replaced, because they are your competitive edge ( I am saying difficult, because I personally also do not believe anyone is truly irreplaceable ).
And again, the risk to a company, especially a tech company, is falling behind. Losing an employee is a fact of life type of risk; effectively unavoidable. Still, that kind of fake modularity is wrong, not because modularity is a bad idea ( it is not ), but because companies absolutely fucking suck at designing that kind of a system ( as evidenced by reality itself ).
All this is before we get to some of the more human aspect of all this ( up until now we were talking about companies as if they are a living thing with wills and what not and an amalgamation of humans, where one action is a function of thousands little decisions ) like: people messing with systems in a way that does the exact opposite of what the company 'wants'.
All in all, it is an interesting argument, and I even agree with it at some level, but I do not think it survives closer inspection.
It's crazy, I've been trying to hire an architect to build a house for me, but I don't trust them (they're all liars) so I asked them to draw up blueprints in front of me and describe everything they are doing in great detail. I need to understand what they are doing. This building is important and I don't want a bad hire. They should be able to do this in 10-15 minutes. If they knew what they were doing, this request wouldn't be an issue.
Then I was trying to get someone to do my taxes. So I've been asking every applicant to do my taxes from last year so I can see if they really know what they are doing. I mean sure, they've done taxes for years, but these are my taxes. I've even tried giving them math puzzles around asset depreciation, but people just keep hanging up the phone.
And then, I wanted to add a wing added to my house and I've been trying to get these entitled contractors to come build a shed in my backyard so I can see if they really know how to use nail guns. I've heard people are just big'ol lairs lately, and I need to see how they work. I mean, sure these guys have built many houses in the past, but we have high standards here and only hire A players.
I've only been getting horrible candidates! No one is worth hiring! There is a huge shortage of qualified people.
I can't tell if this is a snarky way to say we should have programming accreditation like architects and accountants have, or not knowing about accreditation and saying we should just trust the applicants more.
One of my favorite interviews (Mixrank) was where the CTO/founder and I picked a random problem on Project Euler and we both coded on it in parallel. I was in the driver's seat as far as design and general approach was concerned but we were each coding an independent solution. We weren't even using the same languages.
Once we both had the correct answer, we started optimizing to try and eclipse each others' runtime. This was actually a fantastic test to display deeper knowledge beyond just regurgitating a solution, showing benefits and drawbacks of different languages and patterns, and seeing how we could work while agreeing or disagreeing on a technical subject.
I was really too junior for the role they wanted and I didn't get the job, but it was a fantastic experience.
At my first employer circa 2005 we had a simple 1-2 hour interview and a 90 day probationary period. Respected people's time, gave everyone a fair chance to prove themselves. I don't know why it's not more common in the industry.
Part of what lead to it I think is we hired largely straight out of college and doing a 9-hour interview with someone with little experience is a waste of time.
It worked great. In my five years there we only had a couple people not make it past the probationary period.
Well, historically, taking a new job often meant relocating which is a big expense for the employer (who typically paid relo for engineering jobs) and is hugely disruptive for the employee. Definitely not just a shrug for everyone concerned if things don't work out after a bit.
Less true in hotbeds for a given industry. But I've had relocation paid twice in my career and it was just a given.
It's been a long while but, especially as a young employee (presumably) expecting to have relocation handled, I'd be WTF; the relocation would probably have been a huge chunk of my salary at the time. Of course, at that point, you're probably just screwed and you're probably not going to get a lawyer over it.
I'm talking about somewhat longer ago but it used to just be part of the deal along with living expenses for a month or so in my experience for professional jobs.
Having to relocate a long distance would have been a huge barrier for me both for cost and other reasons at the time. Obviously remote is a bigger option these days but far from universal. Glad it wasn't a problem both times I did even if the cost and other obstacles weren't as great at the time.
The one time I had an employer involved that closely they completely dropped the ball and I had to crash on a friend's couch. Again I don't think having corporate administration so closely involved in your life is a great idea just because of the dumb things they occasionally do.
The primary problem with hiring is that developers are a single status with not performance benchmark. The solution is to segment need by capability.
Let’s face the reality that most developers will never be able to write original software and just put text to screen using a tool or framework. Don’t call these people engineers. These people are the assembly line of software. Measure them according to desired patterns. They are copy/paste but smarter than data entry and understand some of the restrictions in place. Expectations are low and compatibility and replacement are the key business values.
Next are the people who test software, the QA. We expect more from these people and then work them harder for less money at a lower level of reputation.
Next are the people who evaluate software. These people are closer to engineers. These people include accessibility, security, and performance experts. These people are more like a combination of QA and senior developers. Evaluate these people on these criteria: written essay, technical knowledge, force them to measure things in real time and see how they perform.
Next are the people who actually write software applications. Let’s call these people solution delivery. These people are similar to junior architects and actually build things. These people should be evaluated only on the basis of organizational capabilities above that of the engineers that measure things.
Finally are the software owners. These people resemble a combination of project management and junior architects. They must have the experience to know how to build original software, like the junior architects, but also a planning vision to push though demands from competing stakeholders. There is busy savvy to this comes from a solid engineering planning vision plus superior communication skills most lesser software people never honed. Think of these people as senior principals with real authority. Evaluate these people on their delivery experience, using numbers, and reputation.
Now the issue is to identify them. All those types of workers will present themselves as Software Developers (or Software Engineers), so the interview process is not only an entry filter, but a classification filter too. You (as a company, or as an interviewer) need to discern which are the strengths of a candidate, and also the skill level within each of those categories.
> Next are the people who actually write software applications. Let’s call these people solution delivery. These people are similar to junior architects and actually build things. These people should be evaluated only on the basis of organizational capabilities above that of the engineers that measure things.
Why? People who actually write original software require many other skills in order to do so (just not, you know, marketing).
Writing software is no different than writing a novel or a music album. Its creating a product. All of these require the ability to write, but its more than just writing an essay. There are functional aspects that require different stages of planning and composition that must be put together in a way that can be maintained, described, and decomposed. Its that vision for composition and extension which requires organizational capacity drawn from lots of experience.
I agree with the article. Discussing previously created code and do code reviews live covers a lot of ground. Whereas live coding is just meaningless for the stated reasons.
But a 9-hours interview process seems just too much... I think you will only ever know a candidates true fit once you start actually working together and 2-3 short sessions with someone is enough to get that go/no go feeling.
You can't hire without taking risks.
Where I live, you usually have a 3-months probation time in which both sides can quit within a 7 days period... so the risk is manageable.
Just feel a candidates fit and then go for it... and adjust when necessary. Don't overthink it.
As long as someone isn't relocating, it's possibly reasonable. As long as someone is moving, there's a lot bigger barrier to taking a job. Mind you, there's is a barrier in any case if someone has a decent-paying job but just isn't loving it.
If I can get a person talking about tradeoffs - be it speaking to a past project, or a hypothetical I give them - then I think I can tell who the serious developers are fairly quickly.
I won't forget the in-person interview round where I coded a frontend visualization for a data graph (tracking global shipping), then fielded a post-work general interview round from the whole company (~10 ppl) about specifics and "choices" made during a rush to finish. I ended up not going due to comp, but they were acquired months later. Life is funny.
I have a rage memory now of a "live coding" event that makes me want to leave this profession and never come back.
Here's my suggestion for the technical interview:
1. Applicant signs NDA and agrees to not use AI
2. A small bug or feature request is chosen from the backlog
3. The staff engineer pair programs with the applicant until it is fixed/implemented
This does a few things:
a) The interview is suddenly "productive" for the employer rather than a cost sink
b) No one will apply that doesn't actually know the stack/framework/language
c) The interviewer gets a real world example of what its like to work with the applicant
d) Leet coding and puzzle solving is eliminated in favor of real world coding
e) A secondary skill set that doesn't actually contribute to the work is eliminated (go pound sand autists)
Except it was wildly unpopular amount the other interviewers as t was seen as setting traps and watch if the poor guy falls into them.
And interviewees were sometimes dumbfounded looking at the code, and we didn't know if they were just crushing under the stress or had never looked at code in their life.
All in all, it wasn't that different from a straight leetcode interview.
Code reviews were basically the same, nice on paper but hard to judge in practice.
Disagree. Am a good programmer who can’t perform under stress or surveillance. A code review would be 10x less stressful than writing fresh code and enable me to show off knowledge easily, in a good way.
To dig a bit on this, setting up the review itself isn't trivial. I felt we were just applying different biases, which could be fine, but it also wasn't catching up internally.
For instance I personally use and abuse the online GitHub/gitlab interface a lot and am extremely familiar with both. But looking at my colleagues, many do code reviews locally, diffing in their IDE.
Some also don't navigate the code the same way and tend to work "bottom up" instead of "top down", which puts them at a disadvantage in time limited settings when they might be better reviewers in general.
Referring to the other comment wishing to get full A3 printout to look at the code, we also had a guy who used his personal laptop to interview and felt lost as he usually reviews code on his giant work screen.
Having the candidate choose could be the best of both worlds, but that' a lot more work on the interviewing side.
If I was asked to review code in an interview, I'd prefer it be printed out on a sheet of A2 or A3 paper that I could look over and write on.
Regardless, there should be a hard rule that if you show code (either working code or example code) to a candidate then it needs to stay visible for at least five minutes. No skipping ahead to the next slide or switching windows after 2 seconds.
For live debugging/fixing we were sharing a dedicated GitHub repo, and the candidate would share his screen while doing it. It was kinda of a mess, so I switched to a more static approach of sharing a MR and have the candidate explain what it does, and potentially comment on it.
TBH I wouldn't do that face to face, it's so unnatural I'd prefer white boarding or straight handing them a computer.
That's also where using an online coding platform where the candidate can run the code works a lot better, less preparation on either side, less surprises.
I generally make it a rule to not share my screen, install software, or create a new account as part of an interview process, so using an online coding platform is nice.
Debugging exercises reveal not just technical knowledge but also communication patterns - how candidates ask clarifying questions and explain their reasoning reveals more about their daily work habits than most algorithm puzzles.
The fundamental problem with interviewing is that you're not preparing yourself to understand a business' problem and needs, but you're preparing to have to impress your potential colleagues, a non-trivial number of which are already jaded.
Big tech can afford this because they have a constant stream of candidates.
So glad I changed industries after my first s/w job out of uni wanted 2 hrs unpaid overtime per day and the boss ran the office like he was lord of the manner, swearing and blowing up whenever it suited him. If I had the skills these people want for the price they're willing to pay I'd just start my own business and reap the rewards myself. Most people aren't worth working for. Perhaps the pool of employers is far larger in the US which makes it easier to shop around for a good one.
They think everyone wants to work for ping pong. It’s delusional. All it takes is one bad decision to send everyone running. Leaders are so high on their own egos that they think no one would ever want to leave, but we do.
The issue I see is lots of companies put strategy into hiring from colleges and then are left with the low performers after 3-5 years. A good company will mix college recruiting with job fairs and LinkedIn/indeed ads to get good candidates and won’t pretend to be “a family” or enter cult phrase to try to attract talent.
I disagree on the "taste" aspect: I don't think it's valuable to take that into account in the slightest.
A lot of the time, technical interviews and take-home exercises turn into 100 iterations of "Do you prefer vanilla ice cream or chocolate?" or "Do you prefer vi or emacs?"
A good employee will figure out the subjective tastes, biases, and cultural quirks of a workplace, and fit in. A senior engineer will have done it perhaps half a dozen times in their career. -- And yet, companies insist on putting interviewees in a situation of having to basically mind-read those subjective tastes and biases to try to tell interviewers what they want to hear, because they'll reject a candidate on the false premise that a vi guy will never fit into an emacs shop.
"How do you feel about unit tests?" I really don't have any feelings about them whatsoever. Just tell me, if you want me to write them or not. Instead you're asking me to mind-read and trigger some hidden trauma in you. I just don't know whether the trauma is that codebase that required breaking production every single day, because there was no way to test it. Or whether the trauma is that one guy that you hired who never got any work done because he obsessed over refactoring the codebase for optimal testability instead.
I've been using a variation on the "Code Review" example for years, and really like it. I give the candidate some fairly straightforward sample code[1] that interacts with a Python library[2] along with a couple user stories that they are expected to implement. I tell them I'm both their product manager and pair programming buddy, and that they should ask me any questions they might have, use ChatGPT, consult Stack Overflow...whatever they do to solve the problem at hand because I'm just interested in seeing how they think.
No system is perfect, but I have a 100% success rate with the engineers that have been hired using this model, and several years of data to back it up.
[1] It actually has a few subtle bugs in it that I'm always curious to see if they'll catch.
[2] The job in question requires working on a Python web app, and so I assume some basic Python knowledge.
I don't want to give away my secrets, because this has actually worked really well for me and I'm afraid that I'll lose my edge as an employer - however I have a very small neck of the woods and HN seems very US-centric so I think I'll be ok.
What has worked for me, honestly, is being directly involved with my hiring pipeline and having conversations.
It seems like common sense, but there's a lot of reasons not to do this and people will make good arguments to prevent it. "What about bias", "your time is more important" etc;
However, bias is an unfortunate consequence of selecting for value fit anyway and I can't think of a more important task than selecting the members that will be the future of the company.
I've had some positions that were open for a weekend where I got 400 applicants, and yes, it was daunting to go through and give each of them an honest shot, but you know: I had to do it. What's the alternative? I might miss a fantastic candidate because someone didn't understand what I actually need.
Evaluating programmers and "devops" people is just insanely hard, technologies are mostly fungible. If you can write one C-like language you can learn the others in about a month, but what can't be taught is what your values are, if you think in a systemic way, if you're easy to work with and respect others.
So, my solution is to have a conversation, challenge what they know, see how they react when challenged, see how they react when they reach the end of their knowledge and see what they're most proud of and if they get excited by it.
No gotchas, no esoteric internal handshake, just: are you defensive? Are you curious? Are you passionate? Can you communicate effectively and are you intelligent.
If you hit those, you can do anything.
"How do you even know who to interview?"
This is a hard question, for me there's not a lot of candidates that are physically located in my region, so those go through as long as they have something on the CV that looks relevant. For others it's a combination of: would it be easy for them to move, have they worked remote (and can do it in a region where I have a tax entity) and how strong of a fit to the role is the CV, lots of experience in games would be what I expect since I work in video games - but if you're going for a backend programming role then: what have you built and what do you list as your responsibility to achieve it?
With this mindset I managed to build a high performing, high trust team that executed very well on (literally) impossible demands. If the ownership of the company was better that team would have easily been world class.
We also exceeded dunbars second (clan) number with the size of the team, so it wasn't intrinsic to small teams (80+).
He mentioned that Oxide has an interview process that takes 20 hours realistically between coming up with work samples, answering 8 questions before hand and 9 hours of in person interviews.
For their “senior” engineers it’s in the range of offers for I’ve seen for new grads at most of the tech companies and around the range of generic enterprise CRUD developers.
No offense to “enterprise developers”. I spent 25 years as one. But why would I jump through hoops for a job that pays about the same as I could hypothetically get based on interviewing for a few hours and asking generic behavioral questions and maybe some techno trivia about whatever language the company uses.
I find it fascinating that companies want rockstar ninja developers but then offer meh compensation for the positions.
So (foolishly?) I had never bothered to check Glassdoor, because we have been so upfront about our compensation.[0] But apparently that was a mistake! If it needs to be said, the Glassdoor numbers are comically wrong -- and in fact the high number in the "Engineer" range was quite a bit less than what we payed everyone six years ago!
First I’m going to make an argument and then immediately refute it before someone else makes the argument. That $235K is still lower than what mid level developers make at any of the BigTech companies.
Yes, that’s true. But they are all toxic hellholes where everyone is jockeying for position, making sure they show “impact” that looks good on promo docs and they all have RTO mandates even for positions that were formally “field by design”.
$235K and the ability to work remotely is something I would definitely think is fair (and a little more than I make now that I’m outside of Bigtech working remotely) as long as you give cost of living increases and is more than most developers will ever make inflation adjusted.
The other point you make is that performance is just a form of stack ranking and even hard work is usually just awarded with a 1-2% raise more than someone else gets. Why not separate it from comp?
I also like sales having variable compensation that is based on performance. I work somewhat as a post sales architect and I have an appreciation for the sales side more than most engineers.
Big tech companies have mostly figured out some kind of infinite money glitch. I don't think comparing compensation at them to startups makes a huge amount of sense. (It makes some sense from the perspective of how much money's coming into your bank account—just not a huge amount.)
Being a prominent face at a startup can also set you up for greater success in your career than being one of a hundred thousand at a bigco.
And as you touched on already, the environment at Oxide is a million times better than the toxicity and empire building that happens at bigcos.
Honestly, I'd say the best setup would be something like:
1. Live coding/code review/take home test
2. Technical discussion about said test/project (and the company's tech as a whole)
3. General team discussion/culture fit interview
That's because at the end of the day, you really want to filter out the folks that can't do the job as quickly as possible. If someone needs AI to code, can barely use a computer or writes poorly thought out, inefficient code straight out of the last century, it doesn't really matter how charismatic they are or how well they can discuss where they want to be in 5 years.
Way too many companies do things the other way around, and waste far too much time because of it.
Oh, and definitely make sure your questions are specific to the tech you use/field you work in. I still remember having a tough time using React at a certain company because the interview process didn't require any modern JavaScript/SPA knowledge and I'd managed to pass without ever having worked on that sort of web app before.
Similarly, I also remember seeing a WordPress dev agency using Google style leetcode interviews to filter out applicants. Made me wonder how many people they actually managed to hire that way, given that the pay being offered was pretty low, the work wasn't particularly appealing to the people who'd pass those interviews and the requirements to pass the interview in general didn't match up with the job at all.
> most interview questions have very little to do with day-to-day responsibilities. all good software engineers are generalist and live coding does not select for generalists
If I had a dollar for every time I heard this (flawed) argument, I’d be rich and would no longer have to sell ads on my Hacker News comments. I’m going to get hate for this unpopular opinion but here we go.
So often, “But Leetcode isn’t like REAL programming” is the siren song of the programmer who probably overestimates their coding skills and experience.
Yes, I hate to say it - live coding is actually one of the best signals you can get on a candidate’s seniority and ability to program a computer (and more importantly, their core computer science skills). A good interviewer is trained to know how to probe your CS knowledge during this, and will watch how you structure code, break down problems, debug, and think about testing. They will even ask you to make changes to see how coachable you are and what you might be like to work with. It’s not about inverting a binary tree while sharing your screen, it’s about showing me how you solve a problem, then translate what’s in your head to code.
Take home exercises provide little to no signal, and screen out people who have families (who wouldn’t bother with a 4 hour take home exercise after work). I don’t want to see how you Google, I want to see how you think.
These candidates always want some version of, “But trust me, bro! Hire me: I’m a senior engineer, I don’t remember how to Leetcode! I’m good, I promise!” But what they won’t admit to themselves is that a good senior engineer is able to do all the things a junior can do PLUS all the things a senior can do.
It’s not perfect, but I won’t hire anyone that can’t pass a live coding round.
This comment brought to you by Poppi. Poppi: it’s soda for people who are silly enough to believe soda can be healthy.
>Take home exercises provide little to no signal, and screen out people who have families (who wouldn’t bother with a 4 hour take home exercise after work). I don’t want to see how you Google, I want to see how you think.
I tend to think that's very possibly true of developers (especially if they haven't worked in open source) but I wouldn't generalize that some combination of pointing to samples of past work and/or a take home isn't valid for a late-stage interview/demo in general. Jobs that involve a lot of writing or presenting, for example, probably require some demonstration of ability whether pre-existing or created for the purpose.
I'd also say that one mistake along this line was taking one such sample and assuming that it was close enough and could be upleveled with a bit of work.
I helped my friend from university get a job by helping him do their take-home exercise. I didn't write the code for him but I walked him through pretty much every single step. I'm not proud of that but my friend needed a job and I was in a position to help him get it. My principles are not nearly as important as that job was to him.
Yes, people can cheat. In my example, you can mitigate by having them also do a live presentation and ask probing questions about what they've written if that's part of the job.
The coding equivalent would be asking them why they took some specific approach or used a particular algorithm. I'm not sure about my feelings with respect to coding takehomes but there are circumstances where someone doesn't have an openly viewable body of work where takehomes can make sense.
There's a difference between live coding round and leetcode rounds where you need to perfectly write code for as medium or hard leetcode question in 20 minutes.
2) if you have thousands of applicants for a position, and probably a dozen stand out by passing a really tough bar, wouldn’t you want to find those dozen?
> 2) if you have thousands of applicants for a position, and probably a dozen stand out by passing a really tough bar, wouldn’t you want to find those dozen?
It's a reasonable assumption, but you might not. If the role doesn't actually require those skills you might hire someone who's going to get fed up and leave in 3 months or (worse) who invests time in making their job more interesting instead of solving your actual business problems.
The question is, however, whether this is a good proxy for one's future colleague and employee.
I have no idea what could be a better option (well, maybe preparing some small feature to work on together), but it often turns out that good problem solvers are not really great at doing the job, for reasons that have nothing to do with the hard skills.
> It’s not perfect, but I won’t hire anyone that can’t pass a live coding round
I'd like to add two points to this:
First, I like that you said "live coding" rather than leet code. The floor for live coding should be super low, with a high ceiling and lots of flexibility. That allows you to say, nope, they didn't pass the floor level, easy binary decision, no hire. Pick a fun toy to build in 90 minutes and the high ceiling + flexibility will yield tons of signal from applicants.
Second, I see live coding sessions like this as a positive sign from potential employers. It lets me know that my future colleagues will have some baseline level of competence. If you've worked on a team that didn't do live coding, and you've had to carry water for someone who can't actually do the day-to-day technical "hard skill" work of software engineering, you probably feel the same way. Never again.
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.
Sounds like one of the many, many alternatives which "works" by just targeting a different subculture. This "representative body of code" idea is very strange to me - I don't have any such thing that I could bring to interviews, it's never occurred to me to write one, and my areas of specialization offer me no opportunity to generate one organically.
If this were the standard interview process, of course, I'm sure I could figure it out. There would be a site called "Leetportfolio", and I'd prep for interviews by implementing dozens of Leetportfolio mediums, and people would come to HN to complain about the obnoxious companies that expect you to include some Leetportfolio hards. For me this sounds significantly more time consuming and no less artificial or frustrating than Leetcode grinding.
>If this were the standard interview process, of course, I'm sure I could figure it out. There would be a site called "Leetportfolio"
It's called Github.
After about 150 interviews, I could do the "just talking" thing without needing any samples or anything else. If they were working on Java, I would ask what versions, what issues they had run into, what their experiences had been with various frameworks they mentioned on their resume, I would bring up recent events to see if they knew about them, just stuff like that could tell me whether someone was senior level or not.
Recent events in... Java? It seems entirely reasonable for a senior developer, at least in a company that's large enough they're not writing their own development environment, to not know what versions they've used or keep up to date with Java language news.
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.
My preferred loop is:
15m recruiter screen (1hr Take home goes here if you’re doing it) 30m hiring manager call 1hr tech interview 1hr team fit
And a go/no go at that point. You can put the hiring manager call at the end if the hiring manager is a senior enough person that you need to protect their time.
The tech test should be actual code, but not evaluated for syntax. I like a code review test but we’ve also done problem solving and writing pseudo code in the past. No let code, no algorithms and no tricky formulas. If you want one of those you should provide the formula. A good tech interview should be open ended enough that you can dig into whatever direction the candidate goes - if they go hard onto concurrency then follow that track, or if they go into testing then follow that track.
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 don’t necessarily disagree but anyone who is a c++ programmer and sees
And doesn’t immediately question it doesn’t instil confidence.Interviews are inherently high pressure situations for the candidate, the only way to avoid that is to just let people try out on the job and fire them if it isn’t working out. That’s unfair to everyone.
Forgive me, I'm a Java programmer.
The glaring bug here is that ptr is - or rather the object being pointed to is - on the heap and allocated in the constructor, but the deconstructor doesn't free it?
- ptr isn't declared in the class body
- ptr is not being deallocated in the destructor
(personal preference - use of class member without explicit `this->`)
> "ptr isn't declared in the class body"
I would assume the interviewer messed up and forgot to declare it and if I just not pretend to assume it was "left out for brevity" I would fail the interview as a smart ass.
There are so many layers to interviewing and you kinda need to guess what the intervoewer wants to hear.
In my defence, this is a HN comment thread and not an actual interview. I wrote that on my phone at 6pm on a Sunday.
We have an actual question, a snippet of code that is copied and shared to the candidate, and everyone who asks this question has undertaken this exercise. The interviewer has the list of (known) issues and a handful of stylistic things that can be talked about too. If we actually did share this snippet with someone and they said "should this be declared in the class body", I would say "oops yeah, thanks for catching", and update our template.
>you kinda need to guess what the intervoewer wants to hear
Interviewers are human, and I've done tech screens for probably 250 candidates over the past few years, and I've designed tech screens that have been used for probably 5x that. We have good days and bad days, and it's super tough to give an evaulation of someone in an hour. The main thing I'm looking for (and I tell people this) is someone that I think would be a good fit on the team. To me that means that their own read on their level is roughly equivalent to my read on their level (a senior engineer who says they understand concurrency but doesn't understand what a mutex or atmoic is is a fail, for example), and that they're not a giant pain in the ass. If you've managed to annoy me in an hour by assuming every single thing I do is an attempt to catch you out, we're not going to get along and I'm going to pass on you for that reason.
If ptr is some kind of global, then it makes sense for it not to be deallocated by the destructor? It’s apparently not really managed by this class, so why would its lifetime be tied to it?
I mean it’s psychotic to half-manage it like this but I don’t think the lack of a destructor is suspicious here; in fact I think it’s correct once the global pointer was introduced
IMHO, there are two review branches to discuss in this example:
First, if `ptr` is declared in the translation unit before and outside defining `class foo`, then there is no check for previous initialization and thus is likely a run-time defect.
Second, if `ptr` is not declared in the translation unit before and outside defining `class foo`, then it is likely a missing member definition and is a compile-time defect.
Does this example even compile, given that ptr is not declared anywhere?
>Does this example even compile, given that ptr is not declared anywhere?
that comment was not a comment but an interview. and you just failed it.
Nope, I also missed a semicolon at the end of the class definition. But I wouldn't ding someone for that in an interview.
How could you ever know whether that’s the case? Obviously it makes sense to try to conduct the interviewer with a low-pressure tone, and perhaps make accommodations for people who seems especially nervous, but at the end of the day I don’t think a job interview has meaningfully higher pressure to perform than, say, the first few months of a new job.
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.
It sounds like you should just use better programming languages that don't break constantly.
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?"
> I didn't do that well on it just because I was nervous as hell.
The problem is everyone gets nervous. The only way to avoid that is paid work trials and to decide whether you want to keep hem after 90 days. But that requires the person to quit their job.
> "hey look at this class from our codebase and tell us what's wrong with it!"
Ours is a self contained example, littered with absolutely obvious errors that anyone who has written the language being interviewed for (C++) should be able to spot a least 2-3 issues with. There are absolute glaring fundamental issues in about 50 lines of code and you are explicitly told there are numerous errors with it.
> 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.
It’s a self contained class that is littered with basic errors and doesn’t actually do what it’s supposed to do. There’s about 15 things wrong - missing pointer checks, uninitialised variables, public variables with private get/set functions, a memory leak, logic bugs that don’t do what the prompt says it’s supposed to do, subtle behavioural issues that come up in edge cases. We’re not looking for every single one, but there is an alarming number of people who cannot identify even the most glaring issues of “there’s a new in the constructor and not a delete in the destructor”.
> Or did they really get by with writing broken C++ all those years without knowing the basics?
Having inadvertently hired a handful of people, it’s this. They write shonky c++, it just about works, but they spend all their time patching up the mess they’ve left behind rather than doing it right in the first place
> I'm not 100% certain it's wrong with just 50 lines of context.
These are blatant issues that we would expect a reviewer to catch in isolation. It’s also an interview, we expect you to ask questions. You’re told as part of the brief to ask questions if you’re unsure. It’s not a trick, we’re looking to see if you can actually write the code or if you just can rattle off some of the rules.
A good example is DIY. How do you install a shelf - you drill a few screws into the wall and stick a piece of wood on it. Being able to tell you that is very different to being able to do that level on a wall. I can tell you “use SQL to select the name of the users who have used X resource without any duplicates”, but I might not actually be able to write that query (“select name from table group by X where Count(X) > 1”)
> I think C++ is a special case when it comes to interviews.
I disagree. Give me a language and I can give you 50-100 lines of code that just about does what it’s supposed to do but is littered with issues. Offhand I could write the same thing for C#, go, python and SQL with very little issue.
Thanks for the additional detail. It sounds like a great interview question; it's both easier, and yet more real-life, than something like "write fizz-buzz".
I mean... it might run or compile but our best case scenario is what, javascript where it returns infinity? But I'd certainly take issue with any program where I saw an explicit division by zero. If you were just trying to create an infinity there's got to be a good explanation for doing it that way.
It could trigger an exception which is caught elsewhere, or round the number to Inf or -Inf. It's a "clever" (aka, stupid) way to do these things, but it might not technically be wrong. It is possible to have well behaved and reliable code doing such a thing, unlike UB in C++.
[dead]
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.
[dead]
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.
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...
I'm 52 and as soon as they figure that out it is pretty much over, anyways. I'm not looking right now, even. I think my career is closed down, but not totally sure yet. I was passionate about my work for a long time, but after awhile I realized the same issues were grinding me down repeatedly and one of them was the average quality of new staff was becoming pretty bad. There would be like one truly inspired developer amongst 10 or 20 so-so ones and that inspired one usually had some kind of work ethic issues, e.g. serious apathy about everything in life. I'm not saying I'm great, because I had times where I wasn't too motivated, either, but I bounced back from burnout 2-3 times and was truly on point for a lot of years at some pretty un-charming companies. So it goes, so it goes.
Then don’t be the median candidate? If you are the median candidate in today’s market randomly submitting your resume to an ATS and trying to get by based on your ability to grind leetCode and reverse a btree on the white board, you’re screwed anyway.
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.
I don’t think I’ve ever even proffered “passion” about software development or whatever random B2B SaaS vertical the company was doing.
I show proficiency, professionalism, expertise, and the ability to bring that to a job.
I’ve had 10 jobs everything from startups, random big enterprise, and BigTech.
Am I suppose to show passion about - bill printing? Field services sending technicians to people’s houses? Railroad car repair?
Admittedly my first job as an architect was for a company that managed sending nurses to the homes of special needs kids and the next two were in the health care industry, but after that it was dealing with cloud consulting (full time jobs) first at AWS directly then other consulting companies (currently a staff architect at a 3rd party cloud company)
I can talk about technical solutions, be a post sales architect, lead implementations and do system design and coding all day long without being “passionate” about the business. It’s just professionalism and my addictions to food and shelter
Passion can show itself in many ways. Why did you pick programming of all things? There's something there, right? If you can dig into a topic, that's a form of passion. If you're willing to put in hard work, that's a form of passion. These may not be the same thing as the person who gets excited about these problems, but something did drive you. And no one is so excited about coding that they are never dispassionate and never frustrated. The thing you're looking for is why should I trust that you have these skills? If there's nothing you can rant about, then I'd find that odd, even if you see it as a paycheck.
I picked programming because I was a short (still short), fat (I got better) kid with a computer in the mid 80s.
You can “trust” I have those skills because I can talk about my past experiences, you can throw any architectural or business problem at me and I can talk through it including tradeoffs and why I made the decisions I made. How I deal with organizational challenges, etc.
My being able to dig into a topic is not “passion”. It’s my job. I get paid to know my subject matter deeply and to be able to ramp up fast on technology and the business domain.
The deal is if I work at your company, you agreed to give me $x amount of money, benefits and for me remote work and in exchange I agreed to give your company all of my expertise gained over 30 years of working for 40-45 hours a week.
You need me to code those 40 hours a week? You got me. You need me to be on a zoom call or fly to a client site? No problem. You want me to do pretty diagrams and spit out 40 page requirement documents or business proposals? I can do that too. Along with leading projects, cloud architecture, etc.
Just understand, you get 40-45 hours a week. You don’t get late nights, you don’t get on call, you don’t get weekend work, and my bullshit tolerance level is relatively low before I am looking for another job - ask my last nine employers.
Okay, so it seems like for the most part we agree in concept but disagree about the words used to convey them? Do I have that right?
I laid out what __I__ consider different forms of passion and while explaining yourself you met some of that criteria. So I'm not sure where the anger is coming from. I hope you're doing okay and I really hope we can have fewer abusive employers. I'm really empathetic to that, and have quit several jobs because situations like you mention.
It’s not anger. I get tired of employers taking advantage of naive younger developers who have “passion” and underpay them and overwork them, expect them to have open source contributions and as you said yourself, if someone is “passionate” money isn’t as important.
These are the people who don’t show “passion” unless when they get off of work they are doing side projects related to software development and usually end up getting burned out.
I’ve also avoided burn out, stress over work and I am able to survive in the industry for 30 years because I understand the transactional nature of the job and set boundaries.
Someone who does there job well doesn’t mean they are “passionate”, they are “professional”.
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.
But we are professional engineers, not students.
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.
> 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
Hey, that's my PhD entrance exams!
Sudden death?
Most devs are not engineers, and has not passed a licensing board or belong to any professional associations.
Most devs are doing work that more closely resembles pipe fitting or carpentry than any engineering discipline.
I have a Bachelor of Software Engineering. The degree is fully accredited by, and I am a member of the Australian Institute of Engineers.
We do exist, but as you said very rare. There were 12 of us in my graduating class in 2004.
This is an interesting point. Most US universities are accredited overall, but their individual engineering programs aren't always accredited by engineering accreditors.
For example, UC Berkeley's EECS department lost its ABET accreditation in 2020 (which it had maintained since 1983.) Stanford University lost its ABET accreditation in Electrical Engineering in 2014 (which it had maintained since 1936.) In contrast, nearby Santa Clara University and San José State University both have ABET-accredited EE and CS programs. So, consider hiring some of their graduates!
Many computing professionals are members of professional societies such as ACM or IEEE (and many are not since they don't see the value in the expensive dues.)
What has also not been widely adopted, and has even been opposed, is standardized professional engineering certification (exams, licensing, continuing education requirements, etc.) for computing professions such as software development.
I think this may be related to the computing industry's remarkable success in avoiding liability and associated regulation, particularly for software and online services.
Perhaps of interest: https://www.nspe.org/career-growth/pe-magazine/may-2018/ncee...
> devs are doing work that more closely resembles pipe fitting or carpentry
Yet plumbers and carpenters (and electricians) are all licensed.
> 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:
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.
It's not like all engineers are certified. And people have tried to create certifications for programming, they just suck.
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.
Sounds like you’re arguing for a professional licensing regime to exist
There should be. Engineers are liable for their failure.
And on the plus side that liability also provides people a lever with which they can push back against stupid managerial decisions. My father was an aeronautical engineer, and his favorite word to say to management was "No". Yes, the engine inspection takes a long time. No, I cannot cut corners in any way just to save you some money (No idea if this is just one of his stories or a real situation, but you get the idea :p ).
I don't know why people are so against it in this field
> I don't know why people are so against it in this field
Because the vast majority of failing software just means inconvenience, rather than disaster.
Tell that to people having their identities stolen every time a data breach happens.
We have this idea that gatekeeping in all its forms is bad; and like all absolutes it is not true.
> and like all absolutes it is not true.
Like this absolute? ;-)
In software at least, professional licensing exams basically petered out because no one required them so no one cared.
My guess is that it would impede outsourcing and end up costing companies too much money.
In general, licensing is for regulatory reasons (e.g. signing off on drawings). Engineers don't generally do it unless there is some industry requirement to do so (especially in civil engineering). And there mostly isn't in software.
I started the engineer-in-training track when I was in the offshore drilling industry but then I left and never went back.
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.
It's hard to get better when you don't get feedback
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.
I'm getting pretty old and have done a ton of interviews at this point in life.
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.
Poorly is different then hitting 90% (maybe?) of the way there but still rejected. Or conflicting responses from different interviews. Like you did great on the coding then the next company thinks you did poorly.
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.
I would probably adjust my original post to say you cant better without useful feedback.
I always ask for feedback after an interview, its almost always useless. And conflicting between company interviews.
Its pretty rare for me to totally bomb an interview to the point i don't know the question. Usually the situation is I answered the coding question, handled the follow ups, wrote working code and still get the feedback that the coding portion didn't go well. How do you use that feedback? Useless imo.
Self reflection amend critique are skills too.
I’ve only been able to book two “phoned-in” (literally and figuratively) interviews in the past year. Not enough to get comfortable.
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.
Agree. leetcode is the greatest thing that happened to tech interviews.
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.
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.
> In my experience the more impressive somebody is at leet code, the worse their production code.
Used to think this too, until I met some truly impressively bad engineers where I'm pretty sure they would not have passed a leetcode screen either. People acing leetcode is at the minimum a good signal for people having the patience to sit down and learn non-trivial things over a somewhat longer time period by themselves.
Leetcode is all local cpu. Production code is all waiting for network responses.
>Get good at it
>with no prep.
You contradicted yourself in the same sentence. You can't get good at leetcoding interviews with no prep
After getting good at it, there is no "additional" prep time, unlike take homes, where you would need to spend hours for every individual assignment. Is that so hard to understand?
>After getting good at it
Do you know the "use it or loose it" phrase? How long do you stay good at leetocde to not require anymore prep whenever you interview again?
For some people, doing an AI assisted take home might take less time than having to restudy and re-exercise leetcode for months which they won't use again. Plus a lot of people suck at live coding when put on the spot due to anxiety, which means even more time investment for something not related to work.
>Is that so hard to understand?
I understood just fine, I'm calling it out as being incorrect for a lot of people.
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.
yes agreed leetcode as interview technqiue sucks but its great for interviewers. i am just a powerless cog playing the game trying to provide for my family.
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
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.
hmm most of the take homes I ever got had a 1 week to complete but I guess I see it, I don't think I've ever been trying to get on a company that is hiring more than a small time at any time.
meta, google, amazon don't have take home
Basically all big companies doing industrial scale hiring ( and firing) that don't have time or patience for take homes.
In Australia, AWS dev position in 2021 had a take home. Microsoft contract position before that didn’t but they were desperate to fill seats on a poorly executed gov contract.
GitHub (pre-microsoft at least) and Crowdstrike both did. Amazon didn't have a take home so much as a "prove you can write code with this simple problem" though that was also pre-AI days as well.
> Basically all big companies doing industrial scala hiring ( and firing)
Is Scala the right choice for hiring and firing, though? If they need to fire quickly, why not straight machine code?
I believe this is a typo for SCADA, which would control the industrial machinery used to fire employees in order to ensure distance and accuracy.
to pretend that they care about safety
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.
What year?
2010.
It didn't hurt that the person in question ran the products group. (And I went to the same school as the ultimate hiring manager.)
People obviously have different experiences at different companies but networks matter a lot in many cases whether a lot of folks like it or not.
Things still took a few months to coordinate meetings and interviews but it was still the only job I (sort of) applied for.
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.
I love take home and don't like leetcode, so I was thinking: choose a company based on how they interview, might help with culture fit?
> 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.
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).
That’s a good point, although of you’ve interviewed at big tech, plenty of times they’re just treating it like a standardized test.
> 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?
Our process is fairly simple:
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.
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.
> We are doing coding challenges
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!
> veto right
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.
Francis Fukuyama calls this system (everyone gets a veto) a vetocracy, and it basically means that nothing ever gets done
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.
By that logic, you should be paid for every minute of the interview process.
Which is a reasonable stance to take! But not if you want to be paid for take homes, but not for interviews.
Please operate in good faith[0,1]
I think any reasonable person can interpret that there is a meaningful difference between an hour of work and several. The same way you might drive your friend across town for free but you're probably going to ask them for gas money and some beers if they ask you to help them move across state. An hour of my time is just less valuable than my entire day.
[0] https://en.wikipedia.org/wiki/Reductio_ad_absurdum
[1] https://news.ycombinator.com/newsguidelines.html
Maybe you’re not as reasonable as you think
Probably. But it is hard to figure out where I'm wrong if you just say I'm wrong and don't say why. Or you say why and use a logical fallacy ¯\_(ツ)_/¯
(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.
Have you ever integrated code a candidate wrote into a code base? Have you ever met anyone that have?
Ask yourself why not
[flagged]
I did. I even read the whole comment
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.
Everyone says that until they start sitting in on interviews and someone is wearing a confederate flag shirt or their areola is clearly showing.
Usually dressing professionally refers to standards that are quite different from that, so if one wants to say that they're checking for things like that it would be best to make that clear.
How do you select the people who get to talk to your CTO?
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 )?
Edited.
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.
I understand you and did the same in the past.
However, here we are talking about at the general level. Not a single instance as your experience.
Engineers are hired for engineering jobs not for manager jobs or mopping the floor.
On the other side, if a lately hired person wasn't find himself comfortable inside the team, I, _as manager_, can always complain the team and accuse them being guilty because they weren't able to say NO at interview level or because they said YES at the wrong candidate. Do you see the faulty thought of our time? I as manager earn a lot for managing people but in reality I download my responsibilities of not being able to interview a candidate and so find the right person _downloading_ that on the team that actually is not responsible for new hired person. Fantastic.
Than's the meal they want you digest in some cultures. In mine, as manager, I decide who is on board, and I clarify clearly the roles of every one. No space for interpretation.
I din't come out from a manager school, but I started from the ground and I put myself _every time_ in the shoes of who is managed by me.
My humble opinion
We get it. You are a manager.
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
2. Then they do the take home challenge, or you hire another candidate.
This is not kindergarden anymore. We're taling adult stuff here. If the manager is not able to interview, analyse and understand who is in front of him, then it is time to change job.
Iff the candidates has personal work to show then it is considered a plus, but it is not madnatory.
3. No, normal wage and is expected of them.
A hired person is supposed to fill a role and not a double or more roles just because the manager is not able to subdivides tasks, roles etc. I don't expect engineer or technical roles to do manager job.
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
It might work in your culture.
in my culture, who is going to take a manager role _manages_ technical people _and_ as such he _must_ know the technical stuff to a certain degrees otherwise the job is not for him. Here managers don't download their responsibilities to engineers they manage.
At the same time, engineers are not supposed to judge or like or dislike their coworkers. Working in a team is a prerequisite that they have to accept, either you like it or not. Full stop. There is no space for interpretation or for leisure. They have tasks and they finish their tasks. Full stop.
2. With us it is. Not for seniors, but juniors, interns, people out of college, we want to see how you program so we know how much effort the training is going to be.
3. We do not fill multiple roles. But if a person might join your team, the team gets to talk with the candidate. This always also becomes a tech talk because we’re developers and we like talking about it. That’s not a second job role at all.
4. Our managers are tech people. They are not always actual developers though, or might’ve been 20 years ago.
In general it goes like this: Junior? - talk with manager and tech lead of the team, just about who you are, what you’ve done and what you’re looking for. All to see if you are a match personality wise. - if we liked the talk you get invited for a technical interview. You go sit with the team as they work, you get to do some challenge. We’ll help you and discuss your solutions - we all together decide yes or no
For experienced developers we have the same, minus the coding challenge. The talk with the team is more about the personal match, but it usually is about tech stuff or what we’re working on because the candidate is curious.
I find it very natural and relaxed. The team eventually decides themselves which candidate they prefer.
Also I have no idea what you mean by there not being time for leisure. With us there definitely is, and liking the team you work in is very important to us. If you don’t like it or it’s not working we might place you in a different team where you match better. Or maybe you don’t think the apps we work on are interesting, but those of another team are. Why shouldn’t working somewhere be enjoyable?
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.
You made your edit before I posted.
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.
I meet a few college CS candidates, and I really empathize with what they’re facing now.
I feel like the industry is far tougher to get into now than when I joined.
I sent out maybe 10 applications, got a few interviews, and 1 offer.
I hear of kids now sending out dozens to hundreds of applications with few bites.
Makes me sad for the stress they must feel.
Historically, I'm not sure that isn't fairly normal.
But compared to maybe the decade plus prior to a couple years ago for (especially junior) software developers, it seems like a tough market based on a lot of conversations irrespective of overall unemployment rates.
Last time I was looking, a year or so ago, I sent out dozens of applications and got zero interviews. Last time I switched jobs, in 2022, I sent out the same amount of applications and >50% led to one or more interviews (and eventually two offers).
“Okay boomer” (said sarcastically - I’m 51).
In 2023, I was Amazoned after 3.5 years and found myself looking for a job. Even worse, by then I had moved to an area that was tourist heavy, but not really tech heavy and was looking for remote only jobs. The remote role at AWS just kind of fell into my lap.
Plan A: Leveraging my network. This led to two offers both architect level positions - one over the architecture and migration to AWS at f500 company and the other over the architecture of PE owned company that was doing rollup acquisitions (been there done that).
Plan B: targeted outreach to companies looking for expertise in a niche of AWS where at the time, I was one of the industry experts and was a major contributor to a popular official “AWS Solution” in its niche.
This led to two interviews and one offer.
I basically had three offers and a side contract within ten days of looking.
I’m not bragging, I’m old. I should have a network to lean on and a reputation. The point is that even with my experience, if that well above had run dry, I might have been screwed.
I also applied for hundreds of jobs during those two weeks while going through the interview process with my first hits. I heard crickets and for every job I applied to, it had hundreds of applications and my application wasn’t even viewed by most and my resume was only downloaded once (LinkedIn Easy Apply shows both).
I was not some old guy (well I am) with outdated skills. At the time I had over ten years of software development experience (on my resume) and 7 years of AWS experience including 3.5 working at AWS (ProServe) leading relatively complex projects.
>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.
Not sure if they're still doing it, but GitLab does the code review interview, and I too really liked it.
Before the interview, you clone the repo and get the app running on your machine.
For the first half of the interview, you review a pull request in real time. There's a mix of obvious and non-obvious callouts. And the second half, you actually implement your suggestions.
Honestly the code review portion alone is a great indicator of a dev's experience and soft skills.
This is how interviews should be conducted. Both as an interviewee and an interviewer I have had the best experiences with this style.
I'd love to hear if anyone has critiques of this style.
The situation is not going to improve as long as business stakeholders and engineering managers (some closer to MBAs than actual engineers) think of software engineers as construction workers. They think we are fungible, they don't understand the craft of programming etc, and have very short term mindsets. Took me a while but then I realised that I needed to interview my prospective employers as much as they were interviewing me, and to just ignore those not worth working for.
> "They think we are fungible"
Most software people do web front end or web back end or CRUD. Most of the rest do apps, whether mobile or desktop. What's non-fungible about us?
At the very least understanding of the specific domain comes to mind.
> I realised that I needed to interview my prospective employers as much as they were interviewing me
This is so important, and most of the “fit” problems working I’ve experienced are because I didn’t weigh something heavily enough in the interview.
If you are even the slightest bit concerned with an employer, that is a red flag in your long-term prospects there.
For example:
- If your future boss seems even a little clueless about the job itself, you may be lucky to find adequate structure or information available to do your job well.
- If your future boss seems guarded, they may be hiding something; they may not be equipped for the job or could be a psychopath.
- If they have greater than average benefits or the recruiter calls you a rockstar, it may be some form of hell, and you won’t find that out until a few weeks in.
- If more than one person seemed like they were afraid to say something during the interview and were very quiet, either the environment there will be weird or it may be a serious hell and/or there is no chance to be able to fill the shoes of the person that left.
- If you sense that they overestimated your ability or you overstate something accidentally in the interview, you may not overcome that as much as you want to believe in yourself. No, you can’t make up for years of experience with hard work. Your LinkedIn profile description must be essentially you, with the burrs removed and buffed up a little; It’s not just to get past a machine or recruiter.
- If anyone you interview with is an arse, even if they work in a different team, that’s not a good sign.
- If you are ___, and no one else there is, that may be a serious problem. This is age, sex, religion, politics, number of kids and ages, pets, what they do/don’t do socially, emotion, humor, tech stack, clothing, what vehicles they drive, style of workplace, and everything else that either you won’t like or they won’t like about you. Diversity is a sham if you’re the only one different, though I know that some may not ever realistically find a place to fully fit in.
- If you join when they’re hiring others for your team at the same time, and the business itself isn’t growing significantly, that can be a bad sign.
- Claims that they don’t fire people are a lie or a hope.
None of these are absolute rules, but find your people, and if anything doesn’t seem right or seems too good to be true, it probably is. Weigh that extra salary against the impact of having to find another job if you quit or are let go later.
> If you are ___, and no one else there is, that may be a serious problem. This is age, sex, religion, politics, number of kids and ages, pets, what they do/don’t do socially, emotion, humor, tech stack, clothing, what vehicles they drive, style of workplace, and everything else that either you won’t like or they won’t like about you. Diversity is a sham if you’re the only one different, though I know that some may not ever realistically find a place to fully fit in.
This is impossible to satisfy below a certain company size. And beyond the things that can't realistically be hidden, I would prefer not to know a lot of that about my coworkers, and would prefer them not to know those things about me.
We are fungible. Most software development is not rocket science. If any of us got hit by a bus tomorrow HR would send our next of kin “thoughts and prayers”, a flower and tell them how to collect our life insurance and then immediately open a req and get flooded with hundreds of probably good enough replacements.
It sounds like what you're arguing for is that companies ought to have employees that are irreplaceable. Wouldn't that impose a huge risk to the company? If said employee gets hit by the proverbial bus or leaves, the company should just fold?
Companies need to build systems where everyone is replaceable to de-risk the business and not because they don't get programmers.
If a company doesn't have irreplaceable people, then that company is not doing anything interesting. Conversely, if replaceable people can produce your (software) product, then any other company can also do it.
As much as I don't like LLMs that much personally, do you think ChatGPT was produced with replaceable people?
> Companies need to build systems where everyone is replaceable...
No they don't. They need to build systems where everyone is happy with their job and don't need to constantly hop jobs for better salary, environment, etc.
The way to mitigate the bus factor is not to make everybody replaceable; it is to have a process to develop more irreplaceable people with overlapping expertise in their areas.
Overlapping expertise is another form of replacing someone. At a basic level, employees need to go on vacation, parental leave and all sorts of other personal leave. If you were irreplaceable, you couldn't go on leave.
Companies who develop these systems successfully are able to allow employees to go on leave for 4-6 months and have them easily come back. This is a good thing.
But they ( companies ) don't. Looking back at my career, what you do get is, various ranges of alignment to an idea ( whatever it may be ). Some companies do it better than others. Usually, the smaller the company, the easier it is for the owner/founder/main guy to make sure his vision is appropriately enforced, but that gets so much harder in bigger ones so the systems they generate get progressively less sensible. And yes, I don't think search for absolutely replaceable employees shows any kind of faith in one's company. It does, however, show an interesting frame of mind that I personally like to avoid.
For all the talk about innovation, you don't get that by making everyone an interchangeable cog. You want at least some people, who are difficult to be replaced, because they are your competitive edge ( I am saying difficult, because I personally also do not believe anyone is truly irreplaceable ).
And again, the risk to a company, especially a tech company, is falling behind. Losing an employee is a fact of life type of risk; effectively unavoidable. Still, that kind of fake modularity is wrong, not because modularity is a bad idea ( it is not ), but because companies absolutely fucking suck at designing that kind of a system ( as evidenced by reality itself ).
All this is before we get to some of the more human aspect of all this ( up until now we were talking about companies as if they are a living thing with wills and what not and an amalgamation of humans, where one action is a function of thousands little decisions ) like: people messing with systems in a way that does the exact opposite of what the company 'wants'.
All in all, it is an interesting argument, and I even agree with it at some level, but I do not think it survives closer inspection.
It's crazy, I've been trying to hire an architect to build a house for me, but I don't trust them (they're all liars) so I asked them to draw up blueprints in front of me and describe everything they are doing in great detail. I need to understand what they are doing. This building is important and I don't want a bad hire. They should be able to do this in 10-15 minutes. If they knew what they were doing, this request wouldn't be an issue.
Then I was trying to get someone to do my taxes. So I've been asking every applicant to do my taxes from last year so I can see if they really know what they are doing. I mean sure, they've done taxes for years, but these are my taxes. I've even tried giving them math puzzles around asset depreciation, but people just keep hanging up the phone.
And then, I wanted to add a wing added to my house and I've been trying to get these entitled contractors to come build a shed in my backyard so I can see if they really know how to use nail guns. I've heard people are just big'ol lairs lately, and I need to see how they work. I mean, sure these guys have built many houses in the past, but we have high standards here and only hire A players.
I've only been getting horrible candidates! No one is worth hiring! There is a huge shortage of qualified people.
If only there was a way to fix this.
I can't tell if this is a snarky way to say we should have programming accreditation like architects and accountants have, or not knowing about accreditation and saying we should just trust the applicants more.
AI!
One of my favorite interviews (Mixrank) was where the CTO/founder and I picked a random problem on Project Euler and we both coded on it in parallel. I was in the driver's seat as far as design and general approach was concerned but we were each coding an independent solution. We weren't even using the same languages.
Once we both had the correct answer, we started optimizing to try and eclipse each others' runtime. This was actually a fantastic test to display deeper knowledge beyond just regurgitating a solution, showing benefits and drawbacks of different languages and patterns, and seeing how we could work while agreeing or disagreeing on a technical subject.
I was really too junior for the role they wanted and I didn't get the job, but it was a fantastic experience.
My best job (for the last decade) for a software engineering job was a 1 hour technical interview followed by a 1 hour interview with the director.
It helped that it was 90 days contract to hire.
At my first employer circa 2005 we had a simple 1-2 hour interview and a 90 day probationary period. Respected people's time, gave everyone a fair chance to prove themselves. I don't know why it's not more common in the industry.
Part of what lead to it I think is we hired largely straight out of college and doing a 9-hour interview with someone with little experience is a waste of time.
It worked great. In my five years there we only had a couple people not make it past the probationary period.
Well, historically, taking a new job often meant relocating which is a big expense for the employer (who typically paid relo for engineering jobs) and is hugely disruptive for the employee. Definitely not just a shrug for everyone concerned if things don't work out after a bit.
Less true in hotbeds for a given industry. But I've had relocation paid twice in my career and it was just a given.
Never in my 25 years has an employer made good on their offer to help with relocating. Often they expect you to be there already.
They’ll say they will help. Even have you fill out a form. Then when it comes time to cover the expense, they come up with excuses on why they won’t.
> They’ll say they will help. Even have you fill out a form.
Have they not formed a verbal contract in saying they'll help with relocation expenses?
It's been a long while but, especially as a young employee (presumably) expecting to have relocation handled, I'd be WTF; the relocation would probably have been a huge chunk of my salary at the time. Of course, at that point, you're probably just screwed and you're probably not going to get a lawyer over it.
I'm talking about somewhat longer ago but it used to just be part of the deal along with living expenses for a month or so in my experience for professional jobs.
Been working professionally since ‘97, still haven’t ever gotten a payment for moving expenses.
The way it's worked for me is I've been given a small relocation bonus and then I'm responsible for figuring the details out.
So assistance really just means punt
Having to relocate a long distance would have been a huge barrier for me both for cost and other reasons at the time. Obviously remote is a bigger option these days but far from universal. Glad it wasn't a problem both times I did even if the cost and other obstacles weren't as great at the time.
Would you really want anything else? I can't really imagine how you're expecting that to work.
In my experience the employer (2x) took care of arrangements for both the moving and the temporary hotel arrangements.
The one time I had an employer involved that closely they completely dropped the ball and I had to crash on a friend's couch. Again I don't think having corporate administration so closely involved in your life is a great idea just because of the dumb things they occasionally do.
The primary problem with hiring is that developers are a single status with not performance benchmark. The solution is to segment need by capability.
Let’s face the reality that most developers will never be able to write original software and just put text to screen using a tool or framework. Don’t call these people engineers. These people are the assembly line of software. Measure them according to desired patterns. They are copy/paste but smarter than data entry and understand some of the restrictions in place. Expectations are low and compatibility and replacement are the key business values.
Next are the people who test software, the QA. We expect more from these people and then work them harder for less money at a lower level of reputation.
Next are the people who evaluate software. These people are closer to engineers. These people include accessibility, security, and performance experts. These people are more like a combination of QA and senior developers. Evaluate these people on these criteria: written essay, technical knowledge, force them to measure things in real time and see how they perform.
Next are the people who actually write software applications. Let’s call these people solution delivery. These people are similar to junior architects and actually build things. These people should be evaluated only on the basis of organizational capabilities above that of the engineers that measure things.
Finally are the software owners. These people resemble a combination of project management and junior architects. They must have the experience to know how to build original software, like the junior architects, but also a planning vision to push though demands from competing stakeholders. There is busy savvy to this comes from a solid engineering planning vision plus superior communication skills most lesser software people never honed. Think of these people as senior principals with real authority. Evaluate these people on their delivery experience, using numbers, and reputation.
Now the issue is to identify them. All those types of workers will present themselves as Software Developers (or Software Engineers), so the interview process is not only an entry filter, but a classification filter too. You (as a company, or as an interviewer) need to discern which are the strengths of a candidate, and also the skill level within each of those categories.
> Next are the people who actually write software applications. Let’s call these people solution delivery. These people are similar to junior architects and actually build things. These people should be evaluated only on the basis of organizational capabilities above that of the engineers that measure things.
Why? People who actually write original software require many other skills in order to do so (just not, you know, marketing).
Writing software is no different than writing a novel or a music album. Its creating a product. All of these require the ability to write, but its more than just writing an essay. There are functional aspects that require different stages of planning and composition that must be put together in a way that can be maintained, described, and decomposed. Its that vision for composition and extension which requires organizational capacity drawn from lots of experience.
I agree with the article. Discussing previously created code and do code reviews live covers a lot of ground. Whereas live coding is just meaningless for the stated reasons.
But a 9-hours interview process seems just too much... I think you will only ever know a candidates true fit once you start actually working together and 2-3 short sessions with someone is enough to get that go/no go feeling.
You can't hire without taking risks.
Where I live, you usually have a 3-months probation time in which both sides can quit within a 7 days period... so the risk is manageable.
Just feel a candidates fit and then go for it... and adjust when necessary. Don't overthink it.
As long as someone isn't relocating, it's possibly reasonable. As long as someone is moving, there's a lot bigger barrier to taking a job. Mind you, there's is a barrier in any case if someone has a decent-paying job but just isn't loving it.
If I can get a person talking about tradeoffs - be it speaking to a past project, or a hypothetical I give them - then I think I can tell who the serious developers are fairly quickly.
> this also loses you taste
I won't forget the in-person interview round where I coded a frontend visualization for a data graph (tracking global shipping), then fielded a post-work general interview round from the whole company (~10 ppl) about specifics and "choices" made during a rush to finish. I ended up not going due to comp, but they were acquired months later. Life is funny.
> live coding does not select for generalists
I have a rage memory now of a "live coding" event that makes me want to leave this profession and never come back.
Here's my suggestion for the technical interview:
1. Applicant signs NDA and agrees to not use AI 2. A small bug or feature request is chosen from the backlog 3. The staff engineer pair programs with the applicant until it is fixed/implemented
This does a few things:
a) The interview is suddenly "productive" for the employer rather than a cost sink b) No one will apply that doesn't actually know the stack/framework/language c) The interviewer gets a real world example of what its like to work with the applicant d) Leet coding and puzzle solving is eliminated in favor of real world coding e) A secondary skill set that doesn't actually contribute to the work is eliminated (go pound sand autists)
I really loved the uno reverse card interview the author recommended. "Let's debug this piece of broken code"
This can spark so many interesting discussions, from syntax, architecture, cs, product etc
It is literally the job that engineers do 99% of their time yet we don't interview on this.
I also loved the idea.
Except it was wildly unpopular amount the other interviewers as t was seen as setting traps and watch if the poor guy falls into them.
And interviewees were sometimes dumbfounded looking at the code, and we didn't know if they were just crushing under the stress or had never looked at code in their life.
All in all, it wasn't that different from a straight leetcode interview.
Code reviews were basically the same, nice on paper but hard to judge in practice.
Disagree. Am a good programmer who can’t perform under stress or surveillance. A code review would be 10x less stressful than writing fresh code and enable me to show off knowledge easily, in a good way.
To dig a bit on this, setting up the review itself isn't trivial. I felt we were just applying different biases, which could be fine, but it also wasn't catching up internally.
For instance I personally use and abuse the online GitHub/gitlab interface a lot and am extremely familiar with both. But looking at my colleagues, many do code reviews locally, diffing in their IDE.
Some also don't navigate the code the same way and tend to work "bottom up" instead of "top down", which puts them at a disadvantage in time limited settings when they might be better reviewers in general.
Referring to the other comment wishing to get full A3 printout to look at the code, we also had a guy who used his personal laptop to interview and felt lost as he usually reviews code on his giant work screen.
Having the candidate choose could be the best of both worlds, but that' a lot more work on the interviewing side.
If I was asked to review code in an interview, I'd prefer it be printed out on a sheet of A2 or A3 paper that I could look over and write on.
Regardless, there should be a hard rule that if you show code (either working code or example code) to a candidate then it needs to stay visible for at least five minutes. No skipping ahead to the next slide or switching windows after 2 seconds.
For live debugging/fixing we were sharing a dedicated GitHub repo, and the candidate would share his screen while doing it. It was kinda of a mess, so I switched to a more static approach of sharing a MR and have the candidate explain what it does, and potentially comment on it.
TBH I wouldn't do that face to face, it's so unnatural I'd prefer white boarding or straight handing them a computer.
That's also where using an online coding platform where the candidate can run the code works a lot better, less preparation on either side, less surprises.
I generally make it a rule to not share my screen, install software, or create a new account as part of an interview process, so using an online coding platform is nice.
Debugging exercises reveal not just technical knowledge but also communication patterns - how candidates ask clarifying questions and explain their reasoning reveals more about their daily work habits than most algorithm puzzles.
The fundamental problem with interviewing is that you're not preparing yourself to understand a business' problem and needs, but you're preparing to have to impress your potential colleagues, a non-trivial number of which are already jaded.
Big tech can afford this because they have a constant stream of candidates.
job ads used to say "thrives under pressure" as a kind of euphemism
now they just use the interview gauntlet to test your will
its like those japanese game shows where they have 10 rounds of humiliation to see how far you can make it
Early in my career, most of the people I interviewed were not very good.
Eventually, enough time passed that the talent pool grew considerably and most people are baseline competent.
Consequently, I now find that respect and time efficiency matter a lot more.
The best interview process I’ve ever done is sitting down with the team for 3 days, crashing on the founders couch for the weekend and shipping code
The worst ones were the leetcode interviews I couldn’t pass
So glad I changed industries after my first s/w job out of uni wanted 2 hrs unpaid overtime per day and the boss ran the office like he was lord of the manner, swearing and blowing up whenever it suited him. If I had the skills these people want for the price they're willing to pay I'd just start my own business and reap the rewards myself. Most people aren't worth working for. Perhaps the pool of employers is far larger in the US which makes it easier to shop around for a good one.
The expression is https://en.wikipedia.org/wiki/Lord_of_the_manor .
Thanks, always helps the message when you grammar right.
> select for applicants who will be good employees for years to come
Why would you do this given the expected average tenure is probably like 18 months to 2 years?
They think everyone wants to work for ping pong. It’s delusional. All it takes is one bad decision to send everyone running. Leaders are so high on their own egos that they think no one would ever want to leave, but we do.
The issue I see is lots of companies put strategy into hiring from colleges and then are left with the low performers after 3-5 years. A good company will mix college recruiting with job fairs and LinkedIn/indeed ads to get good candidates and won’t pretend to be “a family” or enter cult phrase to try to attract talent.
I’m sorry. I don’t understand what your comment has to do with mine?
Tenure and young folks not staying longer than 2 years… read it again.
I’m agreeing with you and stating that corporate leadership is out of touch.
I disagree on the "taste" aspect: I don't think it's valuable to take that into account in the slightest.
A lot of the time, technical interviews and take-home exercises turn into 100 iterations of "Do you prefer vanilla ice cream or chocolate?" or "Do you prefer vi or emacs?"
A good employee will figure out the subjective tastes, biases, and cultural quirks of a workplace, and fit in. A senior engineer will have done it perhaps half a dozen times in their career. -- And yet, companies insist on putting interviewees in a situation of having to basically mind-read those subjective tastes and biases to try to tell interviewers what they want to hear, because they'll reject a candidate on the false premise that a vi guy will never fit into an emacs shop.
"How do you feel about unit tests?" I really don't have any feelings about them whatsoever. Just tell me, if you want me to write them or not. Instead you're asking me to mind-read and trigger some hidden trauma in you. I just don't know whether the trauma is that codebase that required breaking production every single day, because there was no way to test it. Or whether the trauma is that one guy that you hired who never got any work done because he obsessed over refactoring the codebase for optimal testability instead.
Well structured temp to perm arrangements are usually win-win?
I've been using a variation on the "Code Review" example for years, and really like it. I give the candidate some fairly straightforward sample code[1] that interacts with a Python library[2] along with a couple user stories that they are expected to implement. I tell them I'm both their product manager and pair programming buddy, and that they should ask me any questions they might have, use ChatGPT, consult Stack Overflow...whatever they do to solve the problem at hand because I'm just interested in seeing how they think.
No system is perfect, but I have a 100% success rate with the engineers that have been hired using this model, and several years of data to back it up.
[1] It actually has a few subtle bugs in it that I'm always curious to see if they'll catch.
[2] The job in question requires working on a Python web app, and so I assume some basic Python knowledge.
I don't want to give away my secrets, because this has actually worked really well for me and I'm afraid that I'll lose my edge as an employer - however I have a very small neck of the woods and HN seems very US-centric so I think I'll be ok.
What has worked for me, honestly, is being directly involved with my hiring pipeline and having conversations.
It seems like common sense, but there's a lot of reasons not to do this and people will make good arguments to prevent it. "What about bias", "your time is more important" etc;
However, bias is an unfortunate consequence of selecting for value fit anyway and I can't think of a more important task than selecting the members that will be the future of the company.
I've had some positions that were open for a weekend where I got 400 applicants, and yes, it was daunting to go through and give each of them an honest shot, but you know: I had to do it. What's the alternative? I might miss a fantastic candidate because someone didn't understand what I actually need.
Evaluating programmers and "devops" people is just insanely hard, technologies are mostly fungible. If you can write one C-like language you can learn the others in about a month, but what can't be taught is what your values are, if you think in a systemic way, if you're easy to work with and respect others.
So, my solution is to have a conversation, challenge what they know, see how they react when challenged, see how they react when they reach the end of their knowledge and see what they're most proud of and if they get excited by it.
No gotchas, no esoteric internal handshake, just: are you defensive? Are you curious? Are you passionate? Can you communicate effectively and are you intelligent.
If you hit those, you can do anything.
"How do you even know who to interview?"
This is a hard question, for me there's not a lot of candidates that are physically located in my region, so those go through as long as they have something on the CV that looks relevant. For others it's a combination of: would it be easy for them to move, have they worked remote (and can do it in a region where I have a tax entity) and how strong of a fit to the role is the CV, lots of experience in games would be what I expect since I work in video games - but if you're going for a backend programming role then: what have you built and what do you list as your responsibility to achieve it?
With this mindset I managed to build a high performing, high trust team that executed very well on (literally) impossible demands. If the ownership of the company was better that team would have easily been world class.
We also exceeded dunbars second (clan) number with the size of the team, so it wasn't intrinsic to small teams (80+).
He mentioned that Oxide has an interview process that takes 20 hours realistically between coming up with work samples, answering 8 questions before hand and 9 hours of in person interviews.
I was curious about the pay.
https://www.glassdoor.com/Salary/Oxide-Computer-Salaries-E54...
For their “senior” engineers it’s in the range of offers for I’ve seen for new grads at most of the tech companies and around the range of generic enterprise CRUD developers.
No offense to “enterprise developers”. I spent 25 years as one. But why would I jump through hoops for a job that pays about the same as I could hypothetically get based on interviewing for a few hours and asking generic behavioral questions and maybe some techno trivia about whatever language the company uses.
I find it fascinating that companies want rockstar ninja developers but then offer meh compensation for the positions.
So (foolishly?) I had never bothered to check Glassdoor, because we have been so upfront about our compensation.[0] But apparently that was a mistake! If it needs to be said, the Glassdoor numbers are comically wrong -- and in fact the high number in the "Engineer" range was quite a bit less than what we payed everyone six years ago!
[0] https://oxide.computer/blog/oxides-compensation-model-how-is...
That’s fair.
First I’m going to make an argument and then immediately refute it before someone else makes the argument. That $235K is still lower than what mid level developers make at any of the BigTech companies.
Yes, that’s true. But they are all toxic hellholes where everyone is jockeying for position, making sure they show “impact” that looks good on promo docs and they all have RTO mandates even for positions that were formally “field by design”.
$235K and the ability to work remotely is something I would definitely think is fair (and a little more than I make now that I’m outside of Bigtech working remotely) as long as you give cost of living increases and is more than most developers will ever make inflation adjusted.
The other point you make is that performance is just a form of stack ranking and even hard work is usually just awarded with a 1-2% raise more than someone else gets. Why not separate it from comp?
I also like sales having variable compensation that is based on performance. I work somewhat as a post sales architect and I have an appreciation for the sales side more than most engineers.
Big tech companies have mostly figured out some kind of infinite money glitch. I don't think comparing compensation at them to startups makes a huge amount of sense. (It makes some sense from the perspective of how much money's coming into your bank account—just not a huge amount.)
Being a prominent face at a startup can also set you up for greater success in your career than being one of a hundred thousand at a bigco.
And as you touched on already, the environment at Oxide is a million times better than the toxicity and empire building that happens at bigcos.
Duplicate: https://news.ycombinator.com/item?id=44843256
Honestly, I'd say the best setup would be something like:
1. Live coding/code review/take home test 2. Technical discussion about said test/project (and the company's tech as a whole) 3. General team discussion/culture fit interview
That's because at the end of the day, you really want to filter out the folks that can't do the job as quickly as possible. If someone needs AI to code, can barely use a computer or writes poorly thought out, inefficient code straight out of the last century, it doesn't really matter how charismatic they are or how well they can discuss where they want to be in 5 years.
Way too many companies do things the other way around, and waste far too much time because of it.
Oh, and definitely make sure your questions are specific to the tech you use/field you work in. I still remember having a tough time using React at a certain company because the interview process didn't require any modern JavaScript/SPA knowledge and I'd managed to pass without ever having worked on that sort of web app before.
Similarly, I also remember seeing a WordPress dev agency using Google style leetcode interviews to filter out applicants. Made me wonder how many people they actually managed to hire that way, given that the pay being offered was pretty low, the work wasn't particularly appealing to the people who'd pass those interviews and the requirements to pass the interview in general didn't match up with the job at all.
> most interview questions have very little to do with day-to-day responsibilities. all good software engineers are generalist and live coding does not select for generalists
If I had a dollar for every time I heard this (flawed) argument, I’d be rich and would no longer have to sell ads on my Hacker News comments. I’m going to get hate for this unpopular opinion but here we go.
So often, “But Leetcode isn’t like REAL programming” is the siren song of the programmer who probably overestimates their coding skills and experience.
Yes, I hate to say it - live coding is actually one of the best signals you can get on a candidate’s seniority and ability to program a computer (and more importantly, their core computer science skills). A good interviewer is trained to know how to probe your CS knowledge during this, and will watch how you structure code, break down problems, debug, and think about testing. They will even ask you to make changes to see how coachable you are and what you might be like to work with. It’s not about inverting a binary tree while sharing your screen, it’s about showing me how you solve a problem, then translate what’s in your head to code.
Take home exercises provide little to no signal, and screen out people who have families (who wouldn’t bother with a 4 hour take home exercise after work). I don’t want to see how you Google, I want to see how you think.
These candidates always want some version of, “But trust me, bro! Hire me: I’m a senior engineer, I don’t remember how to Leetcode! I’m good, I promise!” But what they won’t admit to themselves is that a good senior engineer is able to do all the things a junior can do PLUS all the things a senior can do.
It’s not perfect, but I won’t hire anyone that can’t pass a live coding round.
This comment brought to you by Poppi. Poppi: it’s soda for people who are silly enough to believe soda can be healthy.
>Take home exercises provide little to no signal, and screen out people who have families (who wouldn’t bother with a 4 hour take home exercise after work). I don’t want to see how you Google, I want to see how you think.
I tend to think that's very possibly true of developers (especially if they haven't worked in open source) but I wouldn't generalize that some combination of pointing to samples of past work and/or a take home isn't valid for a late-stage interview/demo in general. Jobs that involve a lot of writing or presenting, for example, probably require some demonstration of ability whether pre-existing or created for the purpose.
I'd also say that one mistake along this line was taking one such sample and assuming that it was close enough and could be upleveled with a bit of work.
I helped my friend from university get a job by helping him do their take-home exercise. I didn't write the code for him but I walked him through pretty much every single step. I'm not proud of that but my friend needed a job and I was in a position to help him get it. My principles are not nearly as important as that job was to him.
If you let people cheat they will cheat.
Yes, people can cheat. In my example, you can mitigate by having them also do a live presentation and ask probing questions about what they've written if that's part of the job.
The coding equivalent would be asking them why they took some specific approach or used a particular algorithm. I'm not sure about my feelings with respect to coding takehomes but there are circumstances where someone doesn't have an openly viewable body of work where takehomes can make sense.
There's a difference between live coding round and leetcode rounds where you need to perfectly write code for as medium or hard leetcode question in 20 minutes.
1) that’s not what most companies do
2) if you have thousands of applicants for a position, and probably a dozen stand out by passing a really tough bar, wouldn’t you want to find those dozen?
> 2) if you have thousands of applicants for a position, and probably a dozen stand out by passing a really tough bar, wouldn’t you want to find those dozen?
It's a reasonable assumption, but you might not. If the role doesn't actually require those skills you might hire someone who's going to get fed up and leave in 3 months or (worse) who invests time in making their job more interesting instead of solving your actual business problems.
Good points. Most FAANG/MANGO companies in India do leetcode. And I know Amazon still does leetcode in US/Europe.
So, yeah, you are right. Live coding is very good, which is what I do, but too many people confuse live coding with just leet coding.
The question is, however, whether this is a good proxy for one's future colleague and employee.
I have no idea what could be a better option (well, maybe preparing some small feature to work on together), but it often turns out that good problem solvers are not really great at doing the job, for reasons that have nothing to do with the hard skills.
Totally valid critique.
Hiring is really hard. You only get a few hours to decide whether someone will be a good engineer and colleague for several years.
By the nature of the constraints alone, anything you do will be extrapolation, and a guesstimate at best.
> It’s not perfect, but I won’t hire anyone that can’t pass a live coding round
I'd like to add two points to this:
First, I like that you said "live coding" rather than leet code. The floor for live coding should be super low, with a high ceiling and lots of flexibility. That allows you to say, nope, they didn't pass the floor level, easy binary decision, no hire. Pick a fun toy to build in 90 minutes and the high ceiling + flexibility will yield tons of signal from applicants.
Second, I see live coding sessions like this as a positive sign from potential employers. It lets me know that my future colleagues will have some baseline level of competence. If you've worked on a team that didn't do live coding, and you've had to carry water for someone who can't actually do the day-to-day technical "hard skill" work of software engineering, you probably feel the same way. Never again.
> I won’t hire anyone that can’t pass a live coding round.
Excellent - please be sure to mention this in the job description so I can know to never apply to where you work.
Don’t worry: it doesn’t sound like that will be something you’ll have to be concerned with.
This idea that “I’m special - I’m too good for a live coding round” is definitely not an attitude I want on my team. It’s highly entitled.
> This idea that “I’m special - I’m too good for a live coding round” is definitely not an attitude I want on my team. It’s highly entitled.
The irony.
[flagged]