An engineer's perspective on hiring

https://jyn.dev/an-engineers-perspective-on-hiring

by pabs3 • 12 months ago

191 238 12 months ago

0x264• 12 months ago

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.

lsdforme• 12 months ago

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.

zahlman3• 12 months ago

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.

nouveaux2• 12 months ago

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.

A4ET8a8uTh0_v2• 12 months ago

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.

bsoles• 12 months ago

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.

ThrowawayR2• 12 months ago

"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?

tukantje2• 12 months ago

At the very least understanding of the specific domain comes to mind.

scarface_749• 12 months ago

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.

erehweb• 12 months ago

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.

Esophagus47• 12 months ago

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.

ghaff14• 12 months ago

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.

bryanrasmussen3• 12 months ago

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.

jaggederest2• 12 months ago

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.

Esophagus47• 12 months ago

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.

megatron20092• 12 months ago

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.

Esophagus47• 12 months ago

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?

0x20cowboy2• 12 months ago

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.

Esophagus47• 12 months ago

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.

ghaff14• 12 months ago

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.

sfn42• 12 months ago

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.

strix_varius• 12 months ago

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.

Esophagus47• 11 months ago

Absolutely agreed.

I start with a simple problem with several answers of varying difficulty and literally instruct the candidates to code the first correct solution they can think of.

Nested for loops, brute force, it’s absolutely fine.

I just want to see you translate what’s in your head to code. I want to see you structure code, use data structures, etc. Then we will talk through optimizations, refactoring, testing, edge cases, etc later.

You want even the under qualified candidates to feel like they got some pieces right and had a fair shot.

As you start probing deeper, the top candidates stand out. They answer your questions about the differences between data structures, how you would test this piece, how you would monitor that piece in production, how you could parallelize it, etc.

austin-cheney2• 12 months ago

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.

j1elo• 12 months ago

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.

zahlman3• 12 months ago

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).

austin-cheney2• 12 months ago

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.

dijit• 12 months ago

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+).

zdw• 12 months ago

Duplicate: https://news.ycombinator.com/item?id=44843256

shahbaby2• 12 months ago

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.

bryanrasmussen3• 12 months ago

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?

apwell234• 12 months ago

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.

qudat• 12 months ago

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.

ghaff14• 12 months ago

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.

apwell234• 12 months ago

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.

bombela• 12 months ago

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.

FirmwareBurner2• 12 months ago

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

sethammons• 12 months ago

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.

ImageXav• 12 months ago

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.

shahbaby2• 12 months ago

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.

Fire-Dragon-DoL• 12 months ago

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?

sensanaty3• 12 months ago

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.

rpcorb• 12 months ago

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.

horns4lyfe2• 11 months ago

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

donatj• 12 months ago

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.

ghaff14• 12 months ago

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.

reactordev5• 12 months ago

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.

roland352• 12 months ago

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.

tayo423• 12 months ago

It's hard to get better when you don't get feedback

charcircuit• 12 months ago

Self reflection amend critique are skills too.

jaggederest2• 12 months ago

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!

bootsmann2• 12 months ago

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.

roland352• 12 months ago

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.

lkjdsklf• 12 months ago

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.

IshKebab2• 12 months ago

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.

mixmastamyk4• 12 months ago

I’ve only been able to book two “phoned-in” (literally and figuratively) interviews in the past year. Not enough to get comfortable.

paulcole2• 12 months ago

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?

reactordev5• 12 months ago

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.

paulcole2• 12 months ago

I’m sorry. I don’t understand what your comment has to do with mine?

globalnode2• 12 months ago

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.

zahlman3• 12 months ago

The expression is https://en.wikipedia.org/wiki/Lord_of_the_manor .

globalnode2• 12 months ago

Thanks, always helps the message when you grammar right.

pxeger1• 12 months ago

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.)

simpaticoder• 12 months ago

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.

zanderwohl2• 12 months ago

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.

nine_k• 12 months ago

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.

godelski10• 12 months ago

  > 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).

horns4lyfe2• 11 months ago

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.

ozgung• 12 months ago

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.

Henchman212• 12 months ago

Sounds like you’re arguing for a professional licensing regime to exist

ghaff14• 12 months ago

In software at least, professional licensing exams basically petered out because no one required them so no one cared.

thrown-08253• 12 months ago

