Its not that simple. If somenone wanted you wouldn't even know that. Besides - IMO for the hopper it is also not easy - changing colleagues, earning respect again etc. OTOH, whatever one says - the goal of the job is to get paid and support your familly. That gets especially important when you have kids.
We do background checks, so hopefully we're not actually hiring people who tell big lies on their resumes.
> IMO for the hopper it is also not easy
I agree. I'm changing jobs soon and have some apprehension for the reasons you mention, plus don't forget the fear of underperforming and being deported for losing my job :/
> the goal of the job is to get paid and support your family
Parents and people who pass the vibe check get strong yeses from me so no issue there /s
But in all seriousness I do feel really bad when interviewing parents or anyone with other obligations that stop them from grinding practice questions if I have to fail them because they can't solve some BS leetcode question. Unfortunately my intuition if someone is a good engineer or not doesn't matter much if they can't crank out some leetcodes in 35 minutes :/
The signal for who is a good developer is so unbelievably low for a leetcode interview. I do feel like some codebases have been made unmaintainable because of the "fail fast, break often" mentality that I feel like is taking over things. In the interviews I give I touch on many other aspects of code design, testing, and review especially for senior candidates.
Obviously its not bad enough yet to warrant changing the process though at top companies, so maybe I'm the one who is interviewing in the wrong ways.
What I’m seeing is that some big tech companies these days (including my own) have standardized rubrics [1] for leetcode-style questions that focus on a few areas (like DS&A, communication and coding style) so I can’t really give any marks for these other positive behaviours.
There’s some benefits to rubrics (reduces differences between interviewers and is more fair to minority candidates from what I’ve seen) but I’m it definitely impacts or senior hiring.
Unfortunately there are also so many experienced developers in the hiring pipeline who actually can’t code, so doing at least one coding interview seems inevitable. I’d give less “tricky” questions but, like rubrics, the questions are standardized too :/
I do give coding exercises in my interviews, but they’re usually more open ended and don’t require understanding tricks. If there’s a DS&A portion it’s usually something I’d expect to be used on the job (e.g. a map or array list, not a BST). I also touch on things like SQL and API design. These things feel like they’re hardly hit on in most tech interviews.
Code review is mostly to think long term about code (as tests catch the immediate stuff). I have no long term future at the company, so oh well.