5 ms·

As an interviewer, how do I know that you wrote that code in your GitHub profile?

paranoidrobot 6y ago
Code often doesn't stand alone, there's going to be a commit history, there's often going to be comments and issues on other projects. Ask questions about the code: - why did you write this in this way - explain how this works - if you needed to add X into this, how would you do it - are there other ways to achieve what you did here, what are the pros/cons of this? - what would you do differently if you were to re-write this? - are there any bugs or common issues, how do you go about diagnosing and debugging them? Could you write the code differently to be more resiliant to those issues? Anyone who wrote that code (assuming it was relatively recently) is going to be able to talk about it sensibly, and be able to dig into the code and show how certain things are done.
- grogenaut 6y ago
  I had a former coworker re-write a library we had open sourced as their own. They had used the original version at work so knew it well, knew the internals by asking lots of questions while working for performance reasons. They renamed things and changed pointers around to their preference. They did this right before they left and had it on github as their work. They could meet all of your questions. They didn't really write the code, but it was MIT, what can you do. It was very obviously there as bait for people like you and it was removed as soon as they took a new job. It was never used in production in its "released" form. I had no problem with the person's abilities to code, but for reasons like this I probably wouldn't work with them again, or hire them as a eng lead or higher.
  - paranoidrobot 6y ago
    I don't see a solution for this. What you're describing is someone who's clearly good enough to take a project and rewrite it, and still be able to talk in detail about the code. I'd bet they could also pass a whiteboard, pair-programming or take-home test too. That they are willing to lie about it and pass off other's work as their own isn't something that you're going to identify in your typical code interview. Using interrogation tactics to try and weed out the frauds is going to be counter-productive, by driving off all the good candidates.
    - grogenaut 6y ago
      I don't disagree. You might see some of the issues with this candidate on what they choose to highlight as their career successes, I've definitely caught dishonest people, or people I wouldn't work with via soft questions. But I'm not sure, I've never interviewed this person.
  - Impossible 6y ago
    One question is, if someone is doing elaborate deceptive work like this, gets hired and has no problems performing the job, does it actually matter? Some people mostly or entirely code at work, so this looks like a legitimate way to get a "good" project in GitHub that he knew well. It sucks that it's deceptive (which could be a major red flag), but it's also clear enough that he understood a large codebase well enough to explain it and modify and/or refactor it, which is honestly the majority of a SWE job. A lot of people are concerned about the "purity" of how someone solves an interview challenge, and outside of potential ethical red flags, people that "cheat" the system are often putting in a lot of work, and are as likely as anyone else to be capable of doing the work.
    - grogenaut 6y ago
      No if they had no problems performing on the job then no it's not an issue. Maybe they learned and this provided a good reset for them. Maybe they didn't and similar issues will crop up. I put the anecdote up as a real-world example of one way the GGP's github reference can be faked. You would have to dig really hard into their knowledge of the system to catch them, which you wouldn't have time to do. For instance, I believe the issues would show up in a benchmark.
    - deleted 6y ago
      [deleted]
chrisseaton 6y ago
Ask them some questions about it over lunch? What’s your threat model here? People making up elaborate lies about code they’ve written?
- vageli 6y ago
  > What’s your threat model here? People making up elaborate lies about code they’ve written? Likely people making up elaborate lies about code they didn't write. It's trivial to push code of which you are not the author.
  - chrisseaton 6y ago
    I can’t imagine a situation where you couldn’t work that out with five minutes of casual conversation about the codebase but maybe I’m naive.
  - victor9000 6y ago
    Which is why the interviewer should ask specific and thoughtful questions about the project, so they can gauge the candidate's level of understanding. This concern could also be addressed by introducing a trial period.
    - marcinzm 6y ago
      >This concern could also be addressed by introducing a trial period. Why would I leave a stable well paying job for a job that basically says they don't trust me enough to not fire me in two weeks?
      - paulcole 6y ago
        At least they’re honest about it. Unless you’ve got some kind of contract in place (or live somewhere where this is prohibited by law) your current employer could fire you in 2 weeks if they didn’t like your performance, too. They could do it this afternoon even.
      - vageli 6y ago
