[HN Gopher] An engineer's perspective on hiring
___________________________________________________________________
An engineer's perspective on hiring
Author : pabs3
Score : 156 points
Date : 2025-08-09 09:49 UTC (1 days 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.
| A4ET8a8uTh0_v2 wrote:
| 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 wrote:
| 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 wrote:
| > " _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 wrote:
| At the very least understanding of the specific domain comes
| to mind.
| scarface_74 wrote:
| 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 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).
| scarface_74 wrote:
| "Okay boomer" (said sarcastically - I'm 51).
|
| In 2023, I was Amazoned after 3.5 years and found myself
| looking for a job. Even worse, by then I had moved to an
| area that was tourist heavy, but not really tech heavy
| and was looking for remote only jobs. The remote role at
| AWS just kind of fell into my lap.
|
| Plan A: Leveraging my network. This led to two offers
| both architect level positions - one over the
| architecture and migration to AWS at f500 company and the
| other over the architecture of PE owned company that was
| doing rollup acquisitions (been there done that).
|
| Plan B: targeted outreach to companies looking for
| expertise in a niche of AWS where at the time, I was one
| of the industry experts and was a major contributor to a
| popular official "AWS Solution" in its niche.
|
| This led to two interviews and one offer.
|
| I basically had three offers and a side contract within
| ten days of looking.
|
| I'm not bragging, I'm old. I should have a network to
| lean on and a reputation. The point is that even with my
| experience, if that well above had run dry, I might have
| been screwed.
|
| I also applied for hundreds of jobs during those two
| weeks while going through the interview process with my
| first hits. I heard crickets and for every job I applied
| to, it had hundreds of applications and my application
| wasn't even viewed by most and my resume was only
| downloaded once (LinkedIn Easy Apply shows both).
|
| I was not some old guy (well I am) with outdated skills.
| At the time I had over ten years of software development
| experience (on my resume) and 7 years of AWS experience
| including 3.5 working at AWS (ProServe) leading
| relatively complex projects.
| 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.
| jaggederest wrote:
| I think it's reasonable to make a donation on behalf or provide
| an honorarium if someone makes it far enough into the process.
| Something like a $250 gift card or equivalent.
|
| Not enough to make it worth farming interviews for
| compensation, but enough to show that the company appreciates
| that you spent 2-4 hours working on their take home.
| 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
| strken wrote:
| 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.
| layoric wrote:
| In Australia, AWS dev position in 2021 had a take home.
| Microsoft contract position before that didn't but they
| were desperate to fill seats on a poorly executed gov
| contract.
| zdragnar wrote:
| GitHub (pre-microsoft at least) and Crowdstrike both did.
| Amazon didn't have a take home so much as a "prove you can
| write code with this simple problem" though that was also
| pre-AI days as well.
| 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.
| bryanrasmussen wrote:
| hmm most of the take homes I ever got had a 1 week to
| complete but I guess I see it, I don't think I've ever been
| trying to get on a company that is hiring more than a small
| time at any time.
| 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.
| bombela wrote:
| With all those leetcode acers, why is software slow as
| molasses? You would think they pattern match for the most
| efficient algo with all this training.
|
| In my experience the more impressive somebody is at leet
| code, the worse their production code. Full of bugs, no error
| handling. Assuming the inputs never stray from the happy
| path.
|
| Not saying it's always the case of course. But I did
| interview almost 400 people over my career.
|
| On the other hand, most people cannot code to save their
| life. So I have no answers. Only more questions.
| boredatoms wrote:
| Leetcode is all local cpu. Production code is all waiting
| for network responses.
| bootsmann wrote:
| > In my experience the more impressive somebody is at leet
| code, the worse their production code.
|
| Used to think this too, until I met some truly impressively
| bad engineers where I'm pretty sure they would not have
| passed a leetcode screen either. People acing leetcode is
| at the minimum a good signal for people having the patience
| to sit down and learn non-trivial things over a somewhat
| longer time period by themselves.
| FirmwareBurner wrote:
| _> Get good at it_
|
| _> with no prep._
|
| You contradicted yourself in the same sentence. You can't get
| good at leetcoding interviews with no prep
| CITIZENDOT wrote:
| After getting good at it, there is no "additional" prep
| time, unlike take homes, where you would need to spend
| hours for every individual assignment. Is that so hard to
| understand?
| FirmwareBurner wrote:
| _> After getting good at it_
|
| Do you know the "use it or loose it" phrase? How long do
| you stay good at leetocde to not require anymore prep
| whenever you interview again?
|
| For some people, doing an AI assisted take home might
| take less time than having to restudy and re-exercise
| leetcode for months which they won't use again. Plus a
| lot of people suck at live coding when put on the spot
| due to anxiety, which means even more time investment for
| something not related to work.
|
| _> Is that so hard to understand?_
|
| I understood just fine, I'm calling it out as being
| incorrect for a lot of people.
| sethammons wrote:
| Interviews need to give signal to the employer. Having a
| couple decades experience now, working high scale, highly
| available services, and having designed interviews for
| thousands of candidates and given hundreds of interviews
| across half a dozen software engineering orgs, leetcode is
| poor signal.
|
| Good signals comes from questions that uncover attributes
| that will grow your team snd fill deficits.
|
| The best method yet for a technical interview is a work
| sample test based on recent work actually performed by the
| team. I've never encountered a leetcode problem in the wild.
| Data structures and algorithms, of course. Leetcode? Nope.
|
| But leetcode is easy to administer and someone else already
| wrote the question. The big companies don't even try to
| differentiate between those who clearly have practiced the
| given leetcode problem type vs someone who derives a solution
| by working the problem.
| apwell23 wrote:
| yes agreed leetcode as interview technqiue sucks but its
| great for interviewers. i am just a powerless cog playing
| the game trying to provide for my family.
| ImageXav wrote:
| I've had the complete opposite experience, and feel the
| complete opposite way. What is there to learn from failing a
| leetcode? It feels like luck of the draw - I didn't study that
| specific problem type and so failed. Also, there is an up front
| cost of several months to cover and study a wide array of
| leetcode problems.
|
| With a take home I can demonstrate how I would perform at work.
| I can sit on it, think things over in my head, come up with an
| attack plan and execute it. I can demonstrate how I think about
| problems and my own value more clearly. Using a take home as a
| test is indicative to me that a company cares a bit more about
| its hiring pipeline and is being careful not to put candidates
| under arbitrary pressures.
| Fire-Dragon-DoL wrote:
| I love take home and don't like leetcode, so I was thinking:
| choose a company based on how they interview, might help with
| culture fit?
| sensanaty wrote:
| I feel the complete and total opposite. With leetcode-esque
| ones it's just a luck of the draw that you can conjure up the
| memory for whatever it is they're asking you to do. The
| _decent_ ones are the ones that at least are somewhat
| realistic, but the truly terrible ones are those where you have
| to remember how to do an algo of some sort but you have no
| access to outside tools of any kind. I 've never come out of a
| leetcode and felt like I learned anything or could've done
| something better, not to mention the artificially crafted high
| stress environment. I feel like they also literally _never_
| reflect anything even approaching the actual work, either, and
| basically test your memory more than anything else. There 's a
| reason there's a billion books out there about how to "crack"
| the leetcode style interviews.
|
| On the other hand, with takehomes I get to approach a project
| as if it were my own little hobby thing. I get to approach it
| in ways that are comfortable for me to work, with my music on,
| in my own editor, on my own setup, with no time pressure (or at
| least very light time pressure, just like during the actual
| job). I always use it as an opportunity to try out something
| new as well, so I'm also learning in the process even if I
| don't get the job. And in my experience even when rejected,
| I've _always_ gotten detailed feedback for areas of
| improvement, which has _never_ happened in leetcode interviews
| for me.
| rpcorb wrote:
| What if it's an appropriately scoped take-home assignment? 1-2
| hours max. I would say that's fair and gives people with
| interview anxiety more of a chance.
| 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.
| mathiaspoint wrote:
| The one time I had an employer involved that closely they
| completely dropped the ball and I had to crash on a
| friend's couch. Again I don't think having corporate
| administration so closely involved in your life is a
| great idea just because of the dumb things they
| occasionally do.
| 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.
| tayo42 wrote:
| It's hard to get better when you don't get feedback
| charcircuit wrote:
| Self reflection amend critique are skills too.
| jaggederest wrote:
| 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 wrote:
| 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 wrote:
| Yeah companies generally won't provide feedback, there is no
| benefit to them and many times candidates will just argue
| about it anyways.
|
| For better feedback there are some good mock interview
| companies out there, or you can ask a friend or mentor. I've
| also had really good luck just talking to Gemini/Chat GPT.
| lkjdsklf wrote:
| I'm getting pretty old and have done a ton of interviews at
| this point in life.
|
| There's never been a single one that went poorly and I didn't
| know exactly why without a word of feedback from the company
| I was interviewing with.
| mixmastamyk wrote:
| I've only been able to book two "phoned-in" (literally and
| figuratively) interviews in the past year. Not enough to get
| comfortable.
| 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 .
| globalnode wrote:
| Thanks, always helps the message when you grammar right.
| 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.)
| simpaticoder wrote:
| _> 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 wrote:
| > 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 wrote:
| The problem with leetcode is time. If you know a good solution
| to a puzzle, or can instantly come up with it, you have the
| time to write it down, make it work, discuss, improve, etc. If
| you spend extra 10 minutes on a wrong approach, you're very
| strained, and if you spend 15 minutes, you're toast.
|
| _But knowing the good solution by heart is not the point!_ For
| that reason, when I ran code interviews, I often gave hints to
| the candidate, or sometimes just stated that a particular
| algorithm is a good solution, and it 's usually implemented
| using this and that. ("Use BFS. You'll need a queue.")
|
| This is where the demand for _realistic_ conditions kicks in:
| at work, you 're not going to invent an algorithm, you'll ask
| the machine what works in a situation like yours, consider, and
| choose. Doing otherwise would be imprudent.
| godelski wrote:
| > I admit the style of interviewing I'm describing has its own
| problems
|
| We need to be clear, _ALL_ styles of interviewing has problems.
| There 's no global optima for problems like this. It's
| important to say this because people will point out problems as
| reasons not to switch while ignoring the existing ones. The
| answer entirely depends on "what are you optimizing for?" Be
| precise
|
| Also worth pointing out, the style you describe is the
| traditional engineering interview. Leetcode type problems were
| initially done this way. It is also easy to make an effective
| system worse by trying to improve it. This often happens by
| trying to apply hard metrics to noisy problems. You don't
| improve your accuracy, you are just fitting a certain type of
| noise better (and encouraging Goodhart's Law).
| 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.
| thrown-0825 wrote:
| There should be. Engineers are liable for their failure.
| sensanaty wrote:
| And on the plus side that liability also provides people a
| lever with which they can push back against stupid
| managerial decisions. My father was an aeronautical
| engineer, and his favorite word to say to management was
| "No". Yes, the engine inspection takes a long time. No, I
| cannot cut corners in any way just to save you some money
| (No idea if this is just one of his stories or a real
| situation, but you get the idea :p ).
|
| I don't know why people are so against it in this field
| tukantje wrote:
| We have this idea that gatekeeping in all its forms is
| bad; and like all absolutes it is not true.
| agent327 wrote:
| > I don't know why people are so against it in this field
|
| Because the vast majority of failing software just means
| inconvenience, rather than disaster.
| 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.
| zanderwohl wrote:
| > In serious professions, people take exams early in their
| careers for being certified. Sometimes they take additional
| exams to renew their certificates. And that's all.
|
| The field of programming emerged from mathematics, not
| engineering unfortunately. So we lack any useful certification
| processes.
| musicale wrote:
| At many schools, CS departments emerged from Electrical
| Engineering departments. Some (MIT, Berkeley, ...) even have
| a combined EECS department, while others (Stanford) are part
| of the school of engineering.
|
| However, it does not seem to be common practice for computing
| professionals to acquire professional engineering
| certification. (Perhaps graduation from an accredited program
| is considered to be equivalent?)
|
| There do seem to be Professional Engineer (PE) certifications
| for computer engineering at least:
|
| https://ncees.org/exams/pe-exam/electrical-and-computer/
|
| https://ncees.org/wp-content/uploads/2025/01/FINAL_PE-
| Electr...
|
| There are also company-specific certifications (from
| Microsoft, Cisco, etc.) but those are less general.
| thrown-0825 wrote:
| Most devs are not engineers, and has not passed a licensing
| board or belong to any professional associations.
|
| Most devs are doing work that more closely resembles pipe
| fitting or carpentry than any engineering discipline.
| musicale wrote:
| > devs are doing work that more closely resembles pipe
| fitting or carpentry
|
| Yet plumbers and carpenters (and electricians) are all
| licensed.
| testing22321 wrote:
| I have a Bachelor of Software Engineering. The degree is
| fully accredited by, and I am a member of the Australian
| Institute of Engineers.
|
| We do exist, but as you said very rare. There were 12 of us
| in my graduating class in 2004.
| musicale wrote:
| This is an interesting point. Most US universities are
| accredited overall, but their individual engineering
| programs aren't always accredited by engineering
| accreditors.
|
| For example, UC Berkeley's EECS department lost its ABET
| accreditation in 2020 (which it had maintained since 1983.)
| Stanford University lost its ABET accreditation in
| Electrical Engineering in 2014 (which it had maintained
| since 1936.) In contrast, nearby Santa Clara University and
| San Jose State University both have ABET-accredited EE and
| CS programs. So, consider hiring some of their graduates!
|
| Many computing professionals are members of professional
| societies such as ACM or IEEE (and many are not since they
| don't see the value in the expensive dues.)
|
| What has also not been widely adopted, and has even been
| opposed, is standardized professional engineering
| certification (exams, licensing, continuing education
| requirements, etc.) for computing professions such as
| software development.
|
| I think this may be related to the computing industry's
| remarkable success in avoiding liability and associated
| regulation, particularly for software and online services.
| mixmastamyk wrote:
| Indeed, and ridiculous exams at that. Imagine being at school
| and they had a several question exam from _anything_ across a
| four year degree. No information on what area to focus on,
| because there's no focus on purpose.
|
| Quarter of a million dollars in a suitcase, loaded gun, and a
| copper ticking clock on the table next to you. Picture of your
| kids that need new school clothes.
|
| Miss one question and you fail. Must also be confident,
| friendly, and not too old while doing it.
|
| --> "I can't find anyone that can pass my simple test, they
| must all be frauds."
|
| This is not how proper exams work, and for good reason.
| 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.
| jbmsf wrote:
| 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 wrote:
| 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 wrote:
| > 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 wrote:
| 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 wrote:
| > 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 wrote:
| 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 wrote:
| AI!
| Izkata wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| Everyone says that until they start sitting in on
| interviews and someone is wearing a confederate flag shirt
| or their areola is clearly showing.
| john01dav wrote:
| Usually dressing professionally refers to standards that
| are quite different from that, so if one wants to say
| that they're checking for things like that it would be
| best to make that clear.
| CodeVisio wrote:
| 2. "...but in this case you have to show os some of your work
| from the past, so we can discuss this."
|
| That is not always possible. There is always an NDA in
| contracts. Imagine me going around and revealing the code I
| have done for your company...
|
| 3.
|
| Are you going to pay extra those two engineers of your company
| for doing something that is clearly outside what they were
| hired for at beginning or outside their competences?
|
| 4.
|
| The same as 3. Are you going to pay those employees for doing
| manager work instead? Or the managers of your company are paid
| for doing nothing while showing doing something and soon ready,
| as in your message, to download their responsibilities to
| simple engineers (company's leaves )?
|
| Edited.
| moi2388 wrote:
| 2. Then they do the take home challenge, or you hire another
| candidate. 3. No, normal wage and is expected of them. 4.
| That's not manager work. It's a tech talk, it needs to be
| with the tech people.
|
| It's really not that weird to have the team decide who they
| want to join their team
| CodeVisio wrote:
| 2. Then they do the take home challenge, or you hire
| another candidate.
|
| This is not kindergarden anymore. We're taling adult stuff
| here. If the manager is not able to interview, analyse and
| understand who is in front of him, then it is time to
| change job.
|
| Iff the candidates has personal work to show then it is
| considered a plus, but it is not madnatory.
|
| 3. No, normal wage and is expected of them.
|
| A hired person is supposed to fill a role and not a double
| or more roles just because the manager is not able to
| subdivides tasks, roles etc. I don't expect engineer or
| technical roles to do manager job.
|
| 4. That's not manager work. It's a tech talk, it needs to
| be with the tech people. It's really not that weird to have
| the team decide who they want to join their team
|
| It might work in your culture.
|
| in my culture, who is going to take a manager role
| _manages_ technical people _and_ as such he _must_ know the
| technical stuff to a certain degrees otherwise the job is
| not for him. Here managers don't download their
| responsibilities to engineers they manage.
|
| At the same time, engineers are not supposed to judge or
| like or dislike their coworkers. Working in a team is a
| prerequisite that they have to accept, either you like it
| or not. Full stop. There is no space for interpretation or
| for leisure. They have tasks and they finish their tasks.
| Full stop.
| agent327 wrote:
| Maybe that attitude works in a big company, but it won't fly
| in a smaller one. I'm a software engineer and I write plenty
| of code, but I also help out with interviews, packing, sales
| demos and proposals, customer support, general IT support,
| etc. Hell, I've fixed the coffee machine! I'd absolutely hate
| it if writing code was my only task.
| CodeVisio wrote:
| I understand you and did the same in the past.
|
| However, here we are talking about at the general level.
| Not a single instance as your experience.
|
| Engineers are hired for engineering jobs not for manager
| jobs or mopping the floor.
|
| On the other side, if a lately hired person wasn't find
| himself comfortable inside the team, I, _as manager_, can
| always complain the team and accuse them being guilty
| because they weren't able to say NO at interview level or
| because they said YES at the wrong candidate. Do you see
| the faulty thought of our time? I as manager earn a lot for
| managing people but in reality I download my
| responsibilities of not being able to interview a candidate
| and so find the right person _downloading_ that on the team
| that actually is not responsible for new hired person.
| Fantastic.
|
| Than's the meal they want you digest in some cultures. In
| mine, as manager, I decide who is on board, and I clarify
| clearly the roles of every one. No space for
| interpretation.
|
| I din't come out from a manager school, but I started from
| the ground and I put myself _every time_ in the shoes of
| who is managed by me.
|
| My humble opinion
| sly010 wrote:
| We get it. You are a manager.
| azangru wrote:
| > Are you going to pay extra those two engineers of your
| company for doing something that is clearly outside what they
| were hired for at beginning or outside their competences?
|
| Why is it outside (and not just outside, but clearly outside)
| of what they were hired for or what their competencies are?
| Engineers work on the product. Engineers review each other's
| code. Engineers are a stakeholder in this whole process --
| after all, the candidate may become their future colleague,
| and engineers are best positioned to know what they want to
| see in a prospective colleague. Engineers can appreciate
| whether their peers have the desired skills.
|
| Why does this activity require a higher pay than developing a
| new feature with your teammates?
| scarface_74 wrote:
| I get paid to bring my knowledge and skills about computers
| and systems to bring business value to the company - to make
| them money or to save them money.
|
| During the past decade, that has been as a "senior" employee
| of some sort. By senior I don't mean just "I codez real gud".
|
| That has meant:
|
| - Being on calls or flying out to a customer's site to
| support sales in closing deals when I was working with B2B
| companies and later full time working at consulting
| companies.
|
| - Interviewing candidates
|
| - leading teams and come project management work.
|
| - hands on keyboard coding
|
| - DevOps [sic] setting up architecture for empty AWS
| accounts.
|
| But I'm always up front about tradeoffs to management. If
| they want me to do one thing on the list, there is an
| expectation that something else on the list won't get done. I
| don't put in more than around 40 hours a week aside from the
| infrequent business travel.
| godelski wrote:
| > At home coding challenge
|
| I won't do an at home coding challenge, that is, unless you pay
| me. It's not about time investment, it is that we need to
| respect one another. You also have to realize a lot of places
| will use these "challenges" to get free work done. I'm sure
| this isn't what you're doing, but how is the person
| interviewing supposed to know? It is definitely a red flag.
| Built from good intentions, but a red flag nonetheless.
| sensanaty wrote:
| (I do the interviews at our company, but I'm just a regular
| dev and not in management or HR or anything like that)
|
| I get where you're coming from, and I've tried to fight to
| get people paid to do our take homes because I also feel it's
| only fair if we're expecting them to spend ~3 hours of their
| own time, but you also end up in situations where people will
| do the interviews _just_ for the money. We had a small trial
| run with a pretty laughable sum, something like 40 bucks just
| to test the waters and see how people reacted (this was for a
| very high paying role, mind you), and we got a _staggering_
| amount of people who clearly didn 't care at all about the
| role and just wanted the free money. Like literally would
| just post a link to a random repo or whatever, completely
| unrelated to the takehome, and you as the company don't
| really want to be in the situation where you argue with
| candidates about what constitutes a "real assignment" for the
| purposes of payment.
|
| It's one of those situations where a handful of dickheads can
| ruin a good thing for the decent folk.
|
| At least personally, I dedicate as much time to reviewing the
| takehomes as the candidates themselves put in. I write
| extremely detailed feedback covering every single line they
| present us and we supply that feedback to candidates
| regardless if we're moving forward with them or not. Also
| importantly, in the candidate gives us an actual assignment,
| we _always_ move them through to the discussion part of the
| interview, except for cases where the assignment was
| basically not done at all or was egregiously terrible. I feel
| mixed on this one, because sometimes it 's clear from the
| assignment that chances are slim for the candidate, but I've
| also seen some pretty bad takehomes end up with super strong
| hires at the end (and vice versa!) from the discussions.
|
| HR even tells me that a few candidates reached out and wanted
| to thank me personally for the feedback I gave them even when
| they didn't end up getting hired, so at least from what I can
| tell people don't mind the way we do it. I personally fucking
| _hate_ doing interviews, regardless of which side of the
| interview table I 'm on, so at least when I'm the one doing
| the breathing-down-the-neck thing, I try to make it as good
| of an experience as I possibly can.
|
| IMO it's the fairest interview method, and the one I
| personally prefer to do when I'm the one interviewing (as in,
| when I interview for jobs). In my experience it's always been
| pretty obvious that the takehomes aren't for any actual work
| (obviously I can't speak for everyone here, I'm sure it
| _does_ happen) and it 's always a pretty made up scenario
| that is loosely tied to what the domain is. I know that it
| can be unfair for people with a lot on their plate, at least
| I've been lucky enough that 2-4 hours out of my week is
| pretty doable, and especially compared to something like
| leetcode (which most people still have to study for, so the
| 2-4 hour thing is pretty moot IMO) it's just incomparably
| better. I've tried doing "just talking" types of interviews,
| but there are a lot of good bullshitters out there, so there
| has to be _some_ type of actual programming just to weed them
| out.
| oreilles wrote:
| Maybe you should have read the whole sentence.
| godelski wrote:
| I did. I even read the whole comment
| drdrek wrote:
| Have you ever integrated code a candidate wrote into a code
| base? Have you ever met anyone that have?
|
| Ask yourself why not
| jama211 wrote:
| Personally I love take home challenges because I can destress
| compared to coding in front of someone and I can prove what
| I'm made of. Got me jobs that has. It's a part of life.
| musicale wrote:
| It seems fair and appropriate to pay applicants (or employees
| for that matter) to compensate them for the additional time
| required for a take-home assignment, even if it's not actual
| production work for the company.
| pavel_lishin wrote:
| By that logic, you should be paid for every minute of the
| interview process.
|
| Which is a reasonable stance to take! But not if you want to
| be paid for take homes, but not for interviews.
| godelski wrote:
| Please operate in good faith[0,1]
|
| I think any reasonable person can interpret that there is a
| meaningful difference between an hour of work and several.
| The same way you might drive your friend across town for
| free but you're probably going to ask them for gas money
| and some beers if they ask you to help them move across
| state. An hour of my time is just less valuable than my
| entire day.
|
| [0] https://en.wikipedia.org/wiki/Reductio_ad_absurdum
|
| [1] https://news.ycombinator.com/newsguidelines.html
| eunos wrote:
| > veto right
|
| I honestly disagree with the veto right because it makes it too
| easy to be abused. In my opinion, a supermajority (66% or even
| 75%) agreement should be sufficient. They said that Liberum
| Veto rotted the Polish-Lithuanian parliament.
| shortrounddev2 wrote:
| Francis Fukuyama calls this system (everyone gets a veto) a
| vetocracy, and it basically means that nothing ever gets done
| tuna74 wrote:
| How do you select the people who get to talk to your CTO?
| belter wrote:
| > We are doing coding challenges
|
| I won't do a coding challenge unless you do mine too. Don't
| they always say interviewing should be mutual evaluation?
|
| Here's the deal: You give me your standard coding challenge,
| then we reverse roles for an equivalent one I prepared. We do
| this for the full interview duration.
|
| If you can't solve mine, that tells us something important
| about the technical bar at your company. After all, if coding
| puzzles are truly predictive of job performance and essential
| for determining candidate quality, then presumably everyone on
| your team, and especially those making hiring decisions should
| excel at them... ;-)
|
| If your coding challenges are going to determine my
| professional future, and your company claims it only hires "the
| best," then you should have zero problem demonstrating that
| same level of excellence. I wouldn't want to work somewhere
| where the interviewers can't meet the standards they are
| imposing on candidates.
|
| Either these challenges are meaningful indicators of ability
| (in which case you should welcome the chance to prove your
| team's competence), or they are arbitrary hoops and in that
| case, why are we doing this?
| mcprwklzpq wrote:
| When does the CTO has time to be the first unit in the
| pipeline? How much applicants do you have?
|
| From our experience just posting a junior web developer job
| gets up to 1000 resumes into our inbox. And we just a small
| company without an established name.
|
| The only possible first step for us is to automatically send
| everyone an at home coding challenge. This narrows down the
| list to only about 50 developers that would reply. Only 10 of
| them would send working code. And only at that point we can
| actually start to interview.
| whatever1 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| ludicrousdispla wrote:
| I generally make it a rule to not share my screen,
| install software, or create a new account as part of an
| interview process, so using an online coding platform is
| nice.
| mixmastamyk wrote:
| Disagree. Am a good programmer who can't perform under stress
| or surveillance. A code review would be 10x less stressful
| than writing fresh code and enable me to show off knowledge
| easily, in a good way.
| ethan_smith wrote:
| Debugging exercises reveal not just technical knowledge but
| also communication patterns - how candidates ask clarifying
| questions and explain their reasoning reveals more about their
| daily work habits than most algorithm puzzles.
| aaronbrethorst wrote:
| 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 wrote:
| I disagree on the "taste" aspect: I don't think it's valuable to
| take that into account in the slightest.
|
| A lot of the time, technical interviews and take-home exercises
| turn into 100 iterations of "Do you prefer vanilla ice cream or
| chocolate?" or "Do you prefer vi or emacs?"
|
| A good employee will figure out the subjective tastes, biases,
| and cultural quirks of a workplace, and fit in. A senior engineer
| will have done it perhaps half a dozen times in their career. --
| And yet, companies insist on putting interviewees in a situation
| of having to basically mind-read those subjective tastes and
| biases to try to tell interviewers what they want to hear,
| because they'll reject a candidate on the false premise that a vi
| guy will never fit into an emacs shop.
|
| "How do you feel about unit tests?" I really don't have any
| feelings about them whatsoever. Just tell me, if you want me to
| write them or not. Instead you're asking me to mind-read and
| trigger some hidden trauma in you. I just don't know whether the
| trauma is that codebase that required breaking production every
| single day, because there was no way to test it. Or whether the
| trauma is that one guy that you hired who never got any work done
| because he obsessed over refactoring the codebase for optimal
| testability instead.
| tropicalfruit wrote:
| 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 wrote:
| 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 wrote:
| 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).
| Buttons840 wrote:
| > 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.
| maccard wrote:
| It's a self contained class that is littered with basic
| errors and doesn't actually do what it's supposed to do.
| There's about 15 things wrong - missing pointer checks,
| uninitialised variables, public variables with private
| get/set functions, a memory leak, logic bugs that don't do
| what the prompt says it's supposed to do, subtle
| behavioural issues that come up in edge cases. We're not
| looking for every single one, but there is an alarming
| number of people who cannot identify even the most glaring
| issues of "there's a new in the constructor and not a
| delete in the destructor".
|
| > Or did they really get by with writing broken C++ all
| those years without knowing the basics?
|
| Having inadvertently hired a handful of people, it's this.
| They write shonky c++, it just about works, but they spend
| all their time patching up the mess they've left behind
| rather than doing it right in the first place
|
| > I'm not 100% certain it's wrong with just 50 lines of
| context.
|
| These are blatant issues that we would expect a reviewer to
| catch in isolation. It's also an interview, we expect you
| to ask questions. You're told as part of the brief to ask
| questions if you're unsure. It's not a trick, we're looking
| to see if you can actually write the code or if you just
| can rattle off some of the rules.
|
| A good example is DIY. How do you install a shelf - you
| drill a few screws into the wall and stick a piece of wood
| on it. Being able to tell you that is very different to
| being able to do that level on a wall. I can tell you "use
| SQL to select the name of the users who have used X
| resource without any duplicates", but I might not actually
| be able to write that query ("select name from table group
| by X where Count(X) > 1")
|
| > I think C++ is a special case when it comes to
| interviews.
|
| I disagree. Give me a language and I can give you 50-100
| lines of code that just about does what it's supposed to do
| but is littered with issues. Offhand I could write the same
| thing for C#, go, python and SQL with very little issue.
| Buttons840 wrote:
| Thanks for the additional detail. It sounds like a great
| interview question; it's both easier, and yet more real-
| life, than something like "write fizz-buzz".
| OJFord wrote:
| I wonder how many of them would do fine not under pressure
| though. You're not (necessarily) weeding out experienced
| people who can't find actual problems in a 50 line class full
| of glaring issues, you're weeding out those who can't _under
| pressure in an interview setting_.
| maccard wrote:
| I don't necessarily disagree but anyone who is a c++
| programmer and sees class foo {
| public: foo() { ptr = new
| other(); } ~foo() {
| } };
|
| And doesn't immediately question it doesn't instil
| confidence.
|
| Interviews are inherently high pressure situations for the
| candidate, the only way to avoid that is to just let people
| try out on the job and fire them if it isn't working out.
| That's unfair to everyone.
| atomicnumber3 wrote:
| Forgive me, I'm a Java programmer.
|
| The glaring bug here is that ptr is - or rather the
| object being pointed to is - on the heap and allocated in
| the constructor, but the deconstructor doesn't free it?
| fake-name wrote:
| - ptr isn't declared in the class body
|
| - ptr is not being deallocated in the destructor
|
| (personal preference - use of class member without
| explicit `this->`)
| tremon wrote:
| Does this example even compile, given that ptr is not
| declared anywhere?
| tshaddox wrote:
| How could you ever know whether that's the case? Obviously
| it makes sense to try to conduct the interviewer with a
| low-pressure tone, and perhaps make accommodations for
| people who seems especially nervous, but at the end of the
| day I don't think a job interview has meaningfully higher
| pressure to perform than, say, the first few months of a
| new job.
| godelski wrote:
| I didn't say "no code" and I'm definitely not against some
| screener type of questions. But I am against having 6 rounds
| of interviewing and at least 3 of those being coding
| challenges where there's right answers to be gamified and
| made into a website or book for people to pay to memorize.
| maccard wrote:
| My preferred loop is:
|
| 15m recruiter screen (1hr Take home goes here if you're
| doing it) 30m hiring manager call 1hr tech interview 1hr
| team fit
|
| And a go/no go at that point. You can put the hiring
| manager call at the end if the hiring manager is a senior
| enough person that you need to protect their time.
|
| The tech test should be actual code, but not evaluated for
| syntax. I like a code review test but we've also done
| problem solving and writing pseudo code in the past. No let
| code, no algorithms and no tricky formulas. If you want one
| of those you should provide the formula. A good tech
| interview should be open ended enough that you can dig into
| whatever direction the candidate goes - if they go hard
| onto concurrency then follow that track, or if they go into
| testing then follow that track.
| lordnacho wrote:
| I agree. I've interviewed loads of people, without ever giving
| a job to someone who couldn't do the work.
|
| I just have a deep technical conversation. If they run out of
| things to say, they are not right for the job. They run out of
| BS, because I keep the conversation on specific things that you
| can't make up, yet keep it open enough that you have to bring
| your own experience.
|
| That's it, (spoiler alert!) it's like the great reveal in Kung
| Fu Panda.
|
| > For a lot of engineers their passion is related to their
| work.
|
| This is the guy you find with this method. He can talk forever,
| because he loves what he does and can't not keep doing it.
| dustingetz wrote:
| individual manager discretion produces widely variable outcomes
| at scale, a lot of (most?) managers are promoted "by default"
| because the company is growing quickly, or lost a key person,
| and there is no better choice available, and it would be hard
| work to go find and recruit a better choice and nobody wants to
| do that work. So we add process and structure to help
| underqualified personnel not totally screw it up, which
| produces fine results for a while until hierarchy and process
| gets too heavy and marginal returns start to decay, and viola.
| Leetcode and AI screening.
| godelski wrote:
| This would be a nice explanation if my last round of
| interviewing with a few big tech companies didn't involve
| interviewing with technical people. In fact, except for the
| first phone screening interview I exclusively interviewed
| with technical people.
| scarface_74 wrote:
| No my passion isn't my job. I have a long list of things I do
| for fun. Sitting at a computer is not one of them. My job is
| transactional - an exchange of labor for money.
|
| I can't exchange "passion" for food clothes or shelter.
|
| I'm 51 now and can afford to choose work life balance over
| money. But if I were younger and it's advice I give all younger
| graduates in CS is to "grind leetCode and work for a FAANG (or
| equivalent paying company)" and by pay I mean cash and RSUs in
| publicly traded companies not "equity" that will statistically
| be worthless.
| moregrist wrote:
| If you're in an interview, you've already agreed to an hour
| of your time talking to someone. Few technical interviewers
| expect their problem to be your passion. But I think it's
| concerning if you can't show interest in a specific problem
| and have a good technical discussion about solutions for an
| hour.
| scarface_74 wrote:
| I don't think I've ever even proffered "passion" about
| software development or whatever random B2B SaaS vertical
| the company was doing.
|
| I show proficiency, professionalism, expertise, and the
| ability to bring that to a job.
|
| I've had 10 jobs everything from startups, random big
| enterprise, and BigTech.
|
| Am I suppose to show passion about - bill printing? Field
| services sending technicians to people's houses? Railroad
| car repair?
|
| Admittedly my first job as an architect was for a company
| that managed sending nurses to the homes of special needs
| kids and the next two were in the health care industry, but
| after that it was dealing with cloud consulting (full time
| jobs) first at AWS directly then other consulting companies
| (currently a staff architect at a 3rd party cloud company)
|
| I can talk about technical solutions, be a post sales
| architect, lead implementations and do system design and
| coding all day long without being "passionate" about the
| business. It's just professionalism and my addictions to
| food and shelter
| godelski wrote:
| Passion can show itself in many ways. Why did you pick
| programming of all things? There's something there,
| right? If you can dig into a topic, that's a form of
| passion. If you're willing to put in hard work, that's a
| form of passion. These may not be the same thing as the
| person who gets excited about these problems, but
| something did drive you. And no one is so excited about
| coding that they are never dispassionate and never
| frustrated. The thing you're looking for is why should I
| trust that you have these skills? If there's nothing you
| can rant about, then I'd find that odd, even if you see
| it as a paycheck.
| scarface_74 wrote:
| I picked programming because I was a short (still short),
| fat (I got better) kid with a computer in the mid 80s.
|
| You can "trust" I have those skills because I can talk
| about my past experiences, you can throw any
| architectural or business problem at me and I can talk
| through it including tradeoffs and why I made the
| decisions I made. How I deal with organizational
| challenges, etc.
|
| My being able to dig into a topic is not "passion". It's
| my _job_. I get paid to know my subject matter deeply and
| to be able to ramp up fast on technology and the business
| domain.
|
| The deal is if I work at your company, you agreed to give
| me $x amount of money, benefits and for me remote work
| and in exchange I agreed to give your company all of my
| expertise gained over 30 years of working for 40-45 hours
| a week.
|
| You need me to code those 40 hours a week? You got me.
| You need me to be on a zoom call or fly to a client site?
| No problem. You want me to do pretty diagrams and spit
| out 40 page requirement documents or business proposals?
| I can do that too. Along with leading projects, cloud
| architecture, etc.
|
| Just understand, you get 40-45 hours a week. You don't
| get late nights, you don't get on call, you don't get
| weekend work, and my bullshit tolerance level is
| relatively low before I am looking for another job - ask
| my last nine employers.
| godelski wrote:
| Okay, so it seems like for the most part we agree in
| concept but disagree about the words used to convey them?
| Do I have that right?
|
| I laid out what __I__ consider different forms of passion
| and while explaining yourself you met some of that
| criteria. So I'm not sure where the anger is coming from.
| I hope you're doing okay and I really hope we can have
| fewer abusive employers. I'm really empathetic to that,
| and have quit several jobs because situations like you
| mention.
| scarface_74 wrote:
| It's not anger. I get tired of employers taking advantage
| of naive younger developers who have "passion" and
| underpay them and overwork them, expect them to have open
| source contributions and as you said yourself, if someone
| is "passionate" money isn't as important.
|
| These are the people who don't show "passion" unless when
| they get off of work they are doing side projects related
| to software development and usually end up getting burned
| out.
|
| I've also avoided burn out, stress over work and I am
| able to survive in the industry for 30 years because I
| understand the transactional nature of the job and set
| boundaries.
|
| Someone who does there job well doesn't mean they are
| "passionate", they are "professional".
| tshaddox wrote:
| But if you need someone to show up and code every day, you also
| need someone who is willing and able to do that. I don't think
| a passionate chat can demonstrate that.
| scarface_74 wrote:
| He mentioned that Oxide has an interview process that takes 20
| hours realistically between coming up with work samples,
| answering 8 questions before hand and 9 hours of in person
| interviews.
|
| I was curious about the pay.
|
| https://www.glassdoor.com/Salary/Oxide-Computer-Salaries-E54...
|
| For their "senior" engineers it's in the range of offers for I've
| seen for new grads at most of the tech companies and around the
| range of generic enterprise CRUD developers.
|
| No offense to "enterprise developers". I spent 25 years as one.
| But why would I jump through hoops for a job that pays about the
| same as I could hypothetically get based on interviewing for a
| few hours and asking generic behavioral questions and maybe some
| techno trivia about whatever language the company uses.
|
| I find it fascinating that companies want rockstar ninja
| developers but then offer meh compensation for the positions.
| bcantrill wrote:
| So (foolishly?) I had never bothered to check Glassdoor,
| because we have been so upfront about our compensation.[0] But
| apparently that was a mistake! If it needs to be said, the
| Glassdoor numbers are comically wrong -- and in fact the high
| number in the "Engineer" range was quite a bit less than what
| we payed everyone six years ago!
|
| [0] https://oxide.computer/blog/oxides-compensation-model-how-
| is...
| scarface_74 wrote:
| 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.
| sunshowers wrote:
| Big tech companies have mostly figured out some kind of
| infinite money glitch. I don't think comparing compensation
| at them to startups makes a huge amount of sense. (It makes
| _some_ sense from the perspective of how much money 's
| coming into your bank account--just not a huge amount.)
|
| Being a prominent face at a startup can also set you up for
| greater success in your career than being one of a hundred
| thousand at a bigco.
|
| And as you touched on already, the environment at Oxide is
| a million times better than the toxicity and empire
| building that happens at bigcos.
| retrocog wrote:
| Well structured temp to perm arrangements are usually win-win?
| notjoemama wrote:
| > 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 wrote:
| 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.
___________________________________________________________________
(page generated 2025-08-10 23:01 UTC)