Now that I’ve got the website up and running and I’ve spent a few days coming up with things to do, I figured now’s a good time to put down my ideas.
My first idea is to have a weekly check-in blog post, where I summarize what I did and what I’ll do next. Back when I was a student, if I had a particularly big task ahead of me (say, writing a paper) and a tight timeline to complete it, I would create a running thread on Facebook where I’d post a new update every hour with my progress. By publicly tracking what I was doing all day to get the task done, I felt the necessary pressure to stay on task and deliver rather than waste time slacking off. Essentially, this weekly blog-post is just the more formalized version of that.
The goal I’ll be working toward and documenting, naturally, is getting hired – but it’s not quite that simple. As I said in my relaunch post, updating my resume and throwing it at LinkedIn every day just isn’t enough, and even if it was, I’d go mad in the meantime from the waiting. Employment Insurance means that at least I’m not diving (deeper) into debt while I wait, but that doesn’t mean I want to just sit and wait for either someone to notice me or January’s sessional instructor posts to open up.
I want to do a comprehensive overhaul of my work materials, my skills, just about everything that I supposedly depend on to earn a living and make an impact in the world. The first couple weeks of looking around for jobs has convinced me that my available work samples and resume items are just too messy, too idiosyncratic to fit the profile of a hireable engineer.
So that leads me to my next big idea, which I’m calling Project Fundamentals.
Project Fundamentals
The main thing I feel like I’m missing as a worker in the tech sector is a block of code that clearly demonstrates all the basics expected of a software engineer. Something a supervisor can briefly scan and nod to themselves that, yes, this guy knows how to produce software. A portfolio centerpiece, not necessarily the best, most important, or flashiest work, but something that gets you in the running.
I have code, of course, but as a lifelong academic and student, it’s always been short-term and ad-hoc, meant to complete a personal assignment or research project. It hasn’t required the sort of project management, documentation, maintenance, or just the all-around depth and complexity expected of modern software development in professional environments. The best I have to share are the projects I used as part of my PhD research, and while they served their purpose admirably for data collection, they weren’t made to showcase programming talent.
The second thing I need, as I came to appreciate while taking technical interviews last year and over my terms of teaching undergrads, is to knock the rust off my actual programming fundamentals. I’ve never been one to code for fun, and it’s definitely a skill you need to keep in shape. Long years of grad school let me focus only on whatever I needed to know to get through the next project, rather than maintaining a strong and diverse toolset – why would I, when I could focus on big ideas and grand visions of the future?
To meet both of these needs, I’ve come up with a project that puts the coding practice website LeetCode at the center. This website, for the unfamiliar, is a place where you can tackle practice coding problems, the sort of which you might see on a technical interview for a software developer job. It’s a fairly well-featured website, allowing you to submit and test your solutions to hundreds of problems. It also includes a suite of study plans that assign you daily problems in an order meant to cultivate your skills at certain common programming tasks.
I’ve decided to tackle each of the three two-week study plans that LeetCode offers, which should see me solving a hundred or so such programming questions on topics related to data structures and algorithms – all good core material. The process should take six weeks, and the requirement that you complete each day’s tasks within 24 hours is a good way to ensure I stay focused. I’m already four days in, and the process has been pretty rewarding.
Completing the questions themselves is good training for a technical interview, but it also gives me a body of code work I can then use as a basis for the rest of my project. The idea is to turn my collection of answers to LeetCode’s questions into a project that can also showcase my other technical and programming abilities. The truth is that only a small part of software development is typing the code itself – testing, interfaces, version control, there are a vast number of facets to a successful project. By using my LeetCode as the kernel, I can build these around it into my go-to portfolio piece for software development work.
The exact features I have in mind for this project are still only a rough draft, but I’ll list them here to help along the process of turning them into a real development plan. I’ve also split them into phases that loosely represent the order I expect to tackle them.
Phase One
–The Code: Completing LeetCode’s study plans to generate ~100 solutions to common coding problems, demonstrating strong data structures and algorithms fundamentals.
–Version Control: Using Git and Github to keep my project backed up and available to the public.
–Testing: Use JUnit to create unit testing for each of the solutions.
–Documentation: Good code comments, of course, but also a Git readme, and clear instructions as part of the interface and testing suite. This blog isn’t part of the documentation, it’s just a personal log.
Phase Two
–Graphical User Interface: A slightly more advanced interface, maybe packaged into something else, like a browser-friendly version?
–Agile & Scrum: Admittedly, you’re not supposed to apply a software development model like Scrum retroactively, but once I’m more situated I’d like to find a one-person Agile methodology I can use to demonstrate those techniques.
–ER Modelling: An extension of documentation, produce some models and diagrams to support the existing documents.
Phase Three
–Network Compatibility: An online version, accessible via this website.
–Database: Tie SQL in somewhere, maybe storing the data used by the unit tests?
–C++: Rewrite the whole thing in C++, just to show that I can do that language too. This is a real long-term goal, since it probably involves re-doing the LeetCode assignments again.
I have a number of other ideas I’d like to explore as part of my professional self-improvement, but this post is already quite long enough, and I think I have enough work in front of me at the moment. I’ll report back next week, hopefully having completed seven more days of LeetCode problems and having begun to implement some of the features I outlined above. Until then, and if you’re actually reading this massive post, take care.
Dr. Jack Thomas 