I don't care how much help they got if they can discuss their solution coherently. This also shows the candidate that we took their solution seriously.

It's wonderful you don't care about the fact that these solutions are purchased. I'm sure your attitude is a great comfort for all the honest professionals who worked hard to find the time to do a 5 hour take-home, only to see their job taken away by dishonest candidates who paid for the solution.

Taken to its logical conclusions, if your attitude is representative, then everyone should just buy take-home solutions and just spend a bit of time understanding them before the onsite. Now we're back to square one, except at least we're not actively screening for dishonesty anymore.

If copying/buying solution is actually a problem, that means take home project is a thing that's happening, and copying is the new problem to solve along the way.

We're far from there.

In case you didn't know this: take-home is very much happening. I was job-searching not too long ago, and roughly 10% of the places I talked to insisted on take-home assignments. I declined all these requests because I'm a senior engineer with many options, but clearly many candidates are taking them.

There really is a problem with people buying solutions for take-home assignments, I saw that when I was hiring. It just isn't acknowledged, so effectively it has become a competitive advantage for dishonest candidates who are willing to cheat.

Very occasionally the candidate came in and just was wildly off, but usually it was fine.

Later on we changed to having all candidates submit the takehome under the logic that if they’re a, “positive” candidate that they’ll be inclined to see this as an opportunity to strut their stuff. I was a little unsure about this approach but we went with it.

I’m curious how senior folks feel about these different attitudes.

It's quite simple: I'm a senior engineer and I will never do a takehome assignment.

Every time I'm on the job market, there's a certain percentage of positions that require a take home. I just skip them.

I don't explain my position, since I learned long ago that it just leads to arguments and confrontations with the very same recruiter who just a hours ago cold-called you begging you to interview.

I just terminate the process as quietly and unobtrusively as I can.

I wish I could comfort you by saying I ever regret this decision, but the truth is that the best jobs out there - the Google, Netflix, Airbnb jobs - do not require a take-home assignments. I guess they know better than to restrict their candidate pool in this competitive market.

It tends to be the below-average and (often) crappiest jobs that require take-homes, to the point it became a red flag to me. Now I often wonder "what kind of a desperate crappy senior engineer had to jump through all your hoops in this market, especially when you're just one anonymous company out of tens of thousands to be hiring engineers, with nothing special to recommend you this early in the process?".

In short, to insist on take-home tasks in this market is to give up on your strongest candidates. Neither me nor many senior engineers I know will at all consider spending 5+ hours on takehomes when we can easily get dozens (!) of onsites with short, fun remote screens. I will also be very skeptical of any engineer who in this market is willing to do these hours of takehomes after a long, hard day of coding at work.

One last point: it seems quite unfair rude to me for a potential employer to ask me to unilaterally dedicate 5+ hours of my rare valuable time, when we barely begun the process. It's especially out of place and comical when the same recruiter who literally begged you to interview in the first cold-call, is suddenly demanding you do 5+ hours of unpaid work. At least in remote screens, I know the employer is investing some of their own resources into this process as well.

My logic on the take home was that interviews are hard without something to talk about and contrived problems are not super reflective of real work. Therefore, I’d send a dumb version of a simple task we have, then we’d walk through trade offs and such.

If I have some code you wrote and can walk me through that’s a very useful datapoint not just for competence (if you’ve been around a while you probably are good) but for personality and how we’d work together.

Does that seem more reasonable as a trade off for your time?

At some point I think senior engineers realize that coding is the absolute least of your worries as someone expected to do things like interface with the business side, plan medium/long-term roadmaps, improve dev tools or general architecture to make juniors more productive, or mentor/train/manage juniors.

When the entire process seems to be heavily weighted towards coding, it gives off the vibe that this is a company that recognizes overworking and churning out code as traits of a senior engineer, instead of shrewd decision-making, efficient delegation, smart scoping of projects, strong leadership skills, etc etc etc.

I don't want to spend my free time building a portfolio of random bullshit code any more than I want to spend time on your take home test. Because I can't for the life of me see why having an impressive (or average) github profile should be the leading indicator for senior engineering skills.

