Hacker News Reader

Comment by grogenaut | Hacker News Reader

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.

View on HN

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.

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.

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.

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.

Reply on news.ycombinator.com