7 ms·

To be honest, I don't think your questions were good enough to filter out the smooth talkers. I was in a senior position at a successful agency and was hired be

To be honest, I don't think your questions were good enough to filter out the smooth talkers. I was in a senior position at a successful agency and was hired before they changed their interview style to match the eye-rolling "technical interview" that is now gold standard. I repeatedly argued they were getting too many false negatives and only a certain kind of developer with this style, but they believed "if Google and Apple do it, it must be good". Then I was put in a position to hire backend devs and, even though I couldn't entirely change the format of the interview, I came up with questions I believe could filter out the BS artists/not-yet-good-enough from the talent. And it worked. Example questions that are truly hard to BS: 1. I want to build a new service that crawls the internet for used bikes and presents them for sale. Roughly sketch out the architecture you would use and how all the parts fit together. - Why this question is good: it is impossible to successfully answer this question if you don't have experience building systems. Even if you try to BS it, your answer will come off shallow and break under any sort of probing. It also reveals how the dev's mind works when approaching problems. 2. Name your favorite tech stack. What is your favorite thing about it and what is your least favorite thing about it? - Why this question is good: any dev knows that every tech decision comes with good things and terrible things. I love Python, but GIL, circular imports, shitty deployment/package management, 2.x vs 3.x nonsense all suck. If you haven't been in the trenches, you can't answer this _specifically_... you can only answer it _broadly_. And it's very apparent right away to interviewer. I had about 4 - 5 of these questions. None of them required a single line of code to be written.

jimmaswell 8y ago
Does it have to crawl the whole internet or can it just scrape the top 5 or so most important sites?
- asaph 8y ago
  Asking clarifying questions is a good interviewee practice. Well done.
  - fgandiya 8y ago
    Their response reminds me of the Monty Python sketch about the speed of an unlaiden swallow.
- C4stor 8y ago
  Please define what is "the internet" first ^^
  - C1sc0cat 8y ago
    Define if you mean "an internet" or "the Internet" before that :-)
monksy 8y ago
Ask them about the challenges which they've faced when using x, y framework. Ask them why they prefer one framework to another. Ask them how they view testing Walk through with them on a simple whiteboard problem and ask them where they would write test cases. Watch for the amount of detail they give you. That will give you an indication of what kind of a developer and how deeply they go into problems.
- le-mark 8y ago
  It's even simpler, "tell me about a challenging bug you've vanguished, what it was and how you solved it." People in the trenches love to tell war stories. I do.
  - monksy 8y ago
    For me it tells me a lot about how a person goes about solving the problem, how they're going to avoid it later (if the are), context about the conditions that the person worked in, where their interest lies, and what motivates them. If their answer involves "well I searched around stackoverflow a lot and asked there" that's a no go for me.
tptacek 8y ago
I gave an example of one of our erstwhile technical interview questions below. Batting around interview questions is a hacker sport and I've met dozens of developers who delighted in relaying and evangelizing their preferred questions. I'll admit, candidly, that "what's your favorite tech stack and what don't you like about it" --- a question you can literally just look up blog posts on, and a question I feel I could answer credibly for several languages/frameworks I don't even know --- is a uniquely bad one. But even if I felt it was a good one, I wouldn't trust it. Interview questions don't work.
- darkpicnic 8y ago
  "a question you can literally just look up blog posts on, and a question I feel I could answer credibly for several languages/frameworks I don't even know" Really? You mean you could memorize a blog post for random languages, go into an interview and answer a question and not completely fall apart from follow up question 1, 2, n?... You make it sound like I'm asking this question, getting a monologue response and just moving on. These questions facilitate a dialogue between interviewer and interviewee, which quickly reveals your deeper understanding of a subject. Now, I think your above approach (lookup, memorize, pretend) works great for the kind of technical interview questions that I've been refuting this whole time. Finally, I don't think my questions are perfect, nor do I think the interview process in general is that great. I think the best way to find talent is to do a trial run for 1 - 2 weeks and see how good they are at taking fuzzy problems and breaking them down into actionable steps, then executing. This is regrettably hard to do for most people and companies.
  - mbtamuli 8y ago
    > I think the best way to find talent is to do a trial run for 1 - 2 weeks and see how good they are at taking fuzzy problems and breaking them down into actionable steps How do you get people to do a trial run for a week or two? Most people start looking for the next job when they are already doing their current one. So how can we ask them to do a trial run for a week or two? Also what about the remuneration(what kind should be given if at all for this period) and does this work for freshers and absolute newbies too?
