6 ms·

I ask everyone to bring their own project to work on! It could be adding a feature to a side project, starting something new, or contributing to open source. (

I ask everyone to bring their own project to work on! It could be adding a feature to a side project, starting something new, or contributing to open source. (Or, we have some stock ideas if people need inspiration.) Rather than asking them to solve a problem they had never heard of before or use a codebase they're not familiar with, I get so much more out of watching them work in their own environment. I can ask them questions about why they're doing something, and they tend to have much more detailed answers because they've been thinking about it for weeks. They're solving a problem they care about in a codebase they know, which mimics how working with them will be a few months in. We can talk about tradeoffs and design decision, and I get a real sense for how they think. Plus, I've found most people are so much more comfortable and excited. (If you're interested, I wrote a blog post about all the ways I've designed how we interview, to give everyone the chance to show off the best version of themselves: https://blog.readme.com/designing-a-candidate-focused-interview-process/ https://blog.readme.com/designing-a-candidate-focused-interv... And of course, I'm hiring!)

tfsh 6y ago
That's an interesting interview approach - I really like it. Do you find the lack of context (about the interviewees project) on the part of the interviewer to ever be an issue?
- gkoberger 6y ago
  That’s the best part! You get to see how well they are able to articulate what, how and why they’re building. That’s such a huge part of working with someone, which you don’t get if you tell them exactly what to do.
_eigenfoo 6y ago
How do you compensate for the fact that you don't know the codebase that well? I feel like a lot of the value of interviews is that you see how a candidate thinks through a problem that you have also thought deeply about, which gives more fruitful discussions.
- saimiam 6y ago
  This is a great question. Guess OPs approach only works if they are hiring someone much more junior than themselves so that experience trumps code/domain familiarity.
  - gkoberger 6y ago
    Not at all! I’m pretty experienced, but most people I interview or hire are much better engineers than me! Imagine you’re taking a class on a topic you don’t know. You can tell pretty quickly from how the instructor talks and explains something if they know what they’re talking about. It’s very similar! I’ve certainly interviewed people much more skilled than me in languages I’ve never used, and still got a pretty great sense of their expertise.
- gkoberger 6y ago
  Well, that's not how I tend to manage day-to-day. I don't give engineers I manage a problem I've already figured out and solved, and then expect them to do it the way I would. Rather, the engineers on the team are usually building something new, and figuring out how to accomplish it is their responsibility. This way of interviewing mimics that a lot closer. If someone can't explain to me a project they're working on, then they probably won't be able to do the same while we're working together. And that's just as important of a skill as writing code. If I'm expecting interviewees (who are nervous!) to learn and understand my codebase/problem, why can't I do the same for theirs?
  - yowlingcat 6y ago
    Love this attitude. It's a great attitude and it shows. A very common thing I notice with interviewers is that they do one interview over and over again until it's super polished, but paradoxically, they won't compensate for that and in effect, the bar gets higher and higher for later candidates than earlier ones. Flipping the script not only is a great way to balance things here, but it also says a lot about your own confidence. I might have to lift your approach here!
stennie 6y ago
Your candidate-focused interview process is very inspiring! I really like the "bring your own project" idea and it also looks like you've cleverly integrated your product into the interview experience (I'm assuming that is what powers the personalised interview website). I also think the general tone and styling of your content is very considered and engaging. My honest first impression is surprise that I haven't come across your brand yet, but I'm definitely going to learn more.
greggman3 6y ago
Plenty of great programmers have no side projects. They have family or hobbies or something else that occupies their time outside of work.
- gkoberger 6y ago
  Yup! We have projects and ideas ready to go if they don’t have one :) For people like this, though, I’ve seen many use it as an opportunity to work on something they’ve been wanting to for a while and never had the time! A Hello World in a new language, merging in PRs on an old repo, writing a script to automate something or even a take home coding exam for another company.
  - deleted 6y ago
    [deleted]
  - stennie 6y ago
    In the example interview schedule in your blog post there's only an hour allocated for BYO project discussion. Is that representative of your typical interview schedule? The scope of some of your examples in the blog post may be challenging to cover in much detail in the first hour working with brand new collaborators, although perhaps is enough for calibration. Are you able to share any examples of the fun projects/ideas you have as suggestions for candidates that don't have a project of their own?
    - gkoberger 6y ago
      Yup, we do an hour. After that, it feels like there's diminishing returns. There's absolutely no expectation anyone will "finish", and we make that clear. It's the journey we're interested in, not the destination. One that we tend to do a lot is creating an image gallery using Flickr or Unsplashed's API. It's vague enough that people can take it in whatever direction they want, and simple enough that you can get pretty far in an hour.
    - reificator 6y ago
      I was surprised it was that long, I can talk about a project for much longer than an hour but the average interviewer won't give a shit past 15-30 minutes.
