[HN Gopher] An engineer's perspective on hiring
___________________________________________________________________
An engineer's perspective on hiring
Author : pabs3
Score : 39 points
Date : 2025-08-09 09:49 UTC (13 hours ago)
(HTM) web link (jyn.dev)
(TXT) w3m dump (jyn.dev)
| 0x264 wrote:
| 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 wrote:
| > 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 wrote:
| > 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 wrote:
| 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.
| erehweb wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| I meet a few college CS candidates, and I really empathize
| with what they're facing now.
|
| I feel like the industry is far tougher to get into now
| than when I joined.
|
| I sent out maybe 10 applications, got a few interviews, and
| 1 offer.
|
| I hear of kids now sending out dozens to hundreds of
| applications with few bites.
|
| Makes me sad for the stress they must feel.
| ghaff wrote:
| Historically, I'm not sure that isn't fairly normal.
|
| But compared to maybe the decade plus prior to a couple
| years ago for (especially junior) software developers, it
| seems like a tough market based on a lot of conversations
| irrespective of overall unemployment rates.
| _rutinerad wrote:
| Last time I was looking, a year or so ago, I sent out
| dozens of applications and got zero interviews. Last time
| I switched jobs, in 2022, I sent out the same amount of
| applications and >50% led to one or more interviews (and
| eventually two offers).
| bryanrasmussen wrote:
| >The OP thinks that candidates spending a lot of time on
| applications is OK, as long as the company shows respect by
| spending a lot of time themselves
|
| if I spend 6 hours and the company has 1000 employees does that
| mean they spend 6000 hours? If so I might consider it a
| reasonable line of argument, but I guess they don't spend
| anywhere near that.
| Esophagus4 wrote:
| > 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.
| megatron2009 wrote:
| 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 wrote:
| 1) that's not what most companies do
|
| 2) if you have thousands of applicants for a position, and
| probably a dozen stand out by passing a really tough bar,
| wouldn't you want to find those dozen?
| dondraper36 wrote:
| The question is, however, whether this is a good proxy for
| one's future colleague and employee.
|
| I have no idea what could be a better option (well, maybe
| preparing some small feature to work on together), but it
| often turns out that good problem solvers are not really
| great at doing the job, for reasons that have nothing to do
| with the hard skills.
| Esophagus4 wrote:
| Totally valid critique.
|
| Hiring is really hard. You only get a few hours to decide
| whether someone will be a good engineer and colleague for
| several years.
|
| By the nature of the constraints alone, anything you do
| will be extrapolation, and a guesstimate at best.
| dcminter wrote:
| > 2) if you have thousands of applicants for a position,
| and probably a dozen stand out by passing a really tough
| bar, wouldn't you want to find those dozen?
|
| It's a reasonable assumption, but you might not. If the
| role doesn't actually require those skills you might hire
| someone who's going to get fed up and leave in 3 months or
| (worse) who invests time in making their job more
| interesting instead of solving your actual business
| problems.
| megatron2009 wrote:
| Good points. Most FAANG/MANGO companies in India do
| leetcode. And I know Amazon still does leetcode in
| US/Europe.
|
| So, yeah, you are right. Live coding is very good, which is
| what I do, but too many people confuse live coding with
| just leet coding.
| 0x20cowboy wrote:
| > I won't hire anyone that can't pass a live coding round.
|
| Excellent - please be sure to mention this in the job
| description so I can know to never apply to where you work.
| Esophagus4 wrote:
| Don't worry: it doesn't sound like that will be something
| you'll have to be concerned with.
|
| This idea that "I'm special - I'm too good for a live coding
| round" is definitely not an attitude I want on my team. It's
| highly entitled.
| sys_64738 wrote:
| > This idea that "I'm special - I'm too good for a live
| coding round" is definitely not an attitude I want on my
| team. It's highly entitled.
|
| The irony.
| ghaff wrote:
| >Take home exercises provide little to no signal, and screen
| out people who have families (who wouldn't bother with a 4 hour
| take home exercise after work). I don't want to see how you
| Google, I want to see how you think.
|
| I tend to think that's very possibly true of developers
| (especially if they haven't worked in open source) but I
| wouldn't generalize that some combination of pointing to
| samples of past work and/or a take home isn't valid for a late-
| stage interview/demo in general. Jobs that involve a lot of
| writing or presenting, for example, probably require some
| demonstration of ability whether pre-existing or created for
| the purpose.
|
| I'd also say that one mistake along this line was taking one
| such sample and assuming that it was close enough and could be
| upleveled with a bit of work.
| sfn42 wrote:
| I helped my friend from university get a job by helping him
| do their take-home exercise. I didn't write the code for him
| but I walked him through pretty much every single step. I'm
| not proud of that but my friend needed a job and I was in a
| position to help him get it. My principles are not nearly as
| important as that job was to him.
|
| If you let people cheat they will cheat.
| ghaff wrote:
| Yes, people can cheat. In my example, you can mitigate by
| having them also do a live presentation and ask probing
| questions about what they've written if that's part of the
| job.
|
| The coding equivalent would be asking them why they took
| some specific approach or used a particular algorithm. I'm
| not sure about my feelings with respect to coding takehomes
| but there are circumstances where someone doesn't have an
| openly viewable body of work where takehomes can make
| sense.
| strix_varius wrote:
| > It's not perfect, but I won't hire anyone that can't pass a
| live coding round
|
| I'd like to add two points to this:
|
| First, I like that you said "live coding" rather than leet
| code. The floor for live coding should be super low, with a
| high ceiling and lots of flexibility. That allows you to say,
| nope, they didn't pass the floor level, easy binary decision,
| no hire. Pick a fun toy to build in 90 minutes and the high
| ceiling + flexibility will yield tons of signal from
| applicants.
|
| Second, I see live coding sessions like this as a positive sign
| from potential employers. It lets me know that my future
| colleagues will have some baseline level of competence. If
| you've worked on a team that didn't do live coding, and you've
| had to carry water for someone who can't actually do the day-
| to-day technical "hard skill" work of software engineering, you
| probably feel the same way. Never again.
| austin-cheney wrote:
| 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 wrote:
| 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 wrote:
| > Next are the people who actually write software applications.
| Let's call these people solution delivery. These people are
| similar to junior architects and actually build things. These
| people should be evaluated only on the basis of organizational
| capabilities above that of the engineers that measure things.
|
| Why? People who actually write original software require many
| other skills in order to do so (just not, you know, marketing).
| austin-cheney wrote:
| Writing software is no different than writing a novel or a
| music album. Its creating a product. All of these require the
| ability to write, but its more than just writing an essay.
| There are functional aspects that require different stages of
| planning and composition that must be put together in a way
| that can be maintained, described, and decomposed. Its that
| vision for composition and extension which requires
| organizational capacity drawn from lots of experience.
| dijit wrote:
| 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 wrote:
| Duplicate: https://news.ycombinator.com/item?id=44843256
| shahbaby wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| > 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 wrote:
| to pretend that they care about safety
| qudat wrote:
| When you are rapidly hiring, giving a candidate 2 weeks to
| complete a take home is a huge drag on the process. Instead,
| sandwiching 3 interviews (resume walk, leetcode, system
| design) into a 3 hour time period lets candidates move
| through the process faster.
| ghaff wrote:
| I can't speak to developer roles specifically. But the last
| job I had (for a long time), I just dropped an email to
| someone who was a client. I think a fair number of the
| developers at the company came through internships or
| referrals and AFAIK takehomes weren't a thing.
| Henchman21 wrote:
| What year?
| ghaff wrote:
| 2010.
|
| It didn't hurt that the person in question ran the
| products group. (And I went to the same school as the
| ultimate hiring manager.)
|
| People obviously have different experiences at different
| companies but networks matter a lot in many cases whether
| a lot of folks like it or not.
|
| Things still took a few months to coordinate meetings and
| interviews but it was still the only job I (sort of)
| applied for.
| apwell23 wrote:
| Agree. leetcode is the greatest thing that happened to tech
| interviews.
|
| Get good at it and you can do hundreds of interviews with no
| prep.
|
| Take homes are a proxy for hiring most desperate ppl who can
| spend most time on it.
| donatj wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| Been working professionally since '97, still haven't ever
| gotten a payment for moving expenses.
| octo888 wrote:
| > They'll say they will help. Even have you fill out a
| form.
|
| Have they not formed a verbal contract in saying they'll
| help with relocation expenses?
| ghaff wrote:
| It's been a long while but, especially as a young
| employee (presumably) expecting to have relocation
| handled, I'd be WTF; the relocation would probably have
| been a huge chunk of my salary at the time. Of course, at
| that point, you're probably just screwed and you're
| probably not going to get a lawyer over it.
| mathiaspoint wrote:
| The way it's worked for me is I've been given a small
| relocation bonus and then I'm responsible for figuring the
| details out.
| reactordev wrote:
| So _assistance_ really just means punt
| ghaff wrote:
| Having to relocate a long distance would have been a huge
| barrier for me both for cost and other reasons at the
| time. Obviously remote is a bigger option these days but
| far from universal. Glad it wasn't a problem both times I
| did even if the cost and other obstacles weren't as great
| at the time.
| mathiaspoint wrote:
| Would you really want anything else? I can't really
| imagine how you're expecting that to work.
| ghaff wrote:
| In my experience the employer (2x) took care of
| arrangements for both the moving and the temporary hotel
| arrangements.
| roland35 wrote:
| 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.
| paulcole wrote:
| > 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 wrote:
| 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 wrote:
| I'm sorry. I don't understand what your comment has to do
| with mine?
| reactordev wrote:
| 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 wrote:
| 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 wrote:
| The expression is
| https://en.wikipedia.org/wiki/Lord_of_the_manor .
| pxeger1 wrote:
| > 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.)
| ozgung wrote:
| 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 wrote:
| Sounds like you're arguing for a professional licensing regime
| to exist
| ghaff wrote:
| In software at least, professional licensing exams basically
| petered out because no one required them so no one cared.
| billy99k wrote:
| My guess is that it would impede outsourcing and end up
| costing companies too much money.
| ghaff wrote:
| In general, licensing is for regulatory reasons (e.g.
| signing off on drawings). Engineers don't generally do it
| unless there is some industry requirement to do so
| (especially in civil engineering). And there mostly isn't
| in software.
|
| I started the engineer-in-training track when I was in
| the offshore drilling industry but then I left and never
| went back.
| master_crab wrote:
| The only issue is that Software Engineering (is that the term
| we use?) does have more churn and change than other types that
| have PEs like Civil.
|
| Not saying it's not possible to focus on fundamentals that have
| only changed superficially in decades (like the networking
| stack or data structures), but it is more difficult in this
| field.
| vedmakk wrote:
| 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 wrote:
| 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 wrote:
| 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.
| billy99k wrote:
| 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.
| wewewedxfgdf wrote:
| My philosophy on interview - most companies are not systematic in
| the way they do it - it's kinda random and everyone brings in
| their uneducated flavor to the process which th3ey really
| genuinely think gives special analysis and insight into the
| candidate (though usually they are wrong about this).
|
| So, start the process and you might get some good interview steps
| and when you get to the fools who are getting it wrong and
| wasting your time, just bail out immediately.
___________________________________________________________________
(page generated 2025-08-09 23:00 UTC)