6 ms·

I've often thought about this, and based on my own experiences this is the process I would like: 1. Test language-specific knowledge - it's not a bad thing to

I've often thought about this, and based on my own experiences this is the process I would like: 1. Test language-specific knowledge - it's not a bad thing to not know all the small quirks or details of a language since they're generally not too useful, but when someone does know them it tends to be a good sign that they really enjoy coding and learning. And of course there is a certain minimum amount of knowledge that should be required - listing Java as "proficient" on your resume while not knowing the difference between abstract classes and interfaces might indicate a problem. 2. Design question - just a simple toy problem like "how would you design the book management system for a library?". It's easy to use such a problem to probe into some different aspects of programming like concurrency and databases, just to see how much the person knows. 3. A not-crazy-hard algorithms questions - people often say algo questions are irrelevant to actual work, and I agree with that. But I think algorithms are really a core part of the CS curriculum at every school, so getting completely stuck on a medium-difficulty algorithm question should raise some flags. 4. Resume-specific things - it's always nice for an interviewer to show that they've actually read your resume, and it can be a good way to convey some strengths that aren't otherwise evident. I guess my philosophy is to interview in a way that can test the depth of a candidate's knowledge while not being obnoxiously tedious or memorization-focused. i.e. someone who has written a lot of production code should do better in an interview than someone who's just memorized every problem in Cracking the Coding Interview. So, ideally with the screening round clearing the first part (language-specific knowledge), and then 2 or 3 subsequent interviews that cover design and algos.

mav3rick 8y ago
Language quirks are the worst thing to ask in an interview. Please don't do it, it's barely a step above memorization.
- marcell 8y ago
  That’s not true. If you have ten years experience with Python, but don’t know about, say, @property decorators or how variable scoping works, that raises some red flags.
- camjohnson26 8y ago
  On the other hand if a candidate has been coding a language for a long time and doesn’t know the quirks that could be a red flag
- lawnchair_larry 8y ago
  I think it depends how you do it. When I interview, part of what I do is try to find quirks that they know about, but not count the ones they don’t know about against them. I think you can quickly get a sense of depth, potential, curiosity, and passion if you can get them talking about quirks and their opinions on those quirks. For example, if someone says that they once attached a debugger to the JVM to confirm a pathological issue arising from benign looking Java code and found that the JIT compiler falls apart when a certain construct is used, I’m probably going to hire that person, even if we have no Java code in the company - assuming I can also confirm that they are productive and don’t just waste time going down deep rabbit holes.
  - chillacy 8y ago
    How has that been working out for you? I used to think the same and I'd ask a "programming passion question" right before a simple coding question, and then I'd run into these amazing bullshitters who could talk shop but couldn't write fizzbuzz. But they'd come up with a bunch of excuses as they were writing the code as to why ("oh my company uses this other framework so I forgot how to write a for loop"). So sadly I stopped paying attention to that part. I only ask it to make the candidate comfortable before we dive into code.
    - lawnchair_larry 8y ago
      Nobody who can go into that level of detail doesn’t know what a for loop is.
      - chillacy 8y ago
        It seems you're doubting my story. Maybe you think my threshold for "that level of detail" isn't sufficient, or whatever candidate sourcing we use doesn't filter these people out.
- james_s_tayler 8y ago
  I think it's ok to flip the script and ask what a candidates favorite language quirk is or if they have a story relating to a language quirk. In my experience curious developers who like to dive deep light up and love discussing that kind of stuff. Testing random trivia is dumb.
