[dancocos]

"Take-home technical assignment (~4h)"<-- This right here is why senior people aren't interested.

I've got 20 plus years of tech, I've been out of college since 1997 and you want to give a 4 hour homework assignment. If get you want to get a feel for someone's ability but this is more easily done by stating a problem during one of the interviews and asking the person "How would you approach this?" Listing for how they anticipate problems and tradeoffs.

[porcoda]

Exactly. 25+ years in tech here too. When a company says "we're going to give you homework", that is a giant flashing sign that basically reads "we assume your resume is a lie, your references are lying for you (or we just aren't going to bother calling them), so we're going to test you". Hard pass.

Having been on the hiring side of things, I get far more information out of a conversation where I can ask for details about someone's background and experience.

[devoutsalsa]

I got my most recent job offer by talking to the hiring manager & a couple engineers for about two hours. They grilled me on talking points I’d fed them in my CV, along with some questions I couldn’t have prepared for. No coding, no take home exams. It was pretty great.

[jollybean]

It's impossible to gather someone's competence from a resume or even in a conversation.

A 4hr assignment is generally a really good way to gather competency.

That said - it's just 'too much' of a hill for senior devs. to bother with and there are probably some ways to do 'regular interviewing' in order to figure that out.

I have hired a ton of Engineers and I've found a lot of senior engineers to be particular, crusty and a bit weird: excelling in some ares, but cantankerous in other ways.

But yes, 4hr hr take home is going to be a barrier.

[TameAntelope]

Yeah, but as a counterpoint: your years of experience are not indicative of your skill, just that you can meet some arbitrarily low bar for a long time.

The take-home technical assignment is to determine what, if anything, you actually learned in your 20+ years in tech.

A depressingly large number of people with that level of experience have not learned anything meaningful.

[reikonomusha]

As someone who has been a hiring manager for the last decade, I'm absolutely befuddled by the "tenure => competence" assumption.

Tenure doesn't weed out mediocrity by any stretch. In fact, the more tenure someone has, often the more difficult it is to determine from their resume alone whether they know anything.

[__d]

Time in the workforce doesn't indicate competence, but time at known employers can (since we're talking seniors here).

When you're hiring, you should know where you want to hire people from. Normally, you'll know someone there, or who used to be there, so you can do the unofficial check: "Hey, do you remember X who used to work in group Y at company Z? Should I hire them?" At worst, you can do a friend-of-a-friend check.

Of course, you should call their formal references as well, but their responses are normally going to range only from "yes" to "absolutely yes" (unless the candidate has messed up, and given a reference who will actually say "no").

Also useful: a short stint at a known-bad employer. This shows that the candidate recognized their mistake, and corrected it.

I'll normally only interview someone who I can't background if their resume looks super impressive and I've got no better options.

[LargeWu]

We do 2 hour interview. 1 hr of interactive coding with a sr/lead engineer, 1 with the hiring manager.

We want to see them solve a problem, sure, but what's even more valuable is seeing how they approach problems, can they explain what they're doing, do they ask good questions, etc. Much more predictive than just looking at the final output and seeing if it passes a few unit tests.

I would never hire an engineer without them writing actual code that gets compiled and run. It's the single most predictive thing we do in our hiring process. But, we also want to be respectful of people's time, hence limiting the coding session to an hour.

[carapace]

This was my first thought as well. "If you want me to do homework to prove I'm not incompetent that means your interview process is garbage." and it's an automatic pass on that company.

My second thought was noticing that OP didn't actually ask for feedback from senior talent, the questions are addressed to other people hiring, so I figured I'd keep quiet.

But then I couldn't help myself. ;)

[no_butterscotch]

Same I skip these. Same with interview processes that front-load things with an "Online Assessment".

[orblivion]

I worked somewhere that had a phone screen with very basic coding exercise just to weed out people who had no business applying, which was well over half. I imagine the online assessment is a similar thing.

[pnathan]

would you like a take-home or would you like a whiteboard session?

I need to have useful information that a candidate is more than a smooth talker.

[capableweb]

What do you get from a whiteboard/take home assignment that you can't get from a conversation where you grill them about their answers?

[pnathan]

Conversations allow smooth talkers to run a snow job on you. Having a work sample test provides a best-in-class hiring filter.

[oaiey]

If the hiring manager cannot distinguish a smooth talker for a senior role position, maybe the hiring manager is the problem.

There is nothing a work sample can provide what a conversation cannot show for a senior role.

[TameAntelope]

Okay so now we're hiring a hiring manager and a developer, great.

...or maybe people in this thread just don't like having to prove they know things in an industry where a lot of people don't know things.

[pnathan]

> having to prove they know things in an industry where a lot of people don't know things.

The number of people I have interviewed who have been unable to code fibonacci or fizzbuzz, even the number of people with "senior" in their resume, is genuinely remarkable. I can appreciate the tiresome nature of interviews, but someone having to demonstrate that are not simply fakers is, simply, critical to the hiring process.

For people who are "hired by network", that is a different story. But if someone is coming in through the front gate, I will insist on having some kind of technical scrutiny, in technical and documented form, rather than simple conversations.

Work sample tests, according to the literature HN member `tokenadult` has gathered, provide the best predictor of future work.

My druthers today is for senior engineers to provide two work samples: code and design. Neither _particularly_ long or _particularly_ challenging, in a time frame that is not onerous. If the engineer has a portfolio with recent work, that is, IMO, a suitable replacement for code. Again, the point is to elicit fakery and have a demonstration of being able to do good work.

[ShamelessC]

More like we're tired of having to "prove we know something" to people who have no clue what they're talking about (most recruiters).

Further, there are probably lots of software engineers that have _never touched_ your framework of choice and will be able to learn and become proficient with it in a manner of weeks.

[tiborsaas]

I've interviewed multiple people who were really great at talking about tech and work experience, projects, but when we got to the (not so hard) coding challenge they flopped.

[jen20]

Perhaps on you. I’ve never encountered someone where a 5 minute technical discussion told me less than a full day of interview would.

[ShamelessC]

Only if you yourself don't know what you're talking about...

[scarface74]

I’ve interviewed people for the type of role that the submitter is looking for. I can guarantee you that I could see through a “smooth talker”. In fact, I can smell someone who just memorized stuff from ACloudGuru a mile away.

[mrelectric]

I'm a "smooth talker" but boy, do I fuck you over on practical project with 3 seniors sitting next to me.

[krageon]

If you are not capable of dealing with charisma, you shouldn't be doing the interviews at all.

[d13]

Interview their referees and look at work they’ve done.

[peterkelly]

Not if you ask the right questions

[crummy]

What kind of questions would you ask?

[Silhouette]

would you like a take-home or would you like a whiteboard session?

"Not if you'd like me to work for you, no." -- An actually senior developer in this market