371–380 of 493 posts
Aside from all the comments saying that coding challenges aren’t as unrealistic as you think, there’s also the fact that there seems to be an oversupply of good enough coders for some roles so companies need to filter beyond that. Yeah inclusive environments etc is a nice to have but if you can get a top level coder that can solve problems quickly and not crumble under time pressure, even better. Why settle for good…
> When was the last time you had to debug an ancient codebase without documentation or help from a team? > This is like asking a Ruby developer to debug PHP as a test of flexibility > If the job requires specific tech skills, test those skills Sounds like someone failed a coding challenge. In all seriousness, you need to understand that companies rarely implement their hiring practices for the sake of it. It is usual…
> In all seriousness, you need to understand that companies rarely implement their hiring practices for the sake of it. It is usually the best their collective minds could come up with. Unlikely. It's usually what the most senior person either read about or experienced in the past. In fact I'd say that it is highly unlikely that they did any introspection at all as to what they are actually trying to accomplish. They…
Based on the observations I've made of hiring managers I've worked with, what they're trying to accomplish is to provide the appearance to HR that they at least attempted an unbiased hiring process. The result often resembles a "literacy test" and I suspect one has to be very intentional about avoiding that to practically avoid it.
- Use probability as your advantage. Or put it another way, perseverance works. Do recognize that interviewing is a hit-and-miss game. Say with your preparation your chance of getting into any of your top 10 companies is 30% -- a pretty low number just for us to steelman argument. Let's say you can try each companies three times a year (most companies have cool-down period per department instead of per company). Then in 5 years, you can try 30 times. The probability of failing all of them is 0.3^30 ~ 10^-16. That is, practically, zero. Of course, this assumes that each attempt is independent of each other, and we can maximize such assumption by keeping learning the lessons of failures. By the way, this is also a reason why one can see so many so-so engineers in a big companies.
- Do not cram all of the leetcode questions. That's insane. Remember the quote from Invincibles: "when everyone is a superhero, nobody will be"? It applies to cramming too. Instead, use the time to study fundamentals. Pick up Kleinberg's Algorithm Design, Levitin's Introduction to the Design and Analysis of Algorithms, or Skiena's The Algorithm Design Manual. Note these books are not that academic. They all focus on the process of designing an algorithm from constraints and basic principles.
- Do not worry about Leetcode Hard. Yes they will be asked from time to time by an interviewer, but see my suggestion #1. If you really want to try Leetcode Hard, at least ignore the ones that require deep ad-hoc analysis or the ones that require an aha-moment. They are talent filters or memory filters or obedience filters, but they won't improve your engineering expertise. Then, why bother? And trust me, it is actually rare for you to get a Leetcode Hard question.
Earlier quoted context omitted.
A moderately smart person was selected for a good job perhaps over many many better possible hires simply because that person had the leisure to learn the game. Inefficient. But nice for that individual, naturally.
Since when is studying, practicing and preparing, gaming the system? Is reading a book on software engineering to become a better programmer also not allowed? I feel like people want these jobs to be distributed "fairly" based on "natural" ability/talent. But it has never and will never work that way.
Fair question.. the problem today is the emphasis on studying and practicing irrelevant things like memorizing algorithms. That's become the paved short-cut to well paying jobs so naturally people do it. To the point that even the people doing the hiring have forgotten what it meant to be actually qualified, not just a leetcode memorizer.
If you need to hire a musician for your band, do you pick the person who has spent six months practicing a handful of chords to perfection, but possibly doesn't know anything about composing songs or jamming with the band? Or do you pick someone who has been composing and playing live shows for 10+ years?
The first one is just academic memorization that has some value, but very little. The second one is real-life experience that's worth a lot.
I have zero musical skills but even I have managed to learn to play a couple songs on the piano by sheer memorization of which buttons to press in what sequence. If you ask me to play one of those songs it might seem like I know what I'm doing even though I'm completely incompetent in music. That's the equivalent of hiring for software roles based on leetcode memorization.
Earlier quoted context omitted.
Interviewing is a time investment for both sides. Should the company charge you to evaluate your skills?
If someone gives me a take-home assignment that I spend 4 hours on, there is no commitment of time on their side. They may decide to not even look at the results. They may spend five minutes on it. That's exactly my problem with take-home code challenges. If I go to an interview, and they waste my time, they have to waste their own. But with a take-home assignment, they can waste my time without wasting their own. Th…
- The candidate needs to do lots of work while the company gets away with little to none. - The candidate never knows what exactly the other side will be looking for, so the only way is to put in more work. Like when the assignment didn't ask for tests, they might still be expecting them. - The candidate usually gets no feedback about the work he did. More importantly he usually doesn't get a chance to defend his solution. It's either great or garbage. - While the company can learn something about the candidate, the candidate will learn nothing about the company by doing the assignment.
Earlier quoted context omitted.
What would you waste your time with? I exclusively give pairing interviews, usually just 1 hr. The variance between good and bad candidates is amazing, and you wouldn't guess at all from resumes or casual conversations. Most candidates have given me very positive feedback. Why wouldn't you want to be interviewed like this?
I'm a senior developer. Of course I know how to code. Do you know how many code challenges I've done over the course of my career? 99% of them where terrible at evaluating my ability to code. They are a waste of time at the senior level. You are much better off with a conversation, looking at past work and experience and references than you are doing code challenges.
The number of people with impressive looking resumes, and good command of the jargon, but who still can't successfully code hello world is shocking.
I don't believe you (general you, not just the parent) can even code until you demonstrate that to me, or until the industry comes up with a reputable way to tell me that you can code. Until then I'll be making sure you can at least write code that compiles and finishes a brain-dead simple task.
Earlier quoted context omitted.
Sounds like the system worked exactly as intended then. A seemingly smart person got a good job. What's the problem with this story exactly?
It’s like the bar exam for lawyers. It bears absolutely no relationship whatsoever to the actual job and the work you will be doing. It’s a pointless ritual. And the point of the above story is that the person performed the ritual and then promptly forgot all the words once they succeeded. It illustrates the pointlessness.
At least lawyers don't have to take the bar every other year for the rest of their careers.
I recently ran an interview process for a relatively senior eng role at a tiny startup. Because I believe different interview methods work better for different people, I offered everyone a choice: 1. Do a takehome test, targeted to take about 4 hours but with no actual time limit. This was a non-algorithmic project that was just a stripped-down version of what I'd spent the last month on in actual work. 2. Do an onsi…
> ~90-95% of candidates chose the takehome test I was expecting "3. submit a code sample" to be the overwhelming winner here - did anybody choose that? Seems like a no-brainer, since it's already done...