dbcurtis 6y ago
Wow. Best new interviewing idea I have heard in a long time!
HaloZero 6y ago
How do you avoid bias? It seems that if a personal project aligns with the interviewer's preferences or tastes it could create a huge bias.
- gkoberger 6y ago
  Is there any more bias than the interviewer picking the question to begin with? By letting the interviewee pick, we're letting them decide which of their "superpowers" to show off. If they can explain why they chose to do something the way they're doing it, and show they understand the tradeoffs, that's good enough for me.
  - HaloZero 6y ago
    There's a benefit to having a standard question that you can grade independently, you can uncover your own teams biases by having two people evaluate a candidate. One who met them, one who didn't. It can avoid interviewer bias with decision. It sounds like you're putting that system of bias under the rug.
razwall 6y ago
Interesting. Does anyone ever fail this part of the interview?
- johnm 6y ago
  Can't speak for the GP but IME, absolutely. It's much easier to dig in deeper with (much) clearer signal about somebody when they are talking/working with their own code/project. Less distractions/confounding factors/proxies, more direct inquiry and you can go as deep and broad as you want to map the edges/gaps of not only what they know but what they care about/prioritize and why. The proof is in the code.
SPBS 6y ago
This is well intentioned, but have you had any of the applicants try to game it?
- gkoberger 6y ago
  Sure, people prepare! But that's a good thing. We want everyone to do well. If we sense they're doing something they've rehearsed a bit too much, we might push them to do it a bit differently. "What if you tried to do this by _____", just to make sure they can think on their feet. Honestly, though, the best candidates for us are the ones who wouldn't try to game it. They hear the prompt, and are just so excited to show and talk about a project they're building that it's not a problem!
- johnm 6y ago
  I had a great conversation with one of my cofounders about this. First off, if you're only asking questions to a point where they are gameable then your questions aren't very good. The example I was trying to explain to him was that I look for 'aggressive curiosity' and wasn't sure I wanted to put that into the job description. He laughed and asked how far could someone game that as we keep asking follow up questions on any aspect of the discussion?
  - gkoberger 6y ago
    Yes! "Curiosity" is the #1 thing I look for, too! And this question is great at it. It's a great proxy for empathy and understanding. If you're curious, it means you want to learn the why behind why other people do things.
    - johnm 6y ago
      Indeed. And true humility. "Less certainty, more inquiry." --Erik Seidel
natdempk 6y ago
How do you maintain consistency across candidates with this approach? One of the struggles I've seen with interviewing is making sure that candidates are judged on a fair and consistent scale across interviews, candidates, interviewers, etc. Do you find having a different project for each interview makes getting a consistent and comparable signal out of interviews challenging?
- gkoberger 6y ago
  Good question! We’re lucky we don’t need to worry about this for engineers. We never choose between two candidate, rather each candidate is judged on if we want to work with them or not. It’s an advantage we have as a small company! We can rate people based on whatever criteria gives them the best chance, and we can find a ton of great candidates that maybe wouldn’t make it through a traditional hiring interview at a larger company.
  - mav3rick 6y ago
    Then your method doesn't scale.
    - gkoberger 6y ago
      I think it does. But even if not, that's fine! Until we have to scale it, it's an unfair advantage we have. Like YC said, "Do things that don't scale."
    - mdturnerphys 6y ago
      http://paulgraham.com/ds.html http://paulgraham.com/ds.html
    - johnm 6y ago
      What makes you believe that? Do you believe that the e.g., algo approaches create a strictly rank orderable list of candidates which actually correlates to their on-the-job impact? Also, why do you think such a thing matters more at scale than when a team/company is small?
throwaway189262 6y ago
A lot of engineers don't work on their side projects because they can't. Every company I've interviewed with requires IP assignment agreement. From my experience, it's standard outside of California where they're banned. If you asked me to work on something, it would be a toy project. Because I can't contribute to open source and if I build anything substantial it will be taken from me. You shouldn't punish people in this situation. It's extremely common, maybe even the majority of coders outside California.
- gkoberger 6y ago
  I already answered this elsewhere: https://news.ycombinator.com/item?id=24457320 https://news.ycombinator.com/item?id=24457320 That being said, I've interviewed hundreds of candidates over the past 5 years, and not a single one has cited IP assignment as a hesitation.