lazerwalker 8y ago
The only thing I'd caution (particularly about #1) is that being able to parrot facts — even ones you know cold — on-demand in a high-intensity interview setting can be very different from using those same facts day-to-day. If someone can't describe the difference between abstract classes and interfaces, how confident are you it's because they don't understand it and not just because they're horrible at being put on the spot in an interview-style environment?
- asark 8y ago
  Hell, I can barely "hello world" in languages I've been actively and productively writing for months or even years, without context (i.e. existing code) to draw on and/or tool assistance. I've got a better than 50% offer rate on interviews in an over 15 year long career but in one of the ones I flubbed I blanked on the syntax for invoking methods on an object in the language I knew best, at the time, and wrote some other (more common) invocation syntax instead, which can't have helped. Ask me JS scoping trivia and I guarantee I'll screw it up, despite having written JS and TS as my main language(s) for 3ish years now. Look, I stick to a subset of that language precisely so that I can ignore that shit. We can just skip the interview and go straight to the rejection if you're gonna do that. Doubly so if you don't tell me you're gonna do that so I can drill on it before hand. Coworker and manager feedback, and my compensation over the years, say I'm pretty damn good at adding value despite this. I've been considered the "smart one" and the go-to guy for hard or weird problems. But I will struggle to produce something that will even come close to compiling on your whiteboard, in a language I wrote 300 useful lines of yesterday, unless I spend a couple days basically flash-card drilling for your test. Go figure.
- nostrebored 8y ago
  Not being able to describe the difference between abstract classes and interfaces is a huge red flag for anyone working in OO Software Development. You can't be serious?
  - random314 8y ago
    Only dipshits working on shitty OO projects care about the difference between an abstract class and an interface. Let me guess - you also think algorithmic complexity analysis is overrated.
lawnchair_larry 8y ago
For #3, it’s not really a red flag. I am guessing you are a fairly recent grad? Most people who learn algos & DS never have to implement them on the job, and often haven’t actually written their own since their CS classes. If the question is any deeper than “what are some good and bad choices of algorithms for this problem”, you’re selecting more for who has just graduated or has been grinding leetcode and doesn’t have performance anxiety than you are for competence, expertise, and productivity. I know folks who got rejected from the leetcode companies and went on to build major products from scratch. The 0.5% of work that requires them to have to implement something like this manually, they’ll just grab their CLRS book and refresh their memory long enough to solve the problem and probably forget it again a week later. I also know folks at these companies who started fresh out of college, passed that style of interview, worked there for 7-10 years, moved up to senior or higher in the engineering track, and openly admit that they would be a deer in the headlights if they got any of the interview questions. Without going back to study and practice those, they know wouldn’t pass an interview for a junior dev, let alone one for their current job (where they are currently considered high performers). The big problem is that this style of interview filters for people who pass this style of interview, and then those new hires are asked to interview others, so they interviewed in the style that they were given and passed.
- rococode 8y ago
  Yeah, I'm currently a grad student so there's definitely some bias haha. The kind of question I had in mind would be along the lines of "say you have a tree, how could you find the nearest common ancestor of two nodes in that tree?". I actually got this question during an interview recently, and I felt it was of a suitable difficulty where I could figure out a solution without any specific knowledge other than what a tree is (which most developers should know). I'm sure I'm still young and naive, but my line of thinking is that a question like that is good for having a person show their thought process when figuring out a problem they haven't seen before. Design questions are a bit different because they tend to just require a rehash of a codebase you've worked with before.
  - pmontra 8y ago

mav3rick 8y ago

Language quirks are the worst thing to ask in an interview. Please don't do it, it's barely a step above memorization.

marcell 8y ago
That’s not true. If you have ten years experience with Python, but don’t know about, say, @property decorators or how variable scoping works, that raises some red flags.
camjohnson26 8y ago
On the other hand if a candidate has been coding a language for a long time and doesn’t know the quirks that could be a red flag
lawnchair_larry 8y ago
I think it depends how you do it. When I interview, part of what I do is try to find quirks that they know about, but not count the ones they don’t know about against them. I think you can quickly get a sense of depth, potential, curiosity, and passion if you can get them talking about quirks and their opinions on those quirks. For example, if someone says that they once attached a debugger to the JVM to confirm a pathological issue arising from benign looking Java code and found that the JIT compiler falls apart when a certain construct is used, I’m probably going to hire that person, even if we have no Java code in the company - assuming I can also confirm that they are productive and don’t just waste time going down deep rabbit holes.
- chillacy 8y ago
  How has that been working out for you? I used to think the same and I'd ask a "programming passion question" right before a simple coding question, and then I'd run into these amazing bullshitters who could talk shop but couldn't write fizzbuzz. But they'd come up with a bunch of excuses as they were writing the code as to why ("oh my company uses this other framework so I forgot how to write a for loop"). So sadly I stopped paying attention to that part. I only ask it to make the candidate comfortable before we dive into code.
  - lawnchair_larry 8y ago
    Nobody who can go into that level of detail doesn’t know what a for loop is.
    - chillacy 8y ago
      It seems you're doubting my story. Maybe you think my threshold for "that level of detail" isn't sufficient, or whatever candidate sourcing we use doesn't filter these people out.
