CS theory revisited
As I enter my final term of studies, I will shortly be joining the overcrowded pool of freshly graduated 20-somethings with a computer science degree. In preparation for this, I’ve been reading a lot about people’s experiences with programming job interviews, and have come to realise two things:
- Domain-specific knowledge is less important than I thought it was.
- Job interviewers love to focus on theory.
By theory, I mean things like algorithmic complexity, logic puzzles, and big O notation. As a result, I’m now terrified of the fact that while I consider myself a decent programmer and come out near the top of my class, the fact that I didn’t retain all of the knowledge from my data structures and algorithms module at University may lose me future employment.
Sit me down and ask me to write an application and I’ll get straight to work, but sit me down and ask me the most efficient way to sort one million integers and I’ll burst into tears before your eyes.
Now, while I have little actual experience of job interviews, I can imagine that openly weeping is pretty high up on the list of things to avoid doing, right alongside aggravated assault and calling the hiring manager a tosser. If I’m to have any chance of avoiding this disaster scenario, I need a plan.
Once a day for the next 30 days, I’m going to sit down with my leg-numbingly heavy copy of Introduction to Algorithms and go “back to square one”, covering one topic per day - binary search trees, heap sort, recursion - all the theory that I’ve learned in the classroom but never needed to apply in the real world.
I’ve set up a repository to document my progress, and will report back in 30 days with my findings!