To provide a counter argument, because I do not think the attitude should be "I'm not going to do open source because it is useless for programming interviews". Creating an open source library that others use is one of the strongest signals I can think of.
Things that are involved with creating an open source library that I can think of off the top of my head:
- Set up a build system
- Use a test suite
- Choose and follow a coding standard
- Issue tracking
- Bug report system
- Source control (good branching practices/ whatever best practices
your favorite source control promotes)
- Create a specification / roadmap (months of coding can save hours of planning)
- Documentation
a) Determining convention
b) Actually creating clear documentation
c) Updating documentation through changes
- Writing code that just works
And that is all just by yourself. Then if you have users and are building a community
- Communicate architecture to random strangers using
specifications that they understand
- Collaborate to develop roadmap /architecture with input
from other developers
- Communicate in a way as to not piss off strange
developers who decide to help you for free
The understanding of data structures and algorithms are only a small part of the puzzle. If a programmer can demonstrate all of those industry standard behaviors on their own time, then I don't care that much if they don't remember what a skip list or some other crap like that is. You can teach a developer all of the special data structures that your code base uses in a week. On the other hand it can take from months to never of steeping time in order to get developers up to speed with all of the house-keeping I described above.
TL;DR
Contribute to open source, start your own open source project because the skills required cover 90% of what programmers need to know. The CS theory stuff is the smallest and easiest part to train up. Show that you know how to execute well on the 90%, and companies will fall over themselves to train you on their own dime for the tiny subset of CS theory that they use.
Things that are involved with creating an open source library that I can think of off the top of my head:
And that is all just by yourself. Then if you have users and are building a community The understanding of data structures and algorithms are only a small part of the puzzle. If a programmer can demonstrate all of those industry standard behaviors on their own time, then I don't care that much if they don't remember what a skip list or some other crap like that is. You can teach a developer all of the special data structures that your code base uses in a week. On the other hand it can take from months to never of steeping time in order to get developers up to speed with all of the house-keeping I described above.TL;DR
Contribute to open source, start your own open source project because the skills required cover 90% of what programmers need to know. The CS theory stuff is the smallest and easiest part to train up. Show that you know how to execute well on the 90%, and companies will fall over themselves to train you on their own dime for the tiny subset of CS theory that they use.