What is wrong with simple live-coding sessions on very small pieces of code while discussing objectives, edge cases, extensions, etc? Coupled with a high-level systems design session with whiteboard diagrams but no code, and a behavioral interview assessing leadership skills, extracurriculars, personality type, etc. Sane companies seem perfectly fine with sticking to this formula.

Where is this idea that we need more and more, deeper and deeper assessment of candidates coming from? What problem(s) is this solving to look at large amounts of pre-written code from candidates?

I think our focus on code was based on the fact that everyone needed to write code. We were a small company so there was less of the architecture work. We may well have benefited from doing more of it, but we still needed people to ship lots of code.

You do ask a very important question for which I don't really have an answer: why do we care so much about these take-homes or coding interviews for people who have been around for a while?

For me I'd say because I want to have a point of comparison with all other candidates, but that's a pretty weak answer. I'll think more about it.

This assertion makes absolutely no sense at all. Not being able to pass a simple fizzbuzz test doesn't mean the candidate is among the strongest there is. It just means that the candidate was either incapable of taking such a simple test or unwilling to provide any assurance that his alleged seniority made him a paper tiger.

I've personally interviewed a candidate who had a double major in math and CS, had a PhD, declared having over 10years of experience as a senior software dev, and on the first interview he showed he didn't even knew how to include a third-party library on what he claimed to be his programming language of choice he used most of his career.

That's the sort of stuff that take at home tests help weed out. If he took the test he wouldn't have wasted hours of his and our time.

Nobody is talking about fizzbuzz. We are all talking about take home assignments that take hours, generally 5-10 hours and sometimes more.

I code and troubleshoot for $$$, and unless there is a direct route to interview + hire (or at least lunch) I'm not interested. I understand there are sorting methods needed to do hiring, and I'll play that game if I have to, but if there is no direct, up front expectation that I'm in the running then it's just kind of patronizing without payoff.

I can't imagine a scenario where a person can't solve the problem, so hires someone to do it, then explains it as well as the person that actually wrote the code. If you can explain it that well, with reasoning for tradeoffs and design decisions, you might as well have written the code yourself and saved some money.

In the few hiring processes where I've participated as a hiring consultant, take at home tests were only used in the initial stages of a hiring process to filter out blatantly incompetent candidates, who in some cases represented about 90% of all applicants. We're talking about basic fizzbuzz stuff.

Even so, in subsequent stages the candidates who made the cut were again evaluated based on their technical skills, mostly to weed out candidates who might have cheated their way through the first stage.

This meant that it was impossible for dishonest candidates to eat the lunch of candidates who were cut due to their performance of the take at home test because anyone who failed that test was obviously not a competent developer. I mean, are you expecting to be hired as a professional software developer if you can't write a for loop?

You are naive if you think you solved cheating by checking technical skills on the onsite. What if I'm a 7/10 candidate, and someone else is a 9/10, but I cheat and submit the solution of my friend who is a 10/10. I'll get the flight ticket to the onsite, the better qualified guy will not, and you will have to choose from a smaller pool of candidates, in which I might be the best one.

We think this is better then wasting the candidate's time on a toy project - at least the can write off their time on the opensource-karma account.

Also, we can check not only their code but also their communication style and other skills that matter in the real world (projects on our tech stack have a high threshold for documentation, unit tests and other stuff that matters).

We call it "social code challenge" and it is working wonderfully for our recruiting process.

