Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> 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.

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.



I was worried about that for senior candidates, and if I had a good recommendation or had some sort of screen call with them I’d usually skip the takehome.

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.


> 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.


Thanks for your candor, I generally had this sense. If we had something like, “we usually ask for a take-home but a pointer to a code sample you’d be willing to discuss will work.” Would that be acceptable?

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?


I think in general all of these things just start to come off as dishonest, when senior engineers think about what makes them feel "senior," or what they respect and value in "senior" colleagues.

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?


That's all very fair. The Q I usually ask of all candidates onsite is a design, "give-me-pseudocode/prototypes/class outlines" question which I find infinitely more useful in probing how someone thinks than whiteboard algorithm/coding qs. And to be clear, I wouldn't want to see BS code, but if someone had contributed to an open source project or had some sort of side project that they would have done anyway, that would have been useful.

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.


> In short, to insist on take-home tasks in this market is to give up on your strongest candidates.

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.


I encourage you to actually read the thread before commenting.

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


Honestly it's annoying and does not tell that much. We recruted once a guy that passed algorithm tests on site. We had to fire him 9 month later. He wasn't abble to handle code he had not written and was disappearing every time there was a production issue. Tottally unreliable.


If I'm doing homework I expect an office visit. And pizza, or lunch, or something. I expect to be a serious candidate.

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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: