How to deal with an interviewer who thinks I have copied an open source project?

Question

This is an hypothetical question.

In order to gain some practical technical experience, I have started off building a software from scratch whose excellent open source option already exists.

I have examined the features of that open source software and I plan to incorporate them in my software to gain practical experience of programming. I have no plans of peeking into the source code of the already available software.

But, now when I think of putting my work in my resume, I guess the interviewer might think that I have copied the open source project and am just claiming to be knowledgeable about the same for the heck of it!

• How should I deal if they hint anything of that sort?
• Is there a way to prevent any interviewer from thinking that I might have cheated?

• Am I supposed to initiate the talks or do I have to wait for their reaction first?

• What if they say, if your software is not *better than the already existing one then why should one even look at it?

Answer 1

Your question contains the answer to what you should do. You say

In order to gain some practical technical experience, I have started off building a software from scratch whose excellent open source option already exists.

So put that in your resume! So later when you say

But, now when I think of putting my work in my resume, I guess the interviewer might think that I have copied the open source project and am just claiming to be knowledgeable about the same for the heck of it!

That can't be a reasonable conclusion if it explicitly says in your resume something like:

As an intellectual exercise, I am developing from scratch Project Q, which is a {type of software} which I hope will one day have a feature set similar to {well-known open source project}

This invites only positive questions such as:

• Why this {type of software}? What interests you about it?
• What problems have you encountered while developing it? How do the solutions you came up with compare to the solutions in {well-known open source project}?

And so on. You could even use such questions as an opportunity to show your own skills:

With problem P1, I struggled but eventually came up with an approach which, while not as elegant as the solution in {well-known open source project}, has the same performance. However, with problem P2, I had a flash of insight while working on it, and was pleasantly surprised when I checked against {well-known open source project} to find that I had independently come up with a widely-ackonwledged best practice.

Only say such things if they are true, of course...

Answer 2

In this situation the best solution is to have your project open source as well. This allows the interviewer to review your code at their leisure, and in the unlikely event they think you stole the code, they can compare against the other project.

They would not hint at you stealing code (unless it was plainly obvious), but they may ask you why you implemented a certain feature and how it may improve on the existing project.

If it doesn't, you can say you built it for yourself to fix minor annoyances, and/or to improve your coding skills.

If you don't want to go the open source route, they are still likely to ask you those questions. They would not accuse you of stealing code, because they would have no proof and open themselves to litigation in the interview.

Answer 3

In my opinion, a feature by feature clone of an existing product wouldn't weigh very heavily on a resume anyway, so an interviewer is unlikely to care how much of it you copied or not.

Programmers are always wishing they could go back and rewrite old software better. Were I interviewing you about your project, I would mostly want to know what you changed from the original, and why. As a bonus, in addition to looking better on your resume, if you have enough features to differentiate the project, you don't have to worry about being accused of plagiarism.

It wouldn't have to be huge differences to interest me as an interviewer. For example, one of my current hobby projects is a calculator. It's been done thousands of times, so why bother? In my case, the last straw was when I wanted to do exponentiation in hexadecimal mode and my existing calculator software wouldn't let me. I looked at hundreds of calculator programs and gathered a list of features I wanted. None met all my requirements, so I decided to make my own.

Also keep in mind that professional programmers rarely get to start from scratch. Contributing significantly to an existing open source project would give you experience much closer to what professional programmers typically do on a day to day basis.

Answer 4

Just so you are clear, "open source" does not automatically mean "copy at will". Even the most permissive open source licenses (e.g. LGPL, Apache, MIT) have strict proscriptions that you cannot use the software under license without attributing it's source. What does this mean? Generally, it means that while you are free to use, derive or copy the whole or parts of the project you have to include the original license and any copyright notices along with your derived work.

For example, if you take part of the source-code from an Apache-licensed project, make some changes and then include it on your project, the source-code still has to include the original license and copyright text in the source-code file.

This also answers your question. As long as you remain in compliance with the open source license, you should have no problem discussing it openly with a prospective employer since all derived and/or copied parts will have clear notices referring to the original creator/copyright holder, indicating what is original and what is derived/copied.

So, does copying or deriving from existing sources make you a less capable developer? No, it makes you a smart developer as you demonstrate that you're clever enough to not reinvent the wheel. As long as you can motivate why you choose to use certain pieces from other projects, what added value they brought and that you fully understand how they work.

It would also be beneficial if your derived work is an improvement on the original, i.e. adds new functionality or does the same thing but better somehow. Either that or a statement that you did it for pure academic purposes, along with an idea of what you learned from it.

Answer 5

It's a very hypotetical situation and it's quite unlikely the interviewer will rise such concerns.

In real-life (or real-matrix) much more important than writing your code with scratch is the ability to work with existing codebase (reuse it, adapt, bug-fix).

If you're able to take and adapt the existing open source project, or even utilize its existing capabilities in the constructive and creative way, it's a strong point for the CV and the interview.

From my experience, it's of little interest for the interviewers, how much of the codebase you've written yourself. The more important is, how it went production, how it was maintained, integrated and adapted.