Stop Interviewing with Leet Code
1–10 of 675 posts
Re: Stop Interviewing with Leet Code
#2I've decided I'm going to start interviewing with a set of PR's per each role we hire for. each PR will have obvious mistakes, complicated logic problems, as well as code that could be "refactored" once the whole PR has been read.
this provides a few things; it gives us an ability at how the interviewee problem solves. next we can see how they respond too obvious fixes (would they be someone you'd want to send a PR too?). finally, it tests their knowledge of the language and APIs, hopefully much better than Leet Code can. I would also like to see if the user can spot obvious bugs in the setup code (say, package.json, pyproject.toml, etc)
I am going to make an example PR for: - frontend (React/NextJS, TypeScript, CSS) - backend (Django, Python) - DevOps (potentially some Pulumi code for deploying to a Kubernetes cluster?)
Re: Stop Interviewing with Leet Code
#3> Alternatively, look at under-performing people and find what they are lacking
This is great suggestion. While the “look at their github” one is a bad suggestion. Github polishing is theatre more suited for theatre majors instead of people actually working with integrity before coming to your company. Its very similar to the issue with the leetcode interviews as its geared towards people with time to optimize that instead of a day to day job.
Re: Stop Interviewing with Leet Code
#4I've decided I'm going to start interviewing with a set of PR's per each role we hire for. each PR will have obvious mistakes, complicated logic problems, as well as code that could be "refactored" once the whole PR has been read. this provides a few things; it gives us an ability at how the interviewee problem solves. next we can see how they respond too obvious fixes (would they be someone you'd want to send a PR t…
I think there are flaws with this approach too, but I wish this approach was more common so that there was industry wide rapid iteration to a more optimized version of this.
What I’ve seen are time trials, which don’t show you how well a candidate will adapt to a codebase, wont show you how they will do tickets for your sprint. Only reinforces a flawed idea of the employer about how they wont “hit the ground running” despite having that job opening for 8 months.
What you described might not be a time trial, its what ive seen though.
Re: Stop Interviewing with Leet Code
#5Right now, I get bombarded with headhunter requests, if you are going to ask me to leet code, my inbox is full of alternatives.
Leet Code is only cargo culted because many candidates let it happen.
Re: Stop Interviewing with Leet Code
#6> Alternatively, look at under-performing people and find what they are lacking This is great suggestion. While the “look at their github” one is a bad suggestion. Github polishing is theatre more suited for theatre majors instead of people actually working with integrity before coming to your company. Its very similar to the issue with the leetcode interviews as its geared towards people with time to optimize that i…
A software engineer should tell easily whether or not one’s GitHub is authentic by looking at commit history, ownership of repo etc…
Re: Stop Interviewing with Leet Code
#7> Alternatively, look at under-performing people and find what they are lacking This is great suggestion. While the “look at their github” one is a bad suggestion. Github polishing is theatre more suited for theatre majors instead of people actually working with integrity before coming to your company. Its very similar to the issue with the leetcode interviews as its geared towards people with time to optimize that i…
A software engineer should tell easily whether or not one’s GitHub is authentic by looking at commit history, ownership of repo etc…
Oh you focused on the “polishing” and not the “there’s nothing to show” part
People good at their jobs because they do their job: nothing on github
People in the business of performance theatre because they dont have a job to be good at: plenty on github. It can be legit code they wrote, that was not the point at all.
Re: Stop Interviewing with Leet Code
#8Earlier quoted context omitted.
A software engineer should tell easily whether or not one’s GitHub is authentic by looking at commit history, ownership of repo etc…
Oh you focused on the “polishing” and not the “there’s nothing to show” part People good at their jobs because they do their job: nothing on github People in the business of performance theatre because they dont have a job to be good at: plenty on github. It can be legit code they wrote, that was not the point at all.
I half agree with this.
I don't like the idea that every developer has to have code on github. If they want to code for work and nothing more, then that's fine and shouldn't disqualify them from any jobs. We shouldn't expect people to spend years of employment building up a portfolio for the next time they're looking for a job.
However, I don't see how looking at the code people write isn't informative. You can see many things, from small-scale code style decisions to how they structure an application just from looking through their github profile.
Writing code isn't a performance, it's literally what you want to pay them for.
Re: Stop Interviewing with Leet Code
#9Earlier quoted context omitted.
A software engineer should tell easily whether or not one’s GitHub is authentic by looking at commit history, ownership of repo etc…
Oh you focused on the “polishing” and not the “there’s nothing to show” part People good at their jobs because they do their job: nothing on github People in the business of performance theatre because they dont have a job to be good at: plenty on github. It can be legit code they wrote, that was not the point at all.
> People good at their jobs because they do their job: nothing on github
Even better if they have both, worked on open-source projects or have created useful open-source software used by other companies and are already working in their other job(s) or have personal real-world projects they can point to; which those are clear advantages and a simple quick filter to use.
No need to ask about frivolous leetcode questions around re-implementing sorting algorithms or wasting more time asking the candidate to write proofs for those algorithms where realistically you're going to just import it from a library or look up the solution on StackOverflow.
Unless you're Google, a FAAMNG company, university or general research related position or if the position isn't for a typical CRUD application development, then there is little to no justification for wasting everyone's time on pointless leet-code puzzles and this applies to the majority of companies.
Re: Stop Interviewing with Leet Code
#10I've decided I'm going to start interviewing with a set of PR's per each role we hire for. each PR will have obvious mistakes, complicated logic problems, as well as code that could be "refactored" once the whole PR has been read. this provides a few things; it gives us an ability at how the interviewee problem solves. next we can see how they respond too obvious fixes (would they be someone you'd want to send a PR t…
Although this is better than leet code, PRs have been shown to be a poor way to prevent bugs. I find they are mostly useful for disseminating knowledge.