13 ms·

An engineer's perspective on hiring

191 points by pabs3 1y ago

0x264 1y 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 1y 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.
  - zahlman 1y 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.
- nouveaux 1y 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 1y 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 1y 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 1y 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?
  - tukantje 1y ago
    At the very least understanding of the specific domain comes to mind.
- scarface_74 1y 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 1y 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.
- Esophagus4 1y 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.
  - ghaff 1y 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.
    - Esophagus4 1y ago
Esophagus4 1y 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.
- sys_64738 1y ago
  [flagged]
- megatron2009 1y 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.
  - Esophagus4 1y ago
austin-cheney 1y 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 1y 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.
- zahlman 1y 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).
dijit 1y 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 1y ago
Duplicate: https://news.ycombinator.com/item?id=44843256 https://news.ycombinator.com/item?id=44843256
shahbaby 1y 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.
- bryanrasmussen 1y 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?
  - apwell23 1y 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.
    - filesfiles 1y ago
      > 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?
      - apwell23 1y ago
        to pretend that they care about safety
      - strken 1y ago
        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.
donatj 1y 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.
- ghaff 1y 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.
  - reactordev 1y 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.
    - ghaff 1y ago
      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.
      - reactordev 1y ago
        Been working professionally since ‘97, still haven’t ever gotten a payment for moving expenses.
    - octo888 1y ago
roland35 1y 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.
- tayo42 1y ago
  It's hard to get better when you don't get feedback
  - charcircuit 1y ago
    Self reflection amend critique are skills too.
  - jaggederest 1y 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!
  - bootsmann 1y 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.
  - roland35 1y ago
paulcole 1y 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?
- reactordev 1y 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.
  - paulcole 1y ago
    I’m sorry. I don’t understand what your comment has to do with mine?
    - reactordev 1y ago
      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.
globalnode 1y 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.
- zahlman 1y ago
  The expression is https://en.wikipedia.org/wiki/Lord_of_the_manor https://en.wikipedia.org/wiki/Lord_of_the_manor .
  - globalnode 1y ago
    Thanks, always helps the message when you grammar right.
pxeger1 1y 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 1y 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.
- zanderwohl 1y 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 1y ago
ozgung 1y 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.
- Henchman21 1y ago
  Sounds like you’re arguing for a professional licensing regime to exist
  - ghaff 1y ago
    In software at least, professional licensing exams basically petered out because no one required them so no one cared.
    - billy99k 1y ago
      My guess is that it would impede outsourcing and end up costing companies too much money.
vedmakk 1y 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.
- ghaff 1y 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 1y 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 1y 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.
billy99k 1y 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.
deleted 1y ago
[deleted]
jbmsf 1y 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 1y 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 1y 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 1y 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 1y 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.
0x20cowboy 1y 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 1y ago
  AI!
- Izkata 1y 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 1y 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 1y 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.
- jimbob45 1y 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.
  - john01dav 1y 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.
    - jimbob45 1y ago
      Everyone says that until they start sitting in on interviews and someone is wearing a confederate flag shirt or their areola is clearly showing.
whatever1 1y 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.
- makeitdouble 1y 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.
  - ludicrousdispla 1y 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.
    - makeitdouble 1y ago
      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.
      - 1y ago
aaronbrethorst 1y 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 1y 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.
5350-uiop-1130 1y 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
godelski 1y 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.
- maccard 1y 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).
  - dent9 1y ago
    It sounds like you should just use better programming languages that don't break constantly.
  - Buttons840 1y 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.
scarface_74 1y 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-E5426377.htm 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 1y 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-it-going https://oxide.computer/blog/oxides-compensation-model-how-is...
  - scarface_74 1y 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 1y ago
Well structured temp to perm arrangements are usually win-win?
notjoemama 1y 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 1y 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 1y 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 1y 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.

191 points by pabs3 1y 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 1y 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.
- zahlman 1y 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.
nouveaux 1y 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 1y 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 1y 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 1y 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?
- tukantje 1y ago
  At the very least understanding of the specific domain comes to mind.
scarface_74 1y 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 1y 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.

Esophagus4 1y 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.
- ghaff 1y 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.
  - Esophagus4 1y ago

Esophagus4 1y 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.

sys_64738 1y ago
[flagged]
megatron2009 1y 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.
- Esophagus4 1y ago

austin-cheney 1y 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 1y 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.
zahlman 1y 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).

dijit 1y 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 1y ago

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

shahbaby 1y 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.

bryanrasmussen 1y 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?
- apwell23 1y 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.
  - filesfiles 1y ago
    > 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?
    - apwell23 1y ago
      to pretend that they care about safety
    - strken 1y ago
      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.

donatj 1y 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.

ghaff 1y 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.
- reactordev 1y 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.
  - ghaff 1y ago
    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.
    - reactordev 1y ago
      Been working professionally since ‘97, still haven’t ever gotten a payment for moving expenses.
  - octo888 1y ago

roland35 1y 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.

tayo42 1y ago
It's hard to get better when you don't get feedback
- charcircuit 1y ago
  Self reflection amend critique are skills too.
- jaggederest 1y 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!
- bootsmann 1y 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.
- roland35 1y ago

paulcole 1y 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?

reactordev 1y 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.
- paulcole 1y ago
  I’m sorry. I don’t understand what your comment has to do with mine?
  - reactordev 1y ago
    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.

globalnode 1y 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.

zahlman 1y ago
The expression is https://en.wikipedia.org/wiki/Lord_of_the_manor https://en.wikipedia.org/wiki/Lord_of_the_manor .
- globalnode 1y ago
  Thanks, always helps the message when you grammar right.

pxeger1 1y 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 1y 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.
zanderwohl 1y 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 1y ago

ozgung 1y 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.

Henchman21 1y ago
Sounds like you’re arguing for a professional licensing regime to exist
- ghaff 1y ago
  In software at least, professional licensing exams basically petered out because no one required them so no one cared.
  - billy99k 1y ago
    My guess is that it would impede outsourcing and end up costing companies too much money.

vedmakk 1y 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.

ghaff 1y 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 1y 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 1y 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.

billy99k 1y 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.

deleted 1y ago

[deleted]

jbmsf 1y 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 1y 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 1y 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 1y 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 1y 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.

0x20cowboy 1y 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 1y ago
AI!
Izkata 1y 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 1y 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 1y 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.

jimbob45 1y 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.
- john01dav 1y 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.
  - jimbob45 1y ago
    Everyone says that until they start sitting in on interviews and someone is wearing a confederate flag shirt or their areola is clearly showing.

whatever1 1y 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.

makeitdouble 1y 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.
- ludicrousdispla 1y 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.
  - makeitdouble 1y ago
    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.
    - 1y ago

aaronbrethorst 1y 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 1y 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.

5350-uiop-1130 1y 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

godelski 1y 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.

maccard 1y 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).
- dent9 1y ago
  It sounds like you should just use better programming languages that don't break constantly.
- Buttons840 1y 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.

scarface_74 1y 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-E5426377.htm 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 1y 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-it-going https://oxide.computer/blog/oxides-compensation-model-how-is...
- scarface_74 1y 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 1y ago

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

notjoemama 1y 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 1y 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 1y 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 1y 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.