Before enrolling at Oregon State University to pursue a career change, I wanted to be a lawyer. I took two Constitutional Law classes during my previous college education, studied and took the LSAT twice, and had even put a deposit down for a law school. Studying for the LSAT was an interesting experience, combining sadistic multiple choice questions with brain-scrambling logic. I prepped the same way for both LSATs: head in a book, practice problems, and relentless repetition of problems I just wasn’t understanding. Now, several years later, studying for software engineering interviews feels very similar.
I have my copy of Cracking the Coding Interview, my subscription to LeetCode, and am working my way through the “Interview Prep” course on Hackerrank. Aside from the shared praxis of preparing for the LSAT or a software engineering interview, some of the subject matter also seems to have similarities. Both curriculums are heavily logic and systems based (although of course different in their implementation) and success relies on the test-taker to not just take the question or problem at face value but dig deeper to evaluate what a problem or scenario is really asking. And both require the test-taker to remember and retain information previously learned (months or years prior) but that has since been shoved out of memory in favor of more seemingly urgent, short-term information.
So, like many others out there, in-between writing blog posts, fiddling with margins and padding and why-wont-that-box-just-go-there, I’ll continue – like I did with the LSAT – my focused preparation for interviews with the hope that I’ll be in a position a few months from now where I can exchange a memorized implementation of Quicksort with a Chrome bookmark.
