Contrast it to giving a candidate some slightly broken code in a framework related to the role and then asking them to a)fix it and b)implement a new feature of their choosing and document it.
The advantages of the latter approach:
* The interviewer doesn't need to prep beforehand as they already know both the problem and the codebase. This means they can ask much more interesting questions and don't have to invest significant time in reviewing a project that might be in a field in which they have no experience. This in turn leads to better discussions which in turn leads to better interviews.
* The candidate is given a much tighter problem definition and isn't required to come up with something a)novel, b)not covered by their current employer's NDAs.
* The candidate's time is respected because they can be told how long it should take them up front.
* Each candidate gets a standardised problem and so it's easier to compare between them.
When I give take-home assignments, I'm just looking to quickly confirm that someone has a working home dev environment (i.e. they don't just code inside environments that other people give to them) and that they can understand a small codebase and write clean code and document it. Everything beyond that I can find out by talking to them during the interview.
When I actually used this technique in interviews it was interesting to see how many supposed senior engineers would reply with things like "I'm getting a %JAVA_HOME NOT FOUND error, please can you fix the repo and let me know when it's ready for me to work on?".
The test is intentionally designed to filter out candidates who cannot meet or do not want to meet the technical requirements.
Yeah, no, nobody is or should be giving you their own personal work. It's offensive and probably illegal that you'd even ask.
> The novelty and creativity of your submission
Yeah, no.
"Passion projects" in my "spare time"... maybe once the kids have grown up and flown the nest...
Leetcode is easy... I memorise a bunch of stuff, do the dance and pass the interview. If i'm lucky I get a problem i've not seen before and actually have to use my brain during the interview.
I took a look at leetcode when I was interviewing and decided it was a waste of time for me to learn that dance. I was happy with my chances with the companies that didn’t use it in their interviews. And it worked out fine.
Side projects will help you learn useful skills and it is the suggestion of OP that it should be used by more companies in place of leetcode interviews.
Btw, a lot of companies don’t use leetcode for hiring. In my last job hunting season, I would guess than less than 20% of processes used leetcode. Pretty far from “most” companies.
The leetcode dance is, at least for me at this point, much lower effort than starting a side project on the understanding the code I produce will be reviewed during interviews. It's like Sudoku, once you've done a "few", you get to the point where you're able to solve them quickly.
The nice thing about leetcode it is easy to bound the time to what you can handle. I do one puzzle a week and set a timer for 20 minutes. Then I get the answer and browse the forum. It's basically the equivalent of solving the Sunday crossword for me, and it keeps my algorithm skills sharp. Probably no worse than burning a lunch hour on HN.
True, but would your employer care (if they found out) if you copy/pasted a small portion of code that’s not considered critical IP (like util functions, and an integration syncing records from your backend the Salesforce, or something tangential to the business outside the core product)
May technically be breaking your employment agreement, but I can’t imagine it would be too hard to pluck out a decent amount of code, and re-write portions of it if necessary to “anonymize” it for interviewing purposes.
Or if you happen to be interviewed by someone like me, my approach is simply “if you can’t show me the code, show me the UI and explain how the backend / frontend works, and a discussion ensues.
Who decides what is "critical IP" and what is not?
This is a terrible advice, and no, you should never copy code from a work project without being pre-authorized to do it.
It's not just common sense, but you also might trip up over unexpected legal issues (licences etc) that you may not even be aware of.
What? Yes. I expect I'd be in prison for a few years. Your interview approach selects for people who don't follow their NDAs
Sergey Aleynikov went to prison over copying GPL code.
To add some context, my work is in Financial Services, trading systems and whatnot.
The point is to have a conversation about a project that the candidate understands well and is passionate about rather than asking them a bunch of questions that we already know the answers to.
Before the interview we review the code base and try to understand what it’s doing by the documentation provided in the readme. During the interview we get the candidate to demo the project and any questions that came up in our code review we ask at the stage of execution in the project demo. The interview lasts for 2 hours and we’ve had several rounds of candidates put through this process.
Both we as interviewers and the feedback from candidates has been very positive. The interview ends up being a day-to-day normal experience within the team and this really helps us to gauge the team fit. I think this helps to hire people that compliment and expand our skill set rather than hire people who are basically ourselves.