Hacker News Reader

> Imagine the tens of thousands of dollars saved if you had a 15 minute technical conversation and the other engineer is like, yeah this person's worth bringing onboard.

When I was interviewing for both junior and senior positions, my typical tack was to look through their resume and look for something interesting that I have some kind of background knowledge of. Or, alternatively, just ask them "what's the coolest project you've worked on?" From there I'd just let it be a pretty organic conversation where I'd just keep asking for more details until we've either gotten to the bottom of the tech implementation or have gotten to the point where they can say "I don't know, someone else worked on that".

So far I haven't been disappointed with any of the outcomes from that process; there was one where my conclusion was "no hire" and then down the road they were hired anyway... and it turned out pretty much how I figured it would. Good surface technical knowledge with a super scattered implementation.

>"what's the coolest project you've worked on?"

This is the first question I ask followed by, "What's the worst project you've worked on?" The answers are pretty insightful.

That's a pretty good one. Tells you what their idea of a bad project is and how much professionalism they can maintain while describing it.

"They made developers write unit tests!!!" vs "There were some personality clashes which unfortunately impacted on the team's ability to collaborate effectively".

A huge amount of information can be uncover with “tell me about the highest performing team you’ve been on? Lowest performing?”

“Ok, so the schema control tool we were using generated XML that SVN had a hard time merging correctly. We ended up with so many broken commits that we invented the Lock Rock. It was a rock that I picked up in the parking lot and you were only allowed to commit schema changes if you were in possession of the rock.”

I'm trying to install a webhook in TeamCity to send a notification to Slack whenever anyone across 16 time zones commits to specific paths in a Perforce depot.

I'll happily trade for your rock.

My new product idea: ~LockRock~ Mutex As A Service! Only $3/month/user subscription!

100% yes. The reaction to that question will tell you a ton about a candidate.

Most 'pretenders' I've come across over they years have outed themselves by cheating in the most idiotic ways on screening questions and failed to answer the most trivial coding questions because they've been so bad that they didn't understand even the level that was expected.

So I'm inclined to think your 15 minute intuition is nearly enough - the worst people reveal themselves very quickly. And so does the best people. Where a little bit more time might be needed is sometimes in the middle, but it's rare for more conversation to change the initial judgement.

Over nearly 30 years, there have been borderline cases where we might have overpaid someone, and a couple I'd have preferred not to have hired, but who still could deliver, but I don't think we've ended up with anyone who were bad enough to justify these kinds of extensive hiring processes.

I tend to see these complex hiring processes more as tests to determine which candidates are willing to jump through hoops and prove their eagerness and loyalty. E.g. when a FAANG sent me a reading list.... I declined, pointing out that if I needed to study for their interviews they weren't testing my skills, but how desperate I was to work for the. Their recruiters called me back a couple of times to try to convince me again.

I can understand them doing so, because they can, and getting people to who will see it as an achievement to get past these barriers might be worth it to them, but to me it just felt like I didn't want to work in an environment where people were so eager work there that they'd put up with that.

I had a great manager who was a coding genius, always available to pair even if it took hours to explain something, and has been a friend for years after we both left that company.

But before that company I had a manager at a very small company who absolutely had no ability to do the work — and would have failed a personality test on top of that.

Indeed, while it might not work in all cases you'd probably save enough time/money to make up for those cases where it didn't work out. I've often seen jobs posted that stay open for 6 months or more because some hiring manager and their team can't make up their minds on who to hire. Meanwhile, the project they want to bring someone in to work on languishes, or people who are already stretched thin burn out and go elsewhere. There's such an emphasis now on hiring the perfect candidate that it's the enemy of actually getting things done.

One of the biggest blights on the industry is the insistence on matching tech stack. Most jobs need a handful of strict but broad requirements like "has worked in a garbage-collected compiled language" or "has used a SQL database" or "has used the .NET ecosystem", or they're looking for a specialist in a particular field like compiler design or distributed systems. Instead they've got a list of hard requirements: "Go, PostgreSQL, Azure, gRPC, 10 years of experience with RAFT (other consensus algorithms like PAXOS not acceptable), some obscure ORM," etc.