- logicallee 6y ago
  >Every company I've interviewed with requires IP assignment agreement. of course they do, you're a knowledge worker for them. they need to own what you create. a standard phrasing includes "related to the employer's business". see for yourself: https://www.lawinsider.com/clause/intellectual-property-assignment https://www.lawinsider.com/clause/intellectual-property-assi... "during the period of his employment relating to the business of the Company". If your contract doesn't have the words "relating to the business of the Company" then add those words in yourself, signing and dating the change and telling the company of your change. you're not their slave you know. they don't get stuff you make in your free time. however, not replicating the company's business is a fair requirement, since they might share enough information with you to do just that. I think it's fair for them to get everything related to their business.

tfsh 6y ago

That's an interesting interview approach - I really like it. Do you find the lack of context (about the interviewees project) on the part of the interviewer to ever be an issue?

gkoberger 6y ago
That’s the best part! You get to see how well they are able to articulate what, how and why they’re building. That’s such a huge part of working with someone, which you don’t get if you tell them exactly what to do.

_eigenfoo 6y ago

How do you compensate for the fact that you don't know the codebase that well? I feel like a lot of the value of interviews is that you see how a candidate thinks through a problem that you have also thought deeply about, which gives more fruitful discussions.

saimiam 6y ago
This is a great question. Guess OPs approach only works if they are hiring someone much more junior than themselves so that experience trumps code/domain familiarity.
- gkoberger 6y ago
  Not at all! I’m pretty experienced, but most people I interview or hire are much better engineers than me! Imagine you’re taking a class on a topic you don’t know. You can tell pretty quickly from how the instructor talks and explains something if they know what they’re talking about. It’s very similar! I’ve certainly interviewed people much more skilled than me in languages I’ve never used, and still got a pretty great sense of their expertise.
gkoberger 6y ago
Well, that's not how I tend to manage day-to-day. I don't give engineers I manage a problem I've already figured out and solved, and then expect them to do it the way I would. Rather, the engineers on the team are usually building something new, and figuring out how to accomplish it is their responsibility. This way of interviewing mimics that a lot closer. If someone can't explain to me a project they're working on, then they probably won't be able to do the same while we're working together. And that's just as important of a skill as writing code. If I'm expecting interviewees (who are nervous!) to learn and understand my codebase/problem, why can't I do the same for theirs?
- yowlingcat 6y ago
  Love this attitude. It's a great attitude and it shows. A very common thing I notice with interviewers is that they do one interview over and over again until it's super polished, but paradoxically, they won't compensate for that and in effect, the bar gets higher and higher for later candidates than earlier ones. Flipping the script not only is a great way to balance things here, but it also says a lot about your own confidence. I might have to lift your approach here!

stennie 6y ago

Your candidate-focused interview process is very inspiring! I really like the "bring your own project" idea and it also looks like you've cleverly integrated your product into the interview experience (I'm assuming that is what powers the personalised interview website). I also think the general tone and styling of your content is very considered and engaging. My honest first impression is surprise that I haven't come across your brand yet, but I'm definitely going to learn more.

greggman3 6y ago

Plenty of great programmers have no side projects. They have family or hobbies or something else that occupies their time outside of work.

gkoberger 6y ago
Yup! We have projects and ideas ready to go if they don’t have one :) For people like this, though, I’ve seen many use it as an opportunity to work on something they’ve been wanting to for a while and never had the time! A Hello World in a new language, merging in PRs on an old repo, writing a script to automate something or even a take home coding exam for another company.
- deleted 6y ago
  [deleted]
- stennie 6y ago
  In the example interview schedule in your blog post there's only an hour allocated for BYO project discussion. Is that representative of your typical interview schedule? The scope of some of your examples in the blog post may be challenging to cover in much detail in the first hour working with brand new collaborators, although perhaps is enough for calibration. Are you able to share any examples of the fun projects/ideas you have as suggestions for candidates that don't have a project of their own?
  - gkoberger 6y ago
    Yup, we do an hour. After that, it feels like there's diminishing returns. There's absolutely no expectation anyone will "finish", and we make that clear. It's the journey we're interested in, not the destination. One that we tend to do a lot is creating an image gallery using Flickr or Unsplashed's API. It's vague enough that people can take it in whatever direction they want, and simple enough that you can get pretty far in an hour.
  - reificator 6y ago
    I was surprised it was that long, I can talk about a project for much longer than an hour but the average interviewer won't give a shit past 15-30 minutes.

dbcurtis 6y ago

Wow. Best new interviewing idea I have heard in a long time!

HaloZero 6y ago

How do you avoid bias? It seems that if a personal project aligns with the interviewer's preferences or tastes it could create a huge bias.

gkoberger 6y ago
Is there any more bias than the interviewer picking the question to begin with? By letting the interviewee pick, we're letting them decide which of their "superpowers" to show off. If they can explain why they chose to do something the way they're doing it, and show they understand the tradeoffs, that's good enough for me.
- HaloZero 6y ago
  There's a benefit to having a standard question that you can grade independently, you can uncover your own teams biases by having two people evaluate a candidate. One who met them, one who didn't. It can avoid interviewer bias with decision. It sounds like you're putting that system of bias under the rug.

razwall 6y ago

Interesting. Does anyone ever fail this part of the interview?

johnm 6y ago
Can't speak for the GP but IME, absolutely. It's much easier to dig in deeper with (much) clearer signal about somebody when they are talking/working with their own code/project. Less distractions/confounding factors/proxies, more direct inquiry and you can go as deep and broad as you want to map the edges/gaps of not only what they know but what they care about/prioritize and why. The proof is in the code.

SPBS 6y ago

This is well intentioned, but have you had any of the applicants try to game it?

gkoberger 6y ago
Sure, people prepare! But that's a good thing. We want everyone to do well. If we sense they're doing something they've rehearsed a bit too much, we might push them to do it a bit differently. "What if you tried to do this by _____", just to make sure they can think on their feet. Honestly, though, the best candidates for us are the ones who wouldn't try to game it. They hear the prompt, and are just so excited to show and talk about a project they're building that it's not a problem!
johnm 6y ago
I had a great conversation with one of my cofounders about this. First off, if you're only asking questions to a point where they are gameable then your questions aren't very good. The example I was trying to explain to him was that I look for 'aggressive curiosity' and wasn't sure I wanted to put that into the job description. He laughed and asked how far could someone game that as we keep asking follow up questions on any aspect of the discussion?
- gkoberger 6y ago
  Yes! "Curiosity" is the #1 thing I look for, too! And this question is great at it. It's a great proxy for empathy and understanding. If you're curious, it means you want to learn the why behind why other people do things.
  - johnm 6y ago
    Indeed. And true humility. "Less certainty, more inquiry." --Erik Seidel

natdempk 6y ago

How do you maintain consistency across candidates with this approach? One of the struggles I've seen with interviewing is making sure that candidates are judged on a fair and consistent scale across interviews, candidates, interviewers, etc. Do you find having a different project for each interview makes getting a consistent and comparable signal out of interviews challenging?

gkoberger 6y ago
Good question! We’re lucky we don’t need to worry about this for engineers. We never choose between two candidate, rather each candidate is judged on if we want to work with them or not. It’s an advantage we have as a small company! We can rate people based on whatever criteria gives them the best chance, and we can find a ton of great candidates that maybe wouldn’t make it through a traditional hiring interview at a larger company.
- mav3rick 6y ago
  Then your method doesn't scale.
  - gkoberger 6y ago
    I think it does. But even if not, that's fine! Until we have to scale it, it's an unfair advantage we have. Like YC said, "Do things that don't scale."
  - mdturnerphys 6y ago
    http://paulgraham.com/ds.html http://paulgraham.com/ds.html
  - johnm 6y ago
    What makes you believe that? Do you believe that the e.g., algo approaches create a strictly rank orderable list of candidates which actually correlates to their on-the-job impact? Also, why do you think such a thing matters more at scale than when a team/company is small?

throwaway189262 6y ago

A lot of engineers don't work on their side projects because they can't. Every company I've interviewed with requires IP assignment agreement. From my experience, it's standard outside of California where they're banned. If you asked me to work on something, it would be a toy project. Because I can't contribute to open source and if I build anything substantial it will be taken from me. You shouldn't punish people in this situation. It's extremely common, maybe even the majority of coders outside California.

gkoberger 6y ago
I already answered this elsewhere: https://news.ycombinator.com/item?id=24457320 https://news.ycombinator.com/item?id=24457320 That being said, I've interviewed hundreds of candidates over the past 5 years, and not a single one has cited IP assignment as a hesitation.
logicallee 6y ago
>Every company I've interviewed with requires IP assignment agreement. of course they do, you're a knowledge worker for them. they need to own what you create. a standard phrasing includes "related to the employer's business". see for yourself: https://www.lawinsider.com/clause/intellectual-property-assignment https://www.lawinsider.com/clause/intellectual-property-assi... "during the period of his employment relating to the business of the Company". If your contract doesn't have the words "relating to the business of the Company" then add those words in yourself, signing and dating the change and telling the company of your change. you're not their slave you know. they don't get stuff you make in your free time. however, not replicating the company's business is a fair requirement, since they might share enough information with you to do just that. I think it's fair for them to get everything related to their business.