Comment by rootusrootus
3 years ago
I definitely think "we do not do leetcode interviews" and maybe "we only have three interviews total" would be selling points on a job posting. People who are experienced in the field don't want to go through the same hoops that newbies do just to prove they know how to write basic algorithms.
You wrote: <<People who are experienced in the field don't want to go through the same hoops that newbies do just to prove they know how to write basic algorithms.>>
I am constantly interviewing candidates for roles at my company. It seems like CVs are a complete gamble. Either some are lies, or wildy understated, and everything in between -- at all levels of experience! "[J]ust to prove..." and yet so many can not do the 2022 version of FizzBuzz. I am stunned how many senior (well, so they say!) hands-on technical applicants cannot do basic things like write a very simple linked list class, or explain to me how a hash map works. For get about explaining the finer points of sorting algorithms (honestly, very low value in my line of work).
There is no reasonable alternative to testing of some kind for hands-on techincal roles -- I am flexible about method: (1) white board coding (ugh in 2022), (2) IDE/text editor on shared PC / video chat (meh / eh in 2022), or (3) take home (the best in 2022, even if there are drawbacks for people with families).
Joel Spolsky said it best about hiring: The goal is to avoid bad hires. Average and above are fine.
...explain to me how a hash map works. For get about explaining the finer points of sorting algorithms
I've been in software development for 15 years and being able to explain either of these things has never come up and I probably wouldn't be able to give a decent answer without reviewing the topics specifically.
Yes, companies are hiring for competency not tenure or years of life lived while holding job. If you want the latter, I have heard it is more structured that way in Japan and much of Europe.
I would expect most people I hire to be able to explain how a hash map works.
14 replies →
I concede it may just be that I've been lucky, but when interviewing experienced candidates I've never really had any problem judging their competency just from discussing their past work. A little bit of back-and-forth deep dive into the technology has always exposed people who are shallower than their CV would have you believe.
What has burned me, however, cannot be tested adequately in an interview. Bad attitude and laziness. Anyone can behave well in interviews, so we've hired a few people who turned out to have a passive aggressive streak or condescending attitude that interferes with the rest of the team. We've also hired people who are really great developers ... when they work. But they're really lazy and getting them interested enough to do the work is the hard part.
Hiring is hard. I doubt I need to tell you that. There is a reason we gravitate towards hiring people we've worked with in the past, or come recommended by someone we trust.
I've had the same experience. Everyone wants you to "just look at their resume". Meanwhile, I've interviewed plenty of people with great resumes who can't solve a simple problem like reversing a string [1].
If you can point me to extensive open-source experience on projects that roughly approximate professional coding, then fine, I'd be happy to walk through your code with you instead of doing an algorithmic problem. The issue is that that's a minority of developers... most people don't have the time or desire to do extensive open-source work outside of work hours and I don't blame them for it [2]! But given that resumes are unreliable, I need to test you somehow.
[1] No, I don't ever have to reverse strings at work. But I do have to write efficient code. And if you can't conceptualize how to reverse a string then you probably won't stand a chance at more difficult algorithmic issues I often come across.
[2] I don't recall who it was, but I once heard a very well-regarded chef say that he's tired after work and so he doesn't like to cook much at home. I have zero problem with a developer doing the same with coding! Go home and work on a hobby, spend time with your family, or smoke pot and watch netflix... I care about what you are capable of at work, not what you do with your free time.
>technical applicants cannot do basic things like write a very simple linked list class, or explain to me how a hash map works
In my experience people know these things, they just don't realize that what they're doing can be described generically.
An example: If you're in an iOS interview and ask the person to describe a graph, they will get very angry and complain that this is useless knowledge and they don't need it to get the job. But if you ask the same person to describe an UIView hierarchy, they often have no problem doing so. So they _know_ what a graph is, they just didn't know it had that name.
With that in mind, my tests shows that generic algorithm questions suck and questions themed around actual features of the product are the best. If you word the question in a way that feels relevant and is familiar to developers, they will be more likely to know the answer even if deep down the solution is exactly the same as the generic ones.
Personally I do because I enjoy working with very smart people.
The backlash against leetcode is the same as backlash against other types of tests: most people are going to fail and most people don't like failing, so they blame the test.
leetcode == smart ? oO that's new
I interview many candidates at FAANG, I can easily tell the ones that have prep by just doing leetcode and the ones that knows the shit.
I couldn't care less if you can solve all kinds of complex dynamic programming challenges.
I ask coding questions that you won't find in leetcode and requires problem solving skill and good craft.
And this is because I do like working with smart people and not with people good at memorizing patterns.
I consider solving technical challenges in interview the "LC style" interview as compared with talking about your past experience or language trivia grab bag. I am not saying literally ask questions found on leetcode.com
I think it is easier to know the shit to do LC interviews than somehow memorizing the question bank. I haven't seen many people succeed who were unskilled but managed to just memorize the questions.
2 replies →
I like this kind of answer. You are trying to be the leetcode alternative, which I fully support. I have previously written on HN about my most common interview programming question: "Please implement the classic C function atoi() in any language of your choice. Do not use built-in string-to-number functions." This question has a lot of edge cases, but it is simple enough to program on whiteboard, paper, text editor, weird-IDE-that-I-never-used-before-this-interview(!). The questions that people ask and how they explain their solution says a lot about them as engineers.
1 reply →
The backlash is the same as the one against standardized testing methods in school. People that don’t fit the mold of the testing method will fail regardless of how competent they are at their actual job.
It’s good you like that I suppose, but it sounds absolutely bonkers to me.
> don’t fit the mold of the testing method will fail regardless of how competent they are at their actual job.
The mold being answering questions about their supposed area of expertise.
I think people really like to claim that they are misunderstood geniuses who just don't fit the mold of being able to answer questions about the things they know. I have no doubt that such people exist, but I would not want to scrap an evaluation system simply because it doesn't catch every possible person, more important to me is keeping bad people out.
5 replies →
I guess Sergey and Larry weren't "smart" then because they never went through a leetcode interview.
If you think what I just said implies what you just said, then you are the type of person I would not want to work with.
> "we do not do leetcode interviews" and maybe "we only have three interviews total" would be selling points on a job posting.
It depends on the job. I have had interviews that broke the mold here and were panel discussions or more job-talk experience, and I found the interviews uniquely exhausting because they required their own set of skills to study for that were different from the “leet code” style. At the extreme end were the take home projects, which I simply didn’t have time to do for every company and were extremely unattractive to me for that reason. I actually find doing leetcode style interviews for me required the least amount of prep and was the most straightforward, especially when they were structured to leave me with time to ask and talk to real engineers at the company.
Three interviews is now an "only"? Man this industry is fucked.
Basic algorithms? FAANG algorithm questions are usually far from basic.
http://they.whiteboarded.me/companies-that-dont-whiteboard.h...
I am not sure if this is kept up to date. I did interview at DoorDash and they definitely do leetcode style interview.