Not all hiring managers and not even all engineers understand that every requirement winnows down the available candidates. Eventually you're left with only the people who are desperate enough to apply despite not meeting half your list of requirements. Those candidates are on average not as strong as the ones you'd get if you just asked for software engineers with any experience in consensus algorithms and listed your tech stack as an FYI.

One of the best jobs I've ever had needed C++ as a requirement. I knew C, but not C++. Hiring manager said, "It's just a language, you can learn it."

Went on to join the highest performing team I've ever worked on. I miss the first few years of that job... before the acquisition!

Similar to this is demanding skills in specific AWS services. It is incredibly grating because they end up fixating on mostly BS, non-transferable knowledge because it’s easy to test for.

This is very common where I am (Switzerland) and I agree entirely with your conclusion. It's not uncommon to see posts open for over 6 months and it often seems like this is because no candidate is good enough.

In the intervening time, a candidate not quite ticking all the boxes but with motivation and energy could have learned what they needed to and moved whatever the project is forward.

Do you think it might be because of the higher salaries? I live in Germany and they hire more easily, even though after usually 6 months it is harder for them to get rid of you than in Switzerland.

As a neighbor with the lowest salaries of the three countries (France) I can say that we have the same issue.

And for me it's clearly a people one.

It can be that the manager don't want to actually hire someone because they have personal interest of using consultants to do the job. Or the manager lack confidence and is looking for a unicorn to avoid making any mistake (probably the most common). Or the manager expectations are disconnected with the job proposal (they want a senior but the salary is for a junior or like said in another comment, they want someone with skills exactly aligned with the tech stack).

Here we have a trial period of at least three months so it's quite easy to get rid of someone if they don't fit but it's rarely used in IT and I don't understand why. And once the trial is over, it's quite hard to get rid of someone. But basically it seems that once your in, if the trial period is used as a quick exit it's mainly by the new employee and not by the company.

I didn't quite know how to answer but you've hit the nail on the head. Thanks!

I agree. In Switzerland employment law is governed by the code des obligations, or for the parent poster who asked in the first place, Obligationenrecht. There are various notice periods, 1 week in the first 3 months, 1 month for the first year and so on. An employer isn't required to give a reason for dismissing someone either.

I think it is entirely a people issue.

I keep saying this every time the topic comes up, but I think I can get a fairly decent idea of how well someone will perform in an hour of talking.

Just gouging their enthusiasm and knowledge of topics they may not necessarily need to be aware of for the job.

At least it seems to bear out so far, and if not, then it means all candidates are just decent and it doesn’t matter whom we hire.

> I had a interview in 2021 where I had to do a 1.5 hour timed exercise, that apparently isn't sufficient, so their interview pipeline has 3x1hour additional live coding sessions with engineers. Over 4 hours of coding just to prove I can write code up to their standards. Then another 3+ hours of behavioral interviews, meeting the team. Multiply that by the ~5 candidates you interview per position multiplied by each position you hire for in a given year.

... and then, after wasting thousands of dollars per candidate, many companies opt for RTO policies to "trim fat". Yeah, makes sense if you're an accountant / stock market analyst only focusing on capex vs opex and long-term liabilities (which employment contracts are everywhere but in the US with at-will), but from a holistic viewpoint it's all an utter waste.

Assume 30k of hiring costs related to filling any new position (and that's on the lower end), it makes zero sense to not grant existing employees even 2 grands a year in wage increase... but here we are. Financial games have ruined everything.

> Assume 30k of hiring costs related to filling any new position

That is MUCH too low. Most recruiters are paid 20-30% of first year annual salary as a placement fee.

Hmm. 4x1 hour live coding sounds silly. I'd rather have one 4 hour session where I can think before I write the code.