nyxxie 8y ago
I really wish more interviews asked these questions. They're not only good questions for the reasons you mention, but for the interviewee (at least for me) they tend to be pretty low-stress to answer. Those sort of questions are, after all, something that I might be asked to do or think about during my everyday duties at a new company. I always sigh in relief when a company I'm interviewing with asks me something like that vs something like "implement x algorithm to solve y niche computer science problem you probably learned in college at some point".

jimmaswell 8y ago

Does it have to crawl the whole internet or can it just scrape the top 5 or so most important sites?

asaph 8y ago
Asking clarifying questions is a good interviewee practice. Well done.
- fgandiya 8y ago
  Their response reminds me of the Monty Python sketch about the speed of an unlaiden swallow.
C4stor 8y ago
Please define what is "the internet" first ^^
- C1sc0cat 8y ago
  Define if you mean "an internet" or "the Internet" before that :-)

monksy 8y ago

Ask them about the challenges which they've faced when using x, y framework. Ask them why they prefer one framework to another. Ask them how they view testing Walk through with them on a simple whiteboard problem and ask them where they would write test cases. Watch for the amount of detail they give you. That will give you an indication of what kind of a developer and how deeply they go into problems.

le-mark 8y ago
It's even simpler, "tell me about a challenging bug you've vanguished, what it was and how you solved it." People in the trenches love to tell war stories. I do.
- monksy 8y ago
  For me it tells me a lot about how a person goes about solving the problem, how they're going to avoid it later (if the are), context about the conditions that the person worked in, where their interest lies, and what motivates them. If their answer involves "well I searched around stackoverflow a lot and asked there" that's a no go for me.

tptacek 8y ago

I gave an example of one of our erstwhile technical interview questions below. Batting around interview questions is a hacker sport and I've met dozens of developers who delighted in relaying and evangelizing their preferred questions. I'll admit, candidly, that "what's your favorite tech stack and what don't you like about it" --- a question you can literally just look up blog posts on, and a question I feel I could answer credibly for several languages/frameworks I don't even know --- is a uniquely bad one. But even if I felt it was a good one, I wouldn't trust it. Interview questions don't work.

darkpicnic 8y ago
"a question you can literally just look up blog posts on, and a question I feel I could answer credibly for several languages/frameworks I don't even know" Really? You mean you could memorize a blog post for random languages, go into an interview and answer a question and not completely fall apart from follow up question 1, 2, n?... You make it sound like I'm asking this question, getting a monologue response and just moving on. These questions facilitate a dialogue between interviewer and interviewee, which quickly reveals your deeper understanding of a subject. Now, I think your above approach (lookup, memorize, pretend) works great for the kind of technical interview questions that I've been refuting this whole time. Finally, I don't think my questions are perfect, nor do I think the interview process in general is that great. I think the best way to find talent is to do a trial run for 1 - 2 weeks and see how good they are at taking fuzzy problems and breaking them down into actionable steps, then executing. This is regrettably hard to do for most people and companies.
- mbtamuli 8y ago
  > I think the best way to find talent is to do a trial run for 1 - 2 weeks and see how good they are at taking fuzzy problems and breaking them down into actionable steps How do you get people to do a trial run for a week or two? Most people start looking for the next job when they are already doing their current one. So how can we ask them to do a trial run for a week or two? Also what about the remuneration(what kind should be given if at all for this period) and does this work for freshers and absolute newbies too?

nyxxie 8y ago

I really wish more interviews asked these questions. They're not only good questions for the reasons you mention, but for the interviewee (at least for me) they tend to be pretty low-stress to answer. Those sort of questions are, after all, something that I might be asked to do or think about during my everyday duties at a new company. I always sigh in relief when a company I'm interviewing with asks me something like that vs something like "implement x algorithm to solve y niche computer science problem you probably learned in college at some point".