6 ms·

Having been on both sides of interviewing, I find that the majority of complaints about the status quo seems to come from people that haven't been involved in t

by lhorie 5y ago

Having been on both sides of interviewing, I find that the majority of complaints about the status quo seems to come from people that haven't been involved in the interviewer side that much and consequently simply put forward their personal preference (e.g. some people downthread saying they prefer take home, and then subsequently being countered that take homes aren't ideal for various types of candidates) No offense to anyone, but it strikes me a little bit as armchair expert hot takes saying "why not just X". Personally I think that rather than complaining about leetcode-style loops, it'd be more productive to think in terms of what the problem domain is: namely, many of these companies are typically large and want some level of standardization in the hiring process: you have to contend with things like some ethnicities being culturally prone to "hiring down" to inflate subordinate count, talk-the-talk-but-dont-walk-the-walk types, thinly disguised sexism/ageism/other biases that are excused under the "cultural fit" umbrella, mismatch in terms of desire to provide technical interviewing skills vs volume of candidates, etc. It's easy to attack any one methodology simply because if such a thing as a silver bullet existed, we'd all already be using it. All interview methodologies are flawed, and for better or worse, leetcode-style happens to predominate interview loops because it has a semblance of standardization (though ironically, IMHO a good interviewer ought to be looking between the lines more than seeking specific answers, and a lot of leetcode-style interviewers don't get that nuance) If anything, my two cents is that leetcode ain't going anywhere, so the next best thing we should be focusing on is making it more widespread that memorization culture isn't and shouldn't be the evaluation criteria (this goes both for the interviewer and interviewee sides)

mountainriver 5y ago
Been on the hiring side a lot actually! I prefer to have conversations with people and hire primarily off OSS, it works really great
marcellus23 5y ago
> some ethnicities being culturally prone to "hiring down" to inflate subordinate count Sorry, what? Which ethnicities are these?
- hiptobecubic 5y ago
  You know... those ethnicities. The ones with the culture apparently focused around selfishness and power-seeking... I think answers like the parent are why Google started doing "googliness" interviews.
edmcnulty101 5y ago
Memoization > Memorization
- anthony_romeo 5y ago
  Perhaps personal memoization is a topology on personal memorization?
  - edmcnulty101 5y ago
    I made a bad dynamic programming joke.
pwinnski 5y ago
As a counter-example, I've been on the hiring side many, many, many, many times, more times than I can count, and I despise leetcode-style tests as much as or more than anyone. I've been doing this long enough to know that the things that matter in every job at every company are almost never technical ability. It's skill in managing deadlines, collecting requirements and dealing with changes, divvying up work with teammates, things like that. Things that are difficult to test for, even on a whiteboard. Asking questions about experiences and posing hypotheticals to see what gets candidates interested, or what stories they have to tell, these have been a better predictor of eventual success in my experience than any sort of technical test.
- lhorie 5y ago
  > Things that are difficult to test for, even on a whiteboard Agreed 100%! I'd love to explore scalable ways to test for these. I've heard of people in smaller companies who get lots of success with non-leetcode style interviews because they can either have full control over the interview cycle (e.g. a hands-on CTO) or a still tight-knit "rock star" team that "gets it", but the challenge is that you end up getting a huge amount of variability as a company scales to hundreds or thousands of software engineers and things like rush hiring to meet deadlines start to enter the picture. I like to start my interviews asking people about recent work experience and surprisingly that has been a pretty good indicator of how well they'll do in the technical portion. It's still a bit challenging to evaluate because experience doesn't necessarily correlate with potential. I've had a number of candidates whose description of past day-to-day work was nothing to write home about, but you can see their growth potential by really reading between the lines. Posing hypotheticals is actually relatively standard practice at big tech: it's called the system design session. IMHO, you can get a lot of good signal from these if you do it right.
  - HeyLaughingBoy 5y ago
    The approach we took at my aforementioned $BIG_CO_EMPLOYER was to have multiple interview teams, each focused on particular aspects. e.g., - generic HR chit-chat. Our HR rep was really good at uncovering personality problems (and she was used to dealing with devs :-). Every single person she raised a red flag about also had issues somewhere else in the process and we learned to trust her instincts. - What did you do at your last job and what did you like/hate about it? What code were you most proud of? If I asked you to design a system to do X, what would you need to know, what would you be concerned about? - Basic SE theory: what do you know about SOLID?, what are some concerns when dealing with shared data in a multithreaded design, etc.? - Programming/design exercise with the interviewer as a co-worker/resource. Done on whiteboard, or sheets of paper or whatever candidate is comfortable with. Code does not have to compile, no online access allowed. There were scripted questions at each level (except HR) and the interviewer keeps notes on the candidate response. OK to dive deeper or go off on tangents as needed. At the end of the day, or worst case first thing the next day (so the interview is still fresh in everyone's mind) we'd meet to compare notes & vote thumbs up/down.
itronitron 5y ago
Most, if not all, software engineering roles are highly specialized above and beyond general computer science. I think a lot of complaints about interviewing practices stem from candidates feeling their prior experience, which is directly relevant to the position they applied for, is being ignored and replaced with questions about arcane puzzles.
- lhorie 5y ago
  I think even those on the interviewer side acknowledge that leetcode style questions aren't perfect. I think the biggest misconception is the idea that memorizing the puzzle itself is the hiring criteria, when in reality it's supposed to be thought of as a more elaborate version of fizz buzz. For example, inverting a binary tree isn't about binary trees or data structures, it's more meant to be about whether you understand recursion. It can tie into signals about ability to break down problems into smaller pieces, understanding of memory layout (a proxy for understanding of low level concerns), etc. Ideally one should not need to check an entire barrage of checkboxes perfectly, but enough in some dimension to "prove" they aren't completely clueless about programming, and also not raise a bunch of red flags (e.g. if you tell me you have 10 years Java experience and then struggle with class syntax, that's obviously going to look bad). Ideally there are peripheral questions where one gets the opportunity to display well-roundedness (I like to ask about testing in an open ended fashion, for example). Ideally, an interviewer org ought to take a bit of effort to cater questions to roles/stacks more appropriately. Web folks tends to do this well IME. Unfortunately, many interviewers take coding/algo sessions as an opportunity to do a pissing contest either because they haven't been trained/prepared well or because of some dumb sense that company brand is somehow related to their personal worth or whatever, hence the bad rep.