There should be. Engineers are liable for their failure.

master_crab• 12 months ago

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.

zanderwohl2• 12 months ago

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.

musicale4• 12 months ago

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.

IshKebab2• 12 months ago

It's not like all engineers are certified. And people have tried to create certifications for programming, they just suck.

thrown-08253• 12 months ago

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.

musicale4• 12 months ago

devs are doing work that more closely resembles pipe fitting or carpentry

Yet plumbers and carpenters (and electricians) are all licensed.

testing22321• 12 months ago

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.

mixmastamyk4• 12 months ago

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.

zx8080• 12 months ago

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!

vedmakk• 12 months ago

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.

ghaff14• 12 months ago

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.

tomquirk• 12 months ago

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.

rglynn• 11 months ago

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.

billy99k2• 12 months ago

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.

jbmsf• 12 months ago

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.

liampulles• 12 months ago

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.

joshuamoyers• 12 months ago

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.

jamboca• 12 months ago

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?

derivagral• 12 months ago

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.

0x20cowboy2• 12 months ago

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.

reilly3000• 12 months ago

AI!

Izkata• 12 months ago

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.

flappyeagle• 12 months ago

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

svschannak• 12 months ago

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.

jimbob452• 12 months ago

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.

john01dav2• 12 months ago

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.

CodeVisio3• 12 months ago

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...

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?

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.

moi23882• 12 months ago

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

agent3272• 12 months ago

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.

azangru• 12 months ago

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?

scarface_749• 12 months ago

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.

godelski10• 12 months ago

  > At home coding challenge

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.

sensanaty3• 12 months ago

(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.

drdrek• 12 months ago

Have you ever integrated code a candidate wrote into a code base? Have you ever met anyone that have?

Ask yourself why not

jama211• 12 months ago

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.

musicale4• 12 months ago

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.

pavel_lishin2• 12 months ago

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.

eunos• 12 months ago

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.

shortrounddev2• 12 months ago

Francis Fukuyama calls this system (everyone gets a veto) a vetocracy, and it basically means that nothing ever gets done

mstratman• 11 months ago

What worked best in my experience is having a roundtable discussion between all the interviewers about their experience, and any concerns or objections they have. i.e. soft veto.

The hiring manager had the ultimate say, though. But he/she had to acknowledge, address, and own any objection and take personal responsibility for it if the candidate was hired.

When you have a good team who is earnestly focused on preserving a good team, it works really well. Red flag objections were pretty much never ignored, and were effectively vetoes. Minor objections or slight concerns about experience or aptitude, if they were overridden, prompted hiring managers to take extra time and care to help ensure the new hire's success.

tuna74• 12 months ago

How do you select the people who get to talk to your CTO?

belter• 12 months ago

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?

lisbbb4• 12 months ago

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!

mcprwklzpq• 12 months ago

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.

whatever1• 12 months ago

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.

makeitdouble3• 12 months ago

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.

ludicrousdispla2• 12 months ago

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.

mixmastamyk4• 12 months ago

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.

ethan_smith• 12 months ago

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.

aaronbrethorst• 12 months ago

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.

gyulai• 12 months ago

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.

tropicalfruit• 12 months ago

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

godelski10• 12 months ago

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.

maccard7• 12 months ago

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).

Buttons8403• 12 months ago

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.

OJFord• 12 months ago

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.

godelski10• 12 months ago

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.

rstuart4133• 12 months ago

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.

xiande04• 12 months ago

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.

lisbbb4• 12 months ago

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?"

dent9• 12 months ago

It sounds like you should just use better programming languages that don't break constantly.

lordnacho• 12 months ago

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.

dustingetz• 12 months ago

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.

godelski10• 12 months ago

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.

scarface_749• 12 months ago

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.

moregrist• 12 months ago

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.

dilyevsky2• 12 months ago

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...

tshaddox2• 12 months ago

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.

dilyevsky2• 12 months ago

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

scarface_749• 12 months ago

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.

bcantrill• 12 months ago

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...

scarface_749• 12 months ago

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.

retrocog• 12 months ago

Well structured temp to perm arrangements are usually win-win?

notjoemama• 12 months ago

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)

jboggan• 12 months ago

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.

Shaddox• 12 months ago

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.

CM30• 12 months ago

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.

An engineer's perspective on hiring

Related Stories