I am a self taught developer. I had the benefit of a dad who gave me a computer and helped me write some programs. The TI-81 and TI-85 calculator were the laptops of my school days. I spent many days staring at the manual for that calculator as I learned to program a solution to physics problems. I turned out to be better at coding a solver than actually solving the raw problem
I only had a couple of college classes before I dropped out; the most important of which was data structures. This class unlocked actual programming to me. During this class, I started a small company with a friend of mine and dropped out of school. If I could not figure something out I would go to the bookstore and buy a book adding a new tool to my toolbelt on an as needed basis.
Then my company went out of business…
I was lucky enough to land a job at a small software company just after I turned 21. Until this point I’d never worked on a system I hadn’t built though I was a couple of years into my programming career. It was humbling to spend the first couple of weeks trying to get the local development environment up and running. With some help I did, and I was eventually able to contribute code to that company.
The hardest lessons came when I decided it was time to move on from that company. I spent two years interviewing at different places trying to find my next position, and learned that I was only likely to get a job offer if the hiring manager was themself also a self-taught developer. These were some very hard times for me. And I am pretty confident that I am not alone in this feeling.
Feeling stuck because the coding interview feels insurmountable is a rough. It can feel like the next career step is just too high. This was the process I went through to help make my interview efforts a bit more successful. Being able to interview well enables folks to stay where they are because they love the work and not because other opportunities are out of reach. I hope this process will help lower the stress of interviews and improve the success rate. Lastly, I found it to be useful at my job to add in a bunch of tools I never knew existed.
The first step in starting an interview process is to realize it can be very stressful. You will likely have some poor interview experiences. I found myself leaving interviews questioning my worth in the world. I generally try to take this opportunity to remind myself:
- Interviews and interviewers are as flawed as I am.
- I know I am capable of delivering value.
- I am a good person and this is true whether or not I “pass”interview is
Whether or not I connect with the interviewer’s interpretation of my performance. I am (you are) worthy of this profession regardless of a single or string of unsuccessful interviews.
I initially did too many interviews to count but I recall getting about 2 offers after 10 on-site interviews. This was a lot of work for a meager payout (even the offers I got were a low comp).
A former mentor gave me a push in the right direction and I was able to move to a new position. The skills I learned to improve my performance during subsequent interviews have stood up well in the many times I have been either the interviewee and interviewer.
Take that algorithms course
I took this Algorithms Course on Coursera by Tim Roughgarden though it is not the only choice. This course takes time to complete and for me forced me to face some of the hardest challenges I’d ever faced in my programming career. This course helped me to overcome challenges and grow in my capacity and confidence. Taking this course will not only allow one to put a crack in the wall of the coding interview, it will be the nexus of much of the rest of the advice in this article.
When I was first interviewing and got algorithms questions, I was paralyzed. I hadn’t needed them in my day job and hadn’t learned them. Further, when I’d press interviewers about where they used a particular algorithm I never got a great answer. This dichotomy of questions not related to performance of one’s job frustrated me. Algorithms, like Djikstra’s search, finding a cycle in a directed graph, or descending a tree can be amazingly fun when one isn’t under the scornful or bored gaze of another programmer.
Taking algorithms teaches that: It is fun to write code that can objectively be measured as correct.
Much of the modern web developer’s code isn’t algorithmically challenging to write. Figuring out what to write, dealing with the meetings and documentation and changes in requirements are hard, that’s why we care so much about developers being good communicators. If Product Managers knew what they wanted a feature to do, they could write the code themselves.
Solving an algorithm based on the scaffolding provided in a course is hard, at least relatively speaking. In fact, this is why for people who’ve studied them, they make for great coding challenges. Typically for an interview one is given a problem that can be solved in less than an hour and the interviewer can infer the applicant’s ability to do an objectively harder algorithmically challenging problem. So, the interviewer infers a correlation to one’s ability to wrangle text into and out of a database.
Studying these algorithms outside the stress of an interview will be like a kata in karate. It gets burned into muscle memory to do something very hard in a low stress environment, when stress is introduced the body is ready.
Taking algorithms helps one learn how to do hard work while smiling
Learning introductory algorithms helps with interviews. It also helps with the day job. One adds a whole new suite of tools to their toolbox. A hand rolled algorithm doesn’t often go into production. But knowing algorithms takes an n-cubed problem and turns it into an n log(n), this might save the company hundreds of thousands of dollars in compute.
Once Algorithms have been conquered: Learn a new programming language.
Many computer science curricula require engineers to learn several languages. In fact, this is extremely important today as the average developer can find themselves working in JavaScript, TypeScript, PHP, Terraform and probably Go all in a given week. I’m not sure why we (coders) find ourselves in this state, but learning a new language is super freeing. And guess what, you just took an algorithms course, that has some solid correct answers, which you can use as a model to learn the new language.
Try out projecteuler.net, early in the first 20 or 30 problems solid math research is required. Don’t let math become the problem focus on coding not math. Work through a few of them in a language you understand well, then pick a new language you read about on hacker news and solve that same problem again. If you throw a couple unit tests on it and a nice README, perhaps it might be a good idea to put it up on GitHub. So an interviewer can see some your capacity at its fullest. Coding in a quiet place with sufficient time is a much better example of ones performance.
Learn LISP.
Lisp is an early programming language (thanks, Wikipedia). It was the second high level language after Fortran from back in 1958. Most developers have only used c-like languages, and this is definitely very different. Further, it’s macro system allows developers to address a problem by designing a specific language for that problem, then coding in that language. Paul Graham explains well the benefits of this language in the linked article. Note: there are many dialects:; pick one. I did Clojure. I haven’t become a master. I did a few Euler projects and a couple of algorithms so I got a feel for the language. Fortunately this coincided with functional programming making a comeback in Java, and I was able to grok this much faster, having luckily looked at Lisp. (Lastly, if you take this on, one more xkcd comic will come alive for you.
If you are still reading I appreciate it. If you choose to go down this path, you may be approaching the end of the double digits of hours. Remember, this puts you into the arena with individuals who put these hours in while in college or perhaps on their own. If you want to command the top salaries in the world, you need to have the top skills.
One final topic, and it’s a doozy: Distributed Systems Theory.
You don’t need to know everything about this big topic. However, you are already working on a distributed system. You probably have a datastore, a web server, and a client. Because the speed of light isn’t instant and a connection between any two points in a network can fail. Learning about distributed systems will help you realize that failures will occur, we can know generally about these failures, and if you plan for them you can mitigate the consequences.
Read up on CAP theory. Aphyr, has a great blog and if you are extremely brave you can see him destroy many different datastores by forcing partitions upon them. I certainly do not understand all of it, but I have taken away some great lessons.
This is a long journey to undertake. The reward for this effort could end in more money. However, the peach of mind that comes from being a better interviewer is amazing. Interviewing is, and will remain, hard. It requires practice. I would recommend taking an interview at least once or twice per year. Remember we began to improve interview skills so you keep your current position because it is your choice from an abundance and not fear of the unknown. Finally, You will be ready if you are forced to start a job search at a time not of your choosing.
I’m a great believer in luck, and I find the harder I work, the more I have of it. ~ Thomas Jefferson.
Take care,
Nathan