61–70 of 190 posts
Hardware Reverse Engineer here. Would love to see some more tests geared towards my field. (Either reverse or hardware engineering)
Now take that list, throw it in the rubbish bin and wash your hands thoroughly. Take home challenges are simply an absurd waste of time and a huge disrespect towards your candidates personal time. You ask them to spend 4 or more hour of their free time on a useless, throwaway excersise that you "review" in 5 minutes and you conclude they're good enough because they laid out code the way you like it... You never see t…
I have a big folder on my computer of homeworks I've finished for various companies over the years. If I recall I passed all of them, it's sort of annoying that I can't simply hand over this list of other projects I've passed and say "here, all of these companies thought this was good".
What I like about your proposal is that if many other companies did it, the result would be every few years I should take a month of evenings and build out a cool project for myself demoing my ability to write code. If life gets to busy, it's fine if the project ages a bit.
This way you can scratch a personal itch and prep for interviews all the same time.
Earlier quoted context omitted.
If I set a take-home test designed to take two hours, and then very clearly tell the candidate to take two hours, and then they clearly spent way longer than that, then I will consider that a signal that they don’t follow instructions well and don’t value their time appropriately.
How do you know they clearly took over two hours? We love talking about productivity here. You're telling me employers will systematically fail the candidates who performed most productively in their process, because of a speculation they took too much time?
Any candidate capable of actually inventing a time machine should certainly be hired.
Earlier quoted context omitted.
How do you know they clearly took over two hours? We love talking about productivity here. You're telling me employers will systematically fail the candidates who performed most productively in their process, because of a speculation they took too much time?
And a reasonable response in any case is "Yah, I know you said that but I don't like to do sloppy work and there were clearly a number of different edge cases that needed to be handled for this to work reliably."
I don't want an architecture astronaut who is never going to ship anything.
An 80% solution when I need it is infinitely more useful than a 100% solution that's months late.
But the goal of having a candidate work on a real problem is a good once. IMO a far better approach is to do a live exercise with them. Not a leetcode problem... take an existing codebase and add a feature to it, fix an issue with it, etc. Heck, you don't need them to complete everything, but you just need to get signals on how they approach the task, how they pick up working in an unfamiliar codebase, attention to detail, communication, etc.
Anything to get rid of leetcode interviews that are a collosal waste of everyone's time and lead to awful hires. Over the years there has been a democratization of study material for "coding interviews" which has led to a huge influx of wildly inexperienced/unqualified candidates. It also means if you want to hop to another company, you have to waste months grinding leetcode problems completely irrelevant to anything you'll ever do.
Earlier quoted context omitted.
While this certainly sounds like reasonable criteria for rating a take home, does this truly account for general candidate reluctance to do take homes due to the time commitment? Even 2-4 hours is more time than conventional Leetcode-style initial assessments, and many may rather use that time to interview with 2-4 companies instead of just one. I recently interviewed with Ramp and enjoyed their model of practical pr…
> Even 2-4 hours is more time than conventional Leetcode-style initial assessments, Hard disagree on this one. Unless your day-to-day work includes many leetcode style problems, you need to put in significant time training on leetcode if you want to pass the interview. You should be able to complete a take-home based on your current skill set. Yes, it may take 4-6 hours (or 8-10), and yes, that is a big ask of a cand…
ADDED: I suppose one could argue that the Bar exam is a bit like that but that's a credential as are degrees which are not necessarily all that overlapping with the real world.
Earlier quoted context omitted.
How do you know they clearly took over two hours? We love talking about productivity here. You're telling me employers will systematically fail the candidates who performed most productively in their process, because of a speculation they took too much time?
Well, it's pretty simple if you don't given them the task until they agree they're ready to start, and then record when you receive the submission. Any candidate capable of actually inventing a time machine should certainly be hired.
Also, such a system does not prevent cheating, which is really the worst issue here.
As an interviewer, I believe take home tasks are unfair and also poor return on investment. Take home tasks incentivise candidates to burn as much time as possible on the task. Consequently, they are a test of who is willing to put a week of work even when the instructions say it should not take more than 3 hours to complete. I prefer pair programming with the candidate on the premise that if I ask you to spend 2 hou…
As an interviewer, I believe take home tasks are unfair and also poor return on investment. Take home tasks incentivise candidates to burn as much time as possible on the task. Consequently, they are a test of who is willing to put a week of work even when the instructions say it should not take more than 3 hours to complete. I prefer pair programming with the candidate on the premise that if I ask you to spend 2 hou…
That's the problem. I think everyone is too focused on technical prowess and forgetting something just as important which is written documentation and explanation.
Pair programming has the downside of selecting people with good interpersonal skills and will tell you nothing about quality of code delivered.
A good middle ground I believe is simple takehome tasks with focus on documentation that could be done in no more than two to four afternoons.