It depends where they are in their journey. The right answer is "both" because each implies different skills. Working on someone else's code base, and contribu

It depends where they are in their journey. The right answer is "both" because each implies different skills. Working on someone else's code base, and contributing value to it, is probably what your job will entail. So demonstrating profiency in that area is no bad thing. Being able to articulate that goal, and the lessons gained from achieving it will certainly help in an interview. Bonus points if you strike up communication with the author and get their input on what they would like done. Communication skills are critically important in any new-job context. Aside: willingness to write docs and tests while learning a new system will both improve your understanding, And improve your skills at the same time. Building your own project shows a different set of skills. Identifying a problem (even if its only a problem to you), scoping that problem (avoiding endless feature creep), executing the solution and so on are all great in an interview. Again, while this is great, articulating it in an interview is where the value lies. Be honest about the challenges, what you learned, what you would change. Too many programmers think getting their first job is based on programming skill. Of course that's a big part of it, but a bigger part is communication skill.