HeyLaughingBoy 5y ago
This is why the last large organization I worked (at least my group!) settled on pair exercises. We had a known problem set that all candidates had to work and this consistency kept HR happy (although it was an uphill battle to convince HR that it wasn't a "test"). The problem was sized so it would be just barely possible to complete the entire thing in 45 minutes. In fact, I think in all the years we did it, only two people every completed the exercise, and one of those we suspect knew about it ahead of time. However, the problem wasn't a blind "do this on a whiteboard" exercise. We didn't really care whether or not they finished: rather we wanted to see the process they took, the clarifying questions they asked, where they got stuck, how they asked for help, etc. The candidate could choose to work in complete silence, or work with the interviewer as a team exercise, or a mix of both. The point of the exercise was to see if they could (a) program their way out of a wet paper bag and (b) do so in a way that didn't completely alienate the people they would have to work with. Leetcode? Obscure algorithms? We couldn't care less. It was surprisingly effective.

by lhorie 5y ago

mountainriver 5y ago

Been on the hiring side a lot actually! I prefer to have conversations with people and hire primarily off OSS, it works really great

marcellus23 5y ago

> some ethnicities being culturally prone to "hiring down" to inflate subordinate count Sorry, what? Which ethnicities are these?

hiptobecubic 5y ago
You know... those ethnicities. The ones with the culture apparently focused around selfishness and power-seeking... I think answers like the parent are why Google started doing "googliness" interviews.

edmcnulty101 5y ago

Memoization > Memorization

anthony_romeo 5y ago
Perhaps personal memoization is a topology on personal memorization?
- edmcnulty101 5y ago
  I made a bad dynamic programming joke.

pwinnski 5y ago

As a counter-example, I've been on the hiring side many, many, many, many times, more times than I can count, and I despise leetcode-style tests as much as or more than anyone. I've been doing this long enough to know that the things that matter in every job at every company are almost never technical ability. It's skill in managing deadlines, collecting requirements and dealing with changes, divvying up work with teammates, things like that. Things that are difficult to test for, even on a whiteboard. Asking questions about experiences and posing hypotheticals to see what gets candidates interested, or what stories they have to tell, these have been a better predictor of eventual success in my experience than any sort of technical test.

lhorie 5y ago
> Things that are difficult to test for, even on a whiteboard Agreed 100%! I'd love to explore scalable ways to test for these. I've heard of people in smaller companies who get lots of success with non-leetcode style interviews because they can either have full control over the interview cycle (e.g. a hands-on CTO) or a still tight-knit "rock star" team that "gets it", but the challenge is that you end up getting a huge amount of variability as a company scales to hundreds or thousands of software engineers and things like rush hiring to meet deadlines start to enter the picture. I like to start my interviews asking people about recent work experience and surprisingly that has been a pretty good indicator of how well they'll do in the technical portion. It's still a bit challenging to evaluate because experience doesn't necessarily correlate with potential. I've had a number of candidates whose description of past day-to-day work was nothing to write home about, but you can see their growth potential by really reading between the lines. Posing hypotheticals is actually relatively standard practice at big tech: it's called the system design session. IMHO, you can get a lot of good signal from these if you do it right.
- HeyLaughingBoy 5y ago
  The approach we took at my aforementioned $BIG_CO_EMPLOYER was to have multiple interview teams, each focused on particular aspects. e.g., - generic HR chit-chat. Our HR rep was really good at uncovering personality problems (and she was used to dealing with devs :-). Every single person she raised a red flag about also had issues somewhere else in the process and we learned to trust her instincts. - What did you do at your last job and what did you like/hate about it? What code were you most proud of? If I asked you to design a system to do X, what would you need to know, what would you be concerned about? - Basic SE theory: what do you know about SOLID?, what are some concerns when dealing with shared data in a multithreaded design, etc.? - Programming/design exercise with the interviewer as a co-worker/resource. Done on whiteboard, or sheets of paper or whatever candidate is comfortable with. Code does not have to compile, no online access allowed. There were scripted questions at each level (except HR) and the interviewer keeps notes on the candidate response. OK to dive deeper or go off on tangents as needed. At the end of the day, or worst case first thing the next day (so the interview is still fresh in everyone's mind) we'd meet to compare notes & vote thumbs up/down.

itronitron 5y ago

Most, if not all, software engineering roles are highly specialized above and beyond general computer science. I think a lot of complaints about interviewing practices stem from candidates feeling their prior experience, which is directly relevant to the position they applied for, is being ignored and replaced with questions about arcane puzzles.

lhorie 5y ago
I think even those on the interviewer side acknowledge that leetcode style questions aren't perfect. I think the biggest misconception is the idea that memorizing the puzzle itself is the hiring criteria, when in reality it's supposed to be thought of as a more elaborate version of fizz buzz. For example, inverting a binary tree isn't about binary trees or data structures, it's more meant to be about whether you understand recursion. It can tie into signals about ability to break down problems into smaller pieces, understanding of memory layout (a proxy for understanding of low level concerns), etc. Ideally one should not need to check an entire barrage of checkboxes perfectly, but enough in some dimension to "prove" they aren't completely clueless about programming, and also not raise a bunch of red flags (e.g. if you tell me you have 10 years Java experience and then struggle with class syntax, that's obviously going to look bad). Ideally there are peripheral questions where one gets the opportunity to display well-roundedness (I like to ask about testing in an open ended fashion, for example). Ideally, an interviewer org ought to take a bit of effort to cater questions to roles/stacks more appropriately. Web folks tends to do this well IME. Unfortunately, many interviewers take coding/algo sessions as an opportunity to do a pissing contest either because they haven't been trained/prepared well or because of some dumb sense that company brand is somehow related to their personal worth or whatever, hence the bad rep.

HeyLaughingBoy 5y ago

This is why the last large organization I worked (at least my group!) settled on pair exercises. We had a known problem set that all candidates had to work and this consistency kept HR happy (although it was an uphill battle to convince HR that it wasn't a "test"). The problem was sized so it would be just barely possible to complete the entire thing in 45 minutes. In fact, I think in all the years we did it, only two people every completed the exercise, and one of those we suspect knew about it ahead of time. However, the problem wasn't a blind "do this on a whiteboard" exercise. We didn't really care whether or not they finished: rather we wanted to see the process they took, the clarifying questions they asked, where they got stuck, how they asked for help, etc. The candidate could choose to work in complete silence, or work with the interviewer as a team exercise, or a mix of both. The point of the exercise was to see if they could (a) program their way out of a wet paper bag and (b) do so in a way that didn't completely alienate the people they would have to work with. Leetcode? Obscure algorithms? We couldn't care less. It was surprisingly effective.