[gsibble]

Personally, I've never found it difficult. Have 1-2 interviews with a take home or in person coding exercise or however they want to prove to me they can actually code. Pay high, have great benefits, high equity, treat your employees well, and fire those that don't perform up to expectations quickly. It's really not hard to spot talent. Don't make them jump through hoops. If they are talented and get along with your team, make a quick and generous offer. It'll pay off in spades.

Also, tailor your job listings to tell them what they get out of the job. Don't list what you need. You're just culling potential applicants. Most talented developers can adapt to a new language or dev environment quickly. You don't need someone who already knows X, Y, Z and 20 other things. Attract people to your company, don't make a list of needs. Get them excited to work for you. And put your high salary range in the listing.

Every time I do this, I'm inundated with resumes from top quality applicants and can pick and choose the best fit. I've hired over 100 developers this way, almost all of which worked out great.

People just go about the whole process wrong. Make the job and company attractive to work for and talent will come to you.

[yupper32]

> Have 1-2 interviews with a take home.

> fire those that don't perform up to expectations quickly.

This attitude is why I haven't been recruited. I have 10 years at big tech and companies expect me to jump ship with the threat of getting fired if I don't immediately live up to expectations (even if I'm confident that I will, but I'll never know how high your expectations are until it's too late). Add on wild take home assignments on top of my full time job and (typically) less pay than big tech.

It's simply not worth the trouble.

[gsibble]

I've never poached someone without giving them a significant raise for one thing. I'm always clear about my expectations which are pretty simple - your time belongs to you. We pay you a high salary and expect you to get your assigned work done. As long as you get it done on time, you can fuck off and enjoy all of the excess time you have. If you do all of your two week sprint work in 20 minutes, you can enjoy the next two weeks off.

Most companies pile work upon their best performers. I'm the opposite. I reward our best performers by giving them back their time. Expectations differ some depending upon compensation, but really as long as you get your reasonable expectations done, I'm happy, you're happy, management is happy. It's never been an issue.

[PenguinCoder]

> If you do all of your two week sprint work in 20 minutes, you can enjoy the next two weeks off.

Citation/sources wanted. That was my expectation with a 'salary' job; being paid to get the work done. Work is done under 40hr, congrats go home! Work takes longer than 40hr, oh well. In my experience though, in _every single_ company punishes efficiency and hard work, with more work. You're done in 20h? CONGRATS, you get Bob's work now too! Make sure to get his and your work done! Leaving early is absolutely not heard of.

[gsibble]

Yes, I/we do things significantly different than any other company I've worked for. Working fully remote makes it easier since you don't see people getting up from their desks or not coming into work. Our developers have no set hours, can work any hours they want, and are only expected to get the work assigned to them during a sprint done, no more, no less. I brought this style of work to our workplace and it's been a massive success. Everyone is extremely happy and productivity is through the roof. Makes for very loyal and hard working employees.

If you read Drive by Daniel Pink, you'll learn that the things that unlock higher performance are Mastery, Autonomy, and Purpose. That's what we strive to give to our employees, including autonomy over their own time and how they get their work done.

[danenania]

I’m curious how you handle overly optimistic estimates with this approach?

Quality expectations make a lot of sense, but “on time” is famously hard in software. How do you decide whether the developer was slow or the deadline was unrealistic? And similarly, how do you protect developers from feeling that they have to throw out work-life balance to hit deadlines/sprints that turn out to be unrealistic?

[gsibble]

Good question. We generally overestimate to make sure people are given lots of time to complete a task. We also are not strict on deadlines. Didn’t make it this sprint but put forth your best effort in 40 hours a week? No worries at all. Good job. We’ll finish it in the next sprint. We never expect anyone to sacrifice work/life balance to further the company, a luxury of hiring only the best developers who keep my managers happy working reasonable hours. A lot of it is my managing their expectations as well. So far it’s working well.

[PenguinCoder]

Great to hear, glad that's working for you and the employees. Sounds great. Thanks for the book Req; I'm not in a position at a company to implement such teachings, I'm just an IC. Autonomy is certainly a big driver of job happiness for me though, I get it.

[gsibble]

Thanks! We're constantly refining it. Employee satisfaction is a huge priority for me as we only hire top talent. Happy employees are productive employees. And productive employees make my bosses happy which makes our sales go up which makes the value of my equity go up. Everything is just better this way.

If I ever feel like writing a book (fat chance), I'll try to spread the gospel.

[Ensorceled]

> threat of getting fired if I don't immediately live up to expectations

I also try to fire fast and every single time the issue is that they do not actually have the skills they listed on their resume.

That's why the coding test and that's why you need to fire fast.

I have all kinds of patience for good people that need ramp up time.

[JJMcJ]

You need to have a very very clear idea of what the new hire will be doing when they start.

Plenty of companies assign people badly and then act all surprised that they don't have a Plug Compatible Interchangeable Engineer. https://kidneybone.com/c2/wiki/PlugCompatibleInterchangeable...

[Ensorceled]

> You need to have a very very clear idea of what the new hire will be doing when they start.

Yep. My latest hire started a few weeks ago and I had a back log of pretty simple tasks that were well within their wheelhouse and a dedicated mentor to help bring them up to speed.

I've been on the receiving end of gruelling "sink or swim" initiations that were called "onboarding"

[bpicolo]

Take homes are one of the single biggest turnoffs for experienced talent in interview processes. People don't want to do them. Especially good devs who can land a job anywhere.

> Don't make them jump through hoops

The take homes are the hoops.

[Ensorceled]

For people with side/brochure projects, my "take home" tests are always "add these simple features to your git hub project xxx". Often it gets done the same day.

Otherwise, I'll do something simple, on a shared screen in the language of their choice.

It shouldn't be hours and hours and, ideally, it's a win/win.

[bpicolo]

Not being facetious here - if they have notable github projects, why do you want a new feature versus viewing or talking through something they've already developed in one of them? Why is the novelty important?

The shared coding screen is definitely the most common method. And the one I've found most folk prefer. There won't ever be a one size fits all solution, but ideally your interview methods are equitable across all candidates, and ones that the majority of candidates are comfortable going through. Disparate processes hurts the former.

[Ensorceled]

> if they have notable github projects, why do you want a new feature

It might not actually be their project.

> but ideally your interview methods are equitable across all candidates

My candidates are not competing with each other, the tests do not need to be "equitable" between candidates, just fair for that candidate.

One problem, for instance, with github projects is that it's a fairly privileged position to be able to have significant side projects. So it's not fair to expect a candidate to have a github presence and you would be eliminating people without a lot spare time (single parents is the go to example).

[coupdejarnac]

Is this commonly done? I haven't seen this before. If I had an interviewer do this for me, I would be very impressed.

[gsibble]

That's why I try to make take homes fun. I like the elevator problem in Python. Try to make elevator software that passes the unit tests. Sounds simple, right? Wrong. Very hard.

I don't really care how successful you are. I want to see how readable and maintainable your code is. Sometimes I just ask for example projects that I can read.

But I do need to know you can, you know, actually do the job. I personally find in person coding significantly more stressful than take homes. So what would you suggest? How do I test someone's ability to code?

[harshalizee]

It's not about if the take homes are fun or not. Far too many companies have varied take home tests that can take an hour or a 40-hour work week only to be ghosted after submission. I don't partake in any asymmetric interview processes, and many places are happy to let me skip it. I'm happy to sit on a zoom call with one of your engineers for a couple of hours and do whatever they want me code in that time. I'm just not into doing it on my own time with no cost to the interviewer.

[jenscow]

So if I asked you to do to a 1-2 hour coding task, you'd only do it if I were on a zoom call with you while you did it?

[harshalizee]

Yup! The interviewer can see my thought process. I can also evaluate my peers and ask questions about the work. The interviewer can also see how easy or cumbersome it is to set up the environment and code in the allotted time. Win-win.

[jenscow]

If I was hiring a junior, perhaps that would have some use.

[yupper32]

Yes. Put in the time with me to show you're serious. Otherwise you could mass spam candidates, most of which you don't actually care about.

[gsibble]

That's fine. We're happy to let you do that if that's how you'd prefer to show us you can code.

[ipaddr]

If you need experienced developers to show you they can code you are only going to get amateurs.

[ChrisMarshallNY]

My experience is that, whether it be via interview, take-home, or whiteboard test, what employers are looking for, is $buzzwordDuJour.

I may be being generous. I am noticeably “older,” so it may have simply been bald-faced ageism, in my case. Maybe younger folks would have been given more latitude.

I remember getting a take-home, once, where they asked me to write an iOS app that leveraged a specific library. They did not provide a template. They simply sent me an email with a fairly vague spec (I'm fine with that). They also wanted me to use a specific $methodologyDuJour, that would have resulted in needlessly complex, underperformant, and buggy code.

At the time they gave it to me, I had a pretty serious personal family emergency, so I did the app, using the industry-standard method. I wrote a full-quality, localizable, documented app, in less than four hours. While my house was trying to burn down, so there was a bit of extra stress.

Oh, and also, I had never worked with the library they wanted me to use, so I had to learn the API.

So, I wrote a full native Swift iOS app, from scratch, learned a commercial API, integrated it, tested the app, documented it, and delivered an App Store ship-ready iOS app, with very high-Quality code, in about four hours, while under serious personal stress. I did let them know that I had had to deal with a "personal emergency," so the test was a bit "rushed."

They ghosted me hard after that. I was actually shocked at how discourteous they were, as everything before that, was great.

[ipaddr]

Ghosting after take home tests are extremely common. Usually the longer the test the more likely you are to be ghosted.

[ChrisMarshallNY]

It was also pretty damn stupid. That was one of the motivators for me to stop bothering to look. I didn't need the work, and I was looking for work that interested me (this was a hardware company that made a system that interested me).

They maybe didn't like that I used classic MVC for the app, because it is ... less than optimal ... to use other patterns, when writing a UIKit app. Of course, it's also possible that they finally brought in a tech manager, who figured out I was old, so...

But I regularly write full apps in record time. My GH repos are full of test harnesses that I toss together in no time at all. Pretty much every test harness is one that many folks would be proud to submit to the App Store. I’ve had over 20 published native apps, over the last ten years (mostly deprecated, these days), so I’m used to regularly shipping (and maintaining) native iOS apps.

I'd suggest that someone that can chock together an app like that, in just a few hours, while under a serious amount of external stress, could be someone worth following up on. BTW: The library was MapBox. I'd never worked with it before. I enjoyed the opportunity to learn about it, as I may use it in the future (offline maps, and it's a pretty decent dependency).

But that was about three years ago, and I'm actually really glad that I got chased out of the rat race. It just took me a while to appreciate it.

[JamesBarney]

Maybe a better way to phrase it is, "make the hoops count".

[vbezhenar]

It's not hard to recruit good developers. It's hard to recruit good developers without paying premium. Pay $1 billion/month and you'll recruit anyone. This is ad absurdum, but you've got idea. If you can pay high, of course it's easy to hire talented developers.

[gsibble]

I don't believe in paying good developers less than they are worth. I'm a CTO. I'm the developers evangelist inside my company. Their success is my success. Their happiness drives my KPIs. I'm not interested in saving a few bucks. I'm interested in getting the best talent I can. I have gone to the mat to fight for people's salary increases and asks many times and won. And it's always paid off (why I don't even have to ask permission for making high offers anymore). Good developers are usually worth significantly more than what they think they are and what they are happy to get paid.

[sys_64738]

You lost me at "with a take home". I'm not interested in your silly games.

[gsibble]

Ok. What would you suggest instead? I need to know you can, you know, actually code.

[WkndTriathlete]

Talk to the candidate. If you (and the candidate) cannot communicate well enough in 30 minutes to discover that then either (a) you don't know enough to work well with a really good developer or (b) the developer doesn't know enough to work with you or (c) both are true.

I have never been let down by this rule, either as a candidate or an interviewer. In my experience coding exercises as part of an interview process are a big red flag to me indicating the company is trying to compensate for lack of in-house talent with process or they are trying to replace someone with a certain hard-to-find skillset because they have an immediate fire they are trying to put out. Neither situation is a good one to get into.

[gsibble]

Trust me when I say I've talked to plenty of candidates who I thought were great only to learn they couldn't actually code fizzbuzz. Talking to candidates doesn't work.

[sys_64738]

You want programmers to do tricks and silly initiation dances which is your whole problem. If you actually asked real questions about their experience then you’d get a good grounding. I might do silly problems for a high profile employer but that’s likely not you. In which case if I tell you to stop wasting my time and walk out of your attempted initiation ritual then you won’t like it.

[gsibble]

No worries.

[ipaddr]

You might not be good at judging candidates. A good cto uses their gut and experience. An inexperienced or someone who doesn't have the gut uses tricks. Where do you fit?

Have you taken any courses or worked with professionals to help you with this?

[jenscow]

There are people who genuinely believe they are good at their job, when they're not. They're not bullshitting and the conversation is genuine.

Just 10 minutes of coding (or attempting to), tells you they can't code. A little longer can tell you roughly how good they are.

Experienced developers who can code have had the misfortune of working with people who couldn't pass this, and may appreciate that the members of their new team can.

Where do you fit?

[NaturalPhallacy]

My favorite because of how realistic it is, is have me/the candidate do a code review. It's a real world thing that will be a part of most jobs that doesn't require artificial nonsense like coding in a browser, memorizable hacker rank crap, or some throw away time wasting coding challenge. As for if I can code, I have seven public github repos, 3 of which are previous take home challenges of varying degrees of absurdity.

[gsibble]

I said this elsewhere but reviewing previous projects or doing a code review does help somewhat, but it leaves out my ability to see your actual coding skill re: speed. I need to get a sense of that in order to feel comfortable hiring you. The only way I can do that is if you do some live coding one way or another. How you do it at our company is entirely up to you.

With our salaries, we have yet to have anyone turn us down when we get to that stage of the interview, but maybe someday it'll happen.

[pjmlp]

Ask about project work, and real technical questions.

Many of us have a real life, and enough offers to chose from.

[gsibble]

Sorry, but neither of those things show me that you know how to code. I don't know how long it took you to write your projects so you may be very slow and a terrible coder. Technical questions you may have prepped from a book. I need to see active coding, either live, in person, over zoom, or time boxed in a take home. We'll even compensate you for your time. But I need to see you actually working and review your work. Sorry.

Quite frankly, relying upon such things is a sure-fire way to make sure some bad developers get through the cracks.

[pjmlp]

No need to be sorry, I wouldn't apply to your company, and you would be lucky to even get a reply from me if contacting me on the typical social networks for developers.

Sorry.

[gsibble]

No worries. Sounds like we wouldn't want you anyways if you have such poor work ethic.

[akvadrako]

Paid take home assignments are the best in my experience.

[gsibble]

If someone asks for it, we pay for their time. And we offer to get a sense of how they can code however they want. Take home, virtual pair coding, in-officce pair coding or coding exercises, whatever you want. We just need to see you code in a timeboxed way so we can see how you solve problems and see the results to make sure you write readable, maintainable code.

Almost everyone picks take home. Like, over 95%. I'm not sure why people here are complaining about it except that the accounts that are were made 2021+ so maybe it's a generational thing.

[sys_64738]

I know that code and that’s what the resume says.

[JJMcJ]

> fire those that don't perform up to expectations quickly

What's the compensation for that risk? "We'll fire you in six weeks if you don't work out, so please leave your current job where you're well established and have about a 0.5% chance of getting fired this year."

Something like guaranteed six months severance, or a $100K reporting to work bonus with no clawbacks.

At the C-level, these kinds of guarantees happen all the time.

[gsibble]

Honestly, we've never encountered this problem. I've never poached someone that didn't work out. Usually, if I poach, I have to pay a premium so I'm fairly sure they can do the job.

[JJMcJ]

That's the hiring side of the issue.

What's the assurance for the person you are recruiting?

[gsibble]

We usually hire people unhappy in their current position and make an appealing offer. The chance that switching jobs may not work out is a chance all employees at all companies take. We don't do anything specific to protect against that like 99% of employers.

[analyst74]

Great advice.

We can see the opposite in Amazon where they successfully built a reputation as a terrible place to work with low pay relative to its peers, and now struggle to attract talents.

[gsibble]

I've heard horror stories. No amount of pay could get me to work there.

[jstx1]

Everyone else thinks that their way of hiring is the best too.

[gsibble]

Ok, tell me yours.

[intelVISA]

Good approach but can't imagine doing a take home unless it was paid.

[endtime]

I've never been asked to do a take home interview assignment, but I actually have the opposite attitude. I would much rather spend a few hours putting together that I feel good about than spend 10x the time cramming interview prep.

[intelVISA]

I prefer a take home over some LC as you can learn a lot more by seeing somebody's repo, tests, code, etc. than their rote ver of reversing a linked list ...but LC is cheap, a take home that respects the developer's time isn't.

[noirbot]

Or, you know, you don't cram for the interview and just do as well as you can and let them evaluate on that. If you give me a meaningless take-home assignment, I have to actually write working code for it that looks good. If there's a trivial problem in an in-person interview, I can often "blah blah blah" through the more rote parts unless they really ask for details.

There's no wiggle room on a take-home. The code you write either does the thing or it doesn't. If you don't remember the exact way to do something in an in-person interview, you can express your general understanding to the interviewer and probably get some/all the credit of actually knowing it.

[endtime]

> Or, you know, you don't cram for the interview and just do as well as you can and let them evaluate on that.

Sure, depends how much you want the job and what your general approach is. If it's a competitive job then you want to optimize for the interviews. Last time I interviewed, the potential impact on my income and net worth over the next decade was significant, so I took it pretty seriously.

[noirbot]

Oh sure, but then as the interviewer, your take-home is also likely to be gamed by someone cramming for that too. Motivated people can always do too much work for a project. Whether it's a live coding thing, a take home exam, or a whiteboard problem, none of them really give a solution where someone isn't going to spend 100 hours prepping.

[andrewingram]

I did one that was time limited (2 hours, automatically timed and enforced). The exercise wasn't hard, but it did have some tedious quirks which meant I wasted quite a bit of time. But I thought "fine, I can jump through this 2 hour hoop". After I submitted it, it turned out there were some previously undisclosed extra steps where I had to record videos doing the kind of things i'd expect to do in an actual interview (talk through my solution, and talk about a project I'm proud of). I immediately lost interest.

[gsibble]

If the person requests it, we pay for interview time as long as the hourly is reasonable. Not a problem.

The real question I have for you is, how would you prefer to prove to me you can actually do the job? In person coding exercise? Isn't that more stressful?

[andrewingram]

How long do your take home exercises take?

I've always conducted interviews where I've given system design questions, and data modelling questions. Never found that coding exercises give good enough signal to justify the time investment on either side. If you want to catch someone in lie, i.e. they can't code at all, just give them something of fizzbuzz-level difficulty as a basic filter.

[gsibble]

Depends upon how much proof I think I need to see. Both min/max are an hour but you can spend as long as you'd like on some. We take fun problems (github challenge projects I've spent days on just for fun) and give them as tests. We ask you just to spend as much time as you want to give us a sense that you can actually code and give us a sense of your coding style. We're mostly looking that you can 1) actually solve problems 2) write legible code 3) write maintainable code.

We don't give out dumb, tedious quizzes or anything. These are actual projects written to be fun. We don't get many/any complaints.

We also give out the coding test very late in the interview cycle. I'd say we hire 80% of the people we give tests to. We already have a pretty good idea you'll be a good fit by that point. So we're not wasting your time.

[intelVISA]

No issue with take home approach, I think it's incredibly valuable if done in a manner that respects everybody's time.

Personally I'd probably do some sort of FizzBuzz/LC easy type low filter and then a fast (i.e. no compiled langs) take home in an area adjacent to the job description paid at said job's rate with a time expectation so you don't end up getting billed 20hrs for a Node RESTful API.

[gsibble]

We very infrequently get asked to reimburse for time but we do limit how much when we do.

We usually give various challenges as take homes which people find fun and engaging, projects that I myself have spent hours or even days trying to solve in my spare time. We want them to be fun. We rarely get complaints.

We're happy to accomodate if you'd rather do it in person or over zoom. It's really up to the applicant.

[intelVISA]

I can appreciate that and obviously what you're doing is working out for you :)

Guess I'm prob the odd one out here -- unless the job was incredible (like pair programming with J Carmack) I wouldn't be able to commit to any meaningful unpaid take home as I can spend that time programming for profit rather than solving challenges for a company that may or may not work out.

[gsibble]

That's fine and up to you. Our interview process is extremely streamlined and requires 1/2 - 1/5 the time of most engineering interview processes. We do require someone to show they are capable of doing the work. How would you prefer to do that so I can take your feedback into account?