A candidate might reasonably assume that they can look better than the other candidates by spending more time on the problem and tackling a larger or more impressive ticket. If you imagine a world where all interviews were like this, candidates could end up working 60 hours a week on these projects in the normal course of job hunting (easier to imagine if you assume that the talent shortage isn't permanent). Probably, since they can see the size of the contributions made by previous candidates, the pressure increases over time as well.

edit: it would be amazing for FOSS in general though. Imagine how much faster GNOME would be if hiring committees required you to write bug fixes for popular projects.

The same is true with a take-home, candidates see the (often underestimated) statement "this should not take more than X hours" and assume they will have a better shot if the invest more than the X hours.

I forgot to mention that we also accept past contributions - in the end the hypothetical candidate can spread this 60 hours investment over any other hiring processes using the same method.

I'm thinking about writing a "social code challenge manifesto".

My advice is always "build experience contributing to FOSS projects in your spare time".

We are pushing the envelope and often find bugs or lacking features. I want to hire people that can fix/implement those and send the PRs upstream instead of nagging the project maintainers.

[1] https://stackoverflow.com/users/22656/jon-skeet

[2] https://stackoverflow.com/users/444036/paulo-scardine

Why compare the results to work done in a completely different medium with no opportunity to iterate on the output, take a break or work comfortably?

If you assign a take-home test, make the interview focus on discussing the product.

You can have one-way trust in a take-home. If they don't meet your quality bar, you can discard the resume. And it takes near zero work on the company's part, that's why so many companies like it.

However, some people will just get a lot of help on the take-home. So it isn't fair to the other applicants if you treat a take-home as anything other than a filter.

I think we over focus on these scary edge cases where some trickster is trying to con their way into the job. The worst case is you just fire them when they are unable to do the work, and that's on them.

Besides, what environment discourages help? I ask friends for help with my job all the time.

The cost of over optimizing for avoiding those false positives (ie: bad candidate marked good) is a huge drop in true positives (ie: good candidate marked good). It's silly.

The problem is once you offer them a job you stop searching for a candidate. Then you get a bad hire and even if it's quick you won't really know for a while, so then you're really behind.

It's bad enough when you hire someone who really wasn't qualified but didn't do anything bad. Now you have to get rid of someone who probably left a previous position and, like above, you have to go get someone to do the job you were hiring for in the first place. Worst of all possible worlds.

Perhaps the calculus is different in a big company, but for a startup your approach sounds pretty bad.

I believe that the existing system intends to optimize heavily for "reject bad candidates" and actually fails at that too.

Give candidates a take home, then review it with them.

I have a lot of reasons for believing this approach would be far superior to the "sit in a room and get interrogated for 7 hours" approach.

This sounds like a contradiction to me. How are you defining "unqualified" and "bad" here?

The whole reason for the long hiring process is that firing is hard (legally, financially, emotionally). If you're willing to dismiss this difficulty, you're assuming away the core problem.

All that BS about it being hard financially or legally? Not true. At all. It's just an excuse startups use because they don't understand basic HR functions. And that's why every company of a reasonable size (i.e., more than a few dozen people) has an HR department, even if it's just one person. Because they know how to do this stuff.

After all, managing hiring and firing are literally the primary reasons HR departments exist in every company making more than a few million $/year. Especially the profitable ones.

Whether or not you’re talking about Silicon Valley, you’ve endorsed a much stronger claim, that such measures are pointless because firing is just so easy.

If you’re not ready to defend that claim, then maybe you should walk back on your original. Or at least show some some sign that you recognize things aren’t as easy or simple as your original blithe dismissal implies.

Remember, you didn’t even think the emotional side merited an acknowledgement.

Not really. It's just harder to hire again usually than figure out how to coerce the problem you have already to be less of a problem. That's the nature of the market right now.

If developers were easy to find and hire then they would be getting fired left and right like happens with just about any other commodity job.

And severance pay is not a thing for most employees, just the ones, like programmers, that have fairly cushy white collar jobs.

You need to stop seeing everything through a rose-tinted SV lens and look at it the way the rest of the country does. I'm ready to defend my claims. Are you?

What everyone else does is completely irrelevant.

In the programming world, specifically, which is what we are talking about, firing is extremely costly.

This is proved by what companies in the programming world are doing right now.

If you disagree, then you are disagreeing with basically every major tech company in the world. And personal, my bet on who is right would be those tech companies, not you.

And when they do, it's standard practice to require that relocation and signing bonuses be repaid if the employee resigns or is terminated within a certain time frame after joining the company.

I work pretty regularly with HR. Do you?

Not only have I worked at a bunch of different companies, but I have also straight up failed at some of the earlier jobs, and have been in situations where I absolutely deserved to be fired, yet it took literally months for anyone to even approach the topic of my performance.

I am talking, situations of me not doing any work, for months, because I didn't care and was looking for new jobs during that time period.

My experience has shown to me that engineers are pretty damn untouchable. And yes, these have been (mid sized) startups.

The one time I had a reloc bonus, of a job that I left after 5 months, they did not ask for it back, and simply never talked to me again.

It is not about signing bonuses though. It is mostly about things like bad Glassdoor reviews. Many engineers would never ever work at a company where the engineers were constantly terrified of, and complaing about being fired quickly.

Also, disgruntled ex employees are something that you don't ever want to deal with.

How many people can truly, reliably, "fake" their way through a take home? How many people could then do an in person code review and fake their way through that as well?

I doubt it's that many, but you'll get way better returns on good candidates, in my opinion.

I've encountered programmers who know their stuff, can talk about it intelligently and knowledgeably, but cannot write code worth spit. It's not as rare as you might think. It's sort of like someone with an art degree who has no talent for actually painting.

If someone is in a protected class and they get fired within the first week, does anyone really think they'll win a lawsuit alleging discrimination? Does anyone actually think they'd get beyond a motion to dismiss (usually the first motion filed by a defendant)? If the employer was discriminating against protected classes they wouldn't have hired the employee in the first place. These types of claims are quickly dismissed and usually incur minimal legal fees.

I'm not sure I see how someone is going to: a) Write a take home project b) Explain their design decisions, respond to code review, etc, in person

and somehow not be able to "write code worth spit" or otherwise game the system consistently.

edit: Would love to hear (in the US) where that 100k comes from. At-will state means I can fire you for whatever reason, can't imagine it really comes close to 100k tbh.

If you're paying a new-hire-fast-fire more than the salary due to them for the period worked (and any other amounts listed in their offer letter, if one existed), then you need to talk to a labor lawyer because you're definitely doing something wrong...unless you're paying them to shut up about the experience.

1. relocation expenses

2. starting bonus

3. headhunter fees

4. severance pay

5. COBRA

6. it can take a while to determine they're incompetent if they're good at the facade

7. if they're in a protected class, you have to go through a period (often 6 months or more) of documenting their incompetence and leaving a trail of trying to help them improve

8. firing someone always comes with it the risk of a lawsuit, and meritless lawsuits are commonplace, but they still cost a LOT of money to defend.

9. disruption to your team, scheduling slippage, having to allocate someone else to fix the incompetent work, etc.

5. COBRA is paid by the employee, not the employer.

6. Somehow every other industry except programming manages to do this just fine.

7. This is completely and utterly false. If a new hire doesn't work out you can just let them go. Somehow, companies do this all the time without issues, including companies with much cushier jobs than startups.

8. Everything comes with the risk of a lawsuit. You're prematurely optimizing for the 0.0001% case, for an imagined scenario that isn't that expensive to defend.

9. Most of these apply to leaving the position open for months without filling. So let me add one to your list that applies if you don't fill the job: employee burnout leaving to existing employees leaving before the open position is filled, leaving you with more positions to fill than you started with.

Retention bonuses and starting bonuses are structured the same, you sign an agreement to get that bonus that says you pay it back if either you or the company decides to end employment within a certain timeframe.

Unless this is a contracted for benefit, this isn't a separate cost from lawsuit risk, but a mitigation of lawsuit risk: severance pay is paid to people on condition of waiving claims.

> if they're in a protected class

If you start a sentence this way, it's a clear sign you don't know what you are talking about. Except for a few special cases (“age over 40” and “veteran status”), every employment protected class is a dimension on which discrimination against any value is equally restricted, and everyone has some value on each axis (race, sex, etc.)

So, everyone is “in a protected class”. Well, several of them, actually.

> you have to go through a period (often 6 months or more) of documenting their incompetence and leaving a trail of trying to help them improve

No, you don’t, and you can’t really count this “requirement” and lawsuit risk as separate costs, since this is simply a policy companies adopt to mitigate lawsuit risk.

Mitigating lawsuit risks is costly.

It certainly has a cost, but it's part of the cost of lawsuit risk, not a separate, additional cost.

And I said earlier I maintain that my method of interviewing will actually reduce those costs.

If you sell your house, you pay a 6% commission on closing. If you reject the offer, there is no closing, and you don't owe the commission. Because the house didn't sell. If you sell the house, you can't sell it again unless you're committing fraud...But assuming you meant you find another buyer, and successfully close with the second buyer, you would then owe a single 6% commission to your real estate broker, not two 6% commissions.

This is also not how recruitment bonuses work, and I say that as someone that works closely with HR on the tax/legal side of things.

If you pay a recruiter a recruitment bonus, their recruited employee has to remain with the company for X amount of time (aka "trial period"). Usually at least 3 months, but it varies. Once that happens, the bonus "vests" and is due to the recruiter. (Many recruiters will try to get paid before the trial period ends, but you don't actually have to pay them yet.) If you terminate the employee before the trial period ends, the recruiter is not owed a recruitment bonus. These are all standard provisions for recruitment contracts involving 3rd party recruiters. (Note: this is for the contract with the recruiter, not the recruitment employee. The employee's employment contract, if any, may not include any language about a trial period.)

Of course, it's very possible for a startup without an HR department to leave out the trial period language from their recruiter contracts. Because they didn't know any better because they didn't think that HR personnel provided useful functions. Now you know why HR departments exist.

I understand, it isn't intuitive. I hope my analogy of someone well trained in art, yet still can't paint worth a damn, makes sense.

Or pilots who ace all the pre-flight training, yet simply are too uncoordinated to fly well. (That's me. I know all about flying, yet should never be in the pilot's seat.)

Some people are just unable to synthesis good code out of all their knowledge.

Good question. Like I said elsewhere in this thread, there are many people who are knowledgeable and intelligent about coding, but cannot code. They are different skills. I've met many people like this.

I could study Romeo+Juliet and know everything about it that lit professors know. But I could never write it.

For another example, from my time at Boeing, the engineers were divided into two independent groups. One group designed, the other group analyzed and checked the designs. They were different skills, and the engineers would gravitate to whichever path best suited them.

FAANG companies have this problem: when you hire thousands of people a year, a higher false-positive rate is a big deal.

When you are startupbro.com, you don’t have this problem, but you’re desperately cargo-culting your way to success, and doing anything in a way that goes against the grain causes the other bros to accuse you of “bad signaling”.

See also: why tech companies cram together in San Francisco.

My friend's employer is currently hiring thousands of people a year with a single interview lasting 1-2 hours without problems. Some highly technical and some manual laborers.

Then do this by putting new employees on a probationary period for the first six months. Many of their employees are union, and it still works out, the unions agree to this arrangement.

How is it that, simultaneously, firing is hard and job security sucks?

Ask about the code. Ask about the thought process. Ask how to debug it. Ask how to change it or improve it. Put one of the company's team members with them and pair code for half an hour. Find a bug or two and fix it.

There's no lack of questions to confirm if someone did the work themselves. This is easy to figure out once you have working code in front of everyone.

Had other candidates totally ace the take home and flat out state first thing that they can't code and ask to switch to a non coding interview or to go home.

Some people spend a lot of time practicing to cheat. Given how much this industry pays it shouldn't be surprising.

Both of these happened 3 weeks ago when I was interviewing 32 candidates in a event. But several times in the last few years as well.

No I don't have statistics on this or pure confirmation... Kinda hard to get that info from suspected cheaters.

There are problems with every type of interviews a d they're hueristics for skill not a judge of skill.

I would love to meet someone who was at ease, could explain code in detail (including talking about looping over arrays) and then NOT be able to produce that code.

The second one flat out cheated, but I bet they wouldn't have been able to explain the take home so you might have caught them.

Kinda weak speculation on my part but I guess I could be wrong. I've literally never met anyone like that.

What is the take home like? Maybe the code/answers have leaked somewhere?

The first one could also explain the code fine. Interviews 2 and 3 they were comfortable and able to design decent systems but fell over on code. This why I was given the task of "get any code whatsoever after you put them at ease"

What GP describes is more common than you'd think. Not surprising when the prize for cheating is a 6 figure job, and there's no penalty at all for getting caught.

In the gp scenarios they said they were able to Google almost all of the take home and stich the parts together. The overall solution/problem isn't Googleable, we checked.