james_s_tayler 8y ago
I think it's ok to flip the script and ask what a candidates favorite language quirk is or if they have a story relating to a language quirk. In my experience curious developers who like to dive deep light up and love discussing that kind of stuff. Testing random trivia is dumb.

lazerwalker 8y ago

The only thing I'd caution (particularly about #1) is that being able to parrot facts — even ones you know cold — on-demand in a high-intensity interview setting can be very different from using those same facts day-to-day. If someone can't describe the difference between abstract classes and interfaces, how confident are you it's because they don't understand it and not just because they're horrible at being put on the spot in an interview-style environment?

asark 8y ago
Hell, I can barely "hello world" in languages I've been actively and productively writing for months or even years, without context (i.e. existing code) to draw on and/or tool assistance. I've got a better than 50% offer rate on interviews in an over 15 year long career but in one of the ones I flubbed I blanked on the syntax for invoking methods on an object in the language I knew best, at the time, and wrote some other (more common) invocation syntax instead, which can't have helped. Ask me JS scoping trivia and I guarantee I'll screw it up, despite having written JS and TS as my main language(s) for 3ish years now. Look, I stick to a subset of that language precisely so that I can ignore that shit. We can just skip the interview and go straight to the rejection if you're gonna do that. Doubly so if you don't tell me you're gonna do that so I can drill on it before hand. Coworker and manager feedback, and my compensation over the years, say I'm pretty damn good at adding value despite this. I've been considered the "smart one" and the go-to guy for hard or weird problems. But I will struggle to produce something that will even come close to compiling on your whiteboard, in a language I wrote 300 useful lines of yesterday, unless I spend a couple days basically flash-card drilling for your test. Go figure.
nostrebored 8y ago
Not being able to describe the difference between abstract classes and interfaces is a huge red flag for anyone working in OO Software Development. You can't be serious?
- random314 8y ago
  Only dipshits working on shitty OO projects care about the difference between an abstract class and an interface. Let me guess - you also think algorithmic complexity analysis is overrated.

lawnchair_larry 8y ago

For #3, it’s not really a red flag. I am guessing you are a fairly recent grad? Most people who learn algos & DS never have to implement them on the job, and often haven’t actually written their own since their CS classes. If the question is any deeper than “what are some good and bad choices of algorithms for this problem”, you’re selecting more for who has just graduated or has been grinding leetcode and doesn’t have performance anxiety than you are for competence, expertise, and productivity. I know folks who got rejected from the leetcode companies and went on to build major products from scratch. The 0.5% of work that requires them to have to implement something like this manually, they’ll just grab their CLRS book and refresh their memory long enough to solve the problem and probably forget it again a week later. I also know folks at these companies who started fresh out of college, passed that style of interview, worked there for 7-10 years, moved up to senior or higher in the engineering track, and openly admit that they would be a deer in the headlights if they got any of the interview questions. Without going back to study and practice those, they know wouldn’t pass an interview for a junior dev, let alone one for their current job (where they are currently considered high performers). The big problem is that this style of interview filters for people who pass this style of interview, and then those new hires are asked to interview others, so they interviewed in the style that they were given and passed.

rococode 8y ago
Yeah, I'm currently a grad student so there's definitely some bias haha. The kind of question I had in mind would be along the lines of "say you have a tree, how could you find the nearest common ancestor of two nodes in that tree?". I actually got this question during an interview recently, and I felt it was of a suitable difficulty where I could figure out a solution without any specific knowledge other than what a tree is (which most developers should know). I'm sure I'm still young and naive, but my line of thinking is that a question like that is good for having a person show their thought process when figuring out a problem they haven't seen before. Design questions are a bit different because they tend to just require a rehash of a codebase you've worked with before.
- pmontra 8y ago