amiantos 6y ago
Have the interviewee submit repos in which they're the only contributor? But, uh, with a take home project, you _really_ don't know that they wrote the code, either...
- keanebean86 6y ago
  Do a take-home project but don't make them write from scratch. Give them a mostly working starter application. Sprinkle in some bugs. Start with easy spelling errors and go all the way to concurrency problems. Ask them to add a few simple features and fix any bugs they find. Bonus points if they find bugs you didn't add intentionally. Good unit tests are also a bonus. Give them a couple days or something. Don't count off if they don't get everything done. It's better to do a few things correctly that fix everything with hacks. Invite them to email questions/suggestions to the hiring team. This person might be on your team so it's nice to find out early if they have good ideas or they hound you with stack overflow questions all day. I've never had this kind of interview but it sounds nice to me. It's more realistic to real daily work. You can cheat by having someone else do the work but that's always a possibility.
  - asdff 6y ago
    This sounds sadistic to me. I've spent a long time on dumb typos, which become a lot harder to spot when you are stressed and on a deadline. Chances are if you are applying for work, you are probably stressed about not having a job.
    - keanebean86 6y ago
      You've completely missed my point. It's not about being perfect. I want to work with people who leave code better than they found it but I can't expect perfection. I don't care if they can't find all the typos. I'm sure most software has typos. Whiteboardimg a solution to n=np or building full applications is crazy and not realistic. Most interviews do that yet most work is fixing bugs and adding mundane features. Why can't interviews focus on the actual skills needed?
willcipriano 6y ago
"Interesting choice using collections.OrderedDict here, why did you choose that?"
- vageli 6y ago
  > "Interesting choice using collections.OrderedDict here, why did you choose that?" Without looking at the commit history, given enough time this is a challenge. I often don't recognize code I wrote myself 6 months ago.
  - deleted 6y ago
    [deleted]
XCSme 6y ago
I think discussing the projects would be a better solution. The interviewer looks over his projects and asks questions about them, the applicant explains his thought process behind the decisions made.
invalidOrTaken 6y ago
If I'd stolen it, I'd have picked something prettier!
asdff 6y ago
I would assume the best, then in a week when it is clear that they faked their way in you can just lay them off. If they faked their way in but are a great member of the team going forward and contributing to projects, do you really care as a manager?

Code often doesn't stand alone, there's going to be a commit history, there's often going to be comments and issues on other projects. Ask questions about the code: - why did you write this in this way - explain how this works - if you needed to add X into this, how would you do it - are there other ways to achieve what you did here, what are the pros/cons of this? - what would you do differently if you were to re-write this? - are there any bugs or common issues, how do you go about diagnosing and debugging them? Could you write the code differently to be more resiliant to those issues? Anyone who wrote that code (assuming it was relatively recently) is going to be able to talk about it sensibly, and be able to dig into the code and show how certain things are done.

grogenaut 6y ago
I had a former coworker re-write a library we had open sourced as their own. They had used the original version at work so knew it well, knew the internals by asking lots of questions while working for performance reasons. They renamed things and changed pointers around to their preference. They did this right before they left and had it on github as their work. They could meet all of your questions. They didn't really write the code, but it was MIT, what can you do. It was very obviously there as bait for people like you and it was removed as soon as they took a new job. It was never used in production in its "released" form. I had no problem with the person's abilities to code, but for reasons like this I probably wouldn't work with them again, or hire them as a eng lead or higher.
- paranoidrobot 6y ago
  I don't see a solution for this. What you're describing is someone who's clearly good enough to take a project and rewrite it, and still be able to talk in detail about the code. I'd bet they could also pass a whiteboard, pair-programming or take-home test too. That they are willing to lie about it and pass off other's work as their own isn't something that you're going to identify in your typical code interview. Using interrogation tactics to try and weed out the frauds is going to be counter-productive, by driving off all the good candidates.
  - grogenaut 6y ago
    I don't disagree. You might see some of the issues with this candidate on what they choose to highlight as their career successes, I've definitely caught dishonest people, or people I wouldn't work with via soft questions. But I'm not sure, I've never interviewed this person.
- Impossible 6y ago
  One question is, if someone is doing elaborate deceptive work like this, gets hired and has no problems performing the job, does it actually matter? Some people mostly or entirely code at work, so this looks like a legitimate way to get a "good" project in GitHub that he knew well. It sucks that it's deceptive (which could be a major red flag), but it's also clear enough that he understood a large codebase well enough to explain it and modify and/or refactor it, which is honestly the majority of a SWE job. A lot of people are concerned about the "purity" of how someone solves an interview challenge, and outside of potential ethical red flags, people that "cheat" the system are often putting in a lot of work, and are as likely as anyone else to be capable of doing the work.
  - grogenaut 6y ago
    No if they had no problems performing on the job then no it's not an issue. Maybe they learned and this provided a good reset for them. Maybe they didn't and similar issues will crop up. I put the anecdote up as a real-world example of one way the GGP's github reference can be faked. You would have to dig really hard into their knowledge of the system to catch them, which you wouldn't have time to do. For instance, I believe the issues would show up in a benchmark.
  - deleted 6y ago
    [deleted]

chrisseaton 6y ago

Ask them some questions about it over lunch? What’s your threat model here? People making up elaborate lies about code they’ve written?

vageli 6y ago
> What’s your threat model here? People making up elaborate lies about code they’ve written? Likely people making up elaborate lies about code they didn't write. It's trivial to push code of which you are not the author.
- chrisseaton 6y ago
  I can’t imagine a situation where you couldn’t work that out with five minutes of casual conversation about the codebase but maybe I’m naive.
- victor9000 6y ago
  Which is why the interviewer should ask specific and thoughtful questions about the project, so they can gauge the candidate's level of understanding. This concern could also be addressed by introducing a trial period.
  - marcinzm 6y ago
    >This concern could also be addressed by introducing a trial period. Why would I leave a stable well paying job for a job that basically says they don't trust me enough to not fire me in two weeks?
    - paulcole 6y ago
      At least they’re honest about it. Unless you’ve got some kind of contract in place (or live somewhere where this is prohibited by law) your current employer could fire you in 2 weeks if they didn’t like your performance, too. They could do it this afternoon even.
    - vageli 6y ago

amiantos 6y ago

Have the interviewee submit repos in which they're the only contributor? But, uh, with a take home project, you _really_ don't know that they wrote the code, either...

keanebean86 6y ago
Do a take-home project but don't make them write from scratch. Give them a mostly working starter application. Sprinkle in some bugs. Start with easy spelling errors and go all the way to concurrency problems. Ask them to add a few simple features and fix any bugs they find. Bonus points if they find bugs you didn't add intentionally. Good unit tests are also a bonus. Give them a couple days or something. Don't count off if they don't get everything done. It's better to do a few things correctly that fix everything with hacks. Invite them to email questions/suggestions to the hiring team. This person might be on your team so it's nice to find out early if they have good ideas or they hound you with stack overflow questions all day. I've never had this kind of interview but it sounds nice to me. It's more realistic to real daily work. You can cheat by having someone else do the work but that's always a possibility.
- asdff 6y ago
  This sounds sadistic to me. I've spent a long time on dumb typos, which become a lot harder to spot when you are stressed and on a deadline. Chances are if you are applying for work, you are probably stressed about not having a job.
  - keanebean86 6y ago
    You've completely missed my point. It's not about being perfect. I want to work with people who leave code better than they found it but I can't expect perfection. I don't care if they can't find all the typos. I'm sure most software has typos. Whiteboardimg a solution to n=np or building full applications is crazy and not realistic. Most interviews do that yet most work is fixing bugs and adding mundane features. Why can't interviews focus on the actual skills needed?

willcipriano 6y ago

"Interesting choice using collections.OrderedDict here, why did you choose that?"

vageli 6y ago
> "Interesting choice using collections.OrderedDict here, why did you choose that?" Without looking at the commit history, given enough time this is a challenge. I often don't recognize code I wrote myself 6 months ago.
- deleted 6y ago
  [deleted]

XCSme 6y ago

I think discussing the projects would be a better solution. The interviewer looks over his projects and asks questions about them, the applicant explains his thought process behind the decisions made.

invalidOrTaken 6y ago

If I'd stolen it, I'd have picked something prettier!

asdff 6y ago

I would assume the best, then in a week when it is clear that they faked their way in you can just lay them off. If they faked their way in but are a great member of the team going forward and contributing to projects, do you really care as a manager?