Kirk Lange

From Zero to Google

Thu, 31 Jan 2019 17:00:00 +0000

My biggest takeaway from what has happened to me this past year-and-a-half is that LeetCode-style technical interviews are not something one can be naturally good at. Regardless of how impressive your GPA is and how many years of hobbyist coding experience you have under your belt, you’re going to need to grind at least a little bit of LeetCode and read through CTCI in order to ace that next interview. If you remember only one thing from this essay I want it to be this, that technical interviewing is its own distinct skill.

Internship Attempt

I had no idea what I was doing while applying for summer 2018 internships during the 2017-2018 academic year. My summer 2017 on-campus research and at the time eight years of hobbyist video game programming experience made me overconfident. As a result, I applied to too few places, less than ten, in fact, of which I only heard back from two: Exact Sciences and Amazon. I did just fine in the Exact Science non-technical phone interview, but overconfidence overcame me yet again; I sent the usual thank you email right after the phone interview was over, but I never emailed them back asking for an update because I decided to take my chances and wait until after my phone interview with Amazon which was set to take place the following month. And what did I do to prepare for my Amazon technical phone interview? Nothing more than skim through CTCI just days before the call.

At the end of the interview my interviewer asked if I had any questions. I asked something along the lines of what are some good ways for undergrad students like me to prepare for internships at these big companies. He said that I should gain some experience by doing coding projects outside the classroom. I was self-taught from 5th to 12th grade. Programming is my out-of-class hobby…

In desperation, I emailed my Exact Sciences recruiter to see if I could still move forward with them. The position had been filled. I continued to send my resume out to a few places here and there, but as May emerged over the horizon, the prospect of being “self-employed” became evermore certain.

“Self-Employment”

As much as I would have liked to have an internship and as crushing as my Amazon interviewer’s comment was earlier that year, I must admit that up to that point those summer months of 2018 were some of the best of my life. I had three full months all to myself. I could read whatever books I wanted and work on whatever projects I wanted. I confess to not having had the greatest discipline, I wasn’t clocking in full 40+ hours of coding per week until August, but as the title of this essay gives away, that was just enough for me to make the grade.

I had the crucial choice at the beginning of my summer to either expand the breadth or depth of my skill set. I could either learn new technologies like ReactJS, Node.js, Unity Game Engine, etc., or I could dive deeper into C, C++, OOP, and scripting. I ended up choosing the latter because I figured that would give me the best chance of creating an impressive, resume-worthy project by the end of the summer since I already knew a fair amount about those topics. This ended up being the best decision I have ever made since I was able to create the EzAF suite of projects that went on to impress my Google and Synopsys interviewers. Of all the programming books I read over that summer, the one I owe the most to is API Design for C++ by Martin Reddy. Read through that book and my code for EzGL and you’ll see the correlation!

Round Two

In preparing for my full-time 2019 applications, I have r/cscareerquestions to thank. Although reading too much of that subreddit leads one to self-doubt, what I did learn was worth it at the end. The weekly resume threads were especially helpful. It was very enlightening seeing how others similar or more advanced than me were writing their resumes, and to my surprise, when I posted my own resume drafts, I got a good amount of constructive feedback. This is where I was introduced to the Deedy Resume, a resume template tailored to undergraduate computer science majors. Also in this subreddit was where I was introduced to the infamous “LeetCode grind”. While I never did anymore than about fifty-or-so problems over the course of a couple months, I felt like I did do enough such that I got a handle on the most common “idioms” as I like to call them, that is, categories of solution such as sliding window, tree traversal, 1D dynamic programming, 2D dynamic programming, sorting, etc. The way I see it, the less LeetCode or other interview practice you do, the more you are relying on chance to get an interview question that you are comfortable with. The more interview practice you do, the wider of a range of questions you will be more comfortable with and thus be more likely to ace whatever the interviewer throws at you. I must also say that doing mock whiteboard interview practices with another person is invaluable. Getting to test your code on LeetCode is one thing, but having to write syntactically correct, error-free C++ code on a whiteboard is a whole other game. For this, I would recommend asking a CS friend or professor to pretend to be your interviewer giving you LeetCode-style questions.

Now more knowledgeable and better prepared than last year, it was time for me to solicit my resume. I applied to about twenty companies across a wider range of fields and locations than last year. Yes, I should have applied to more, but I received responses from a few companies relatively quickly and was busying myself preparing for their interviews rather than applying to even more places. I heard back from ten of them, five of which said no to my resume (including Booz Allen and King Digital Entertainment), the other five of which moved me forward through the application process. Of those five, I didn’t pass two of their technical phone interviews and/or online coding tests (Stevens Capital Management and Amazon), and the remaining three I went on to do on-site interviews and receive offers (Epic Systems, Google, and Synopsys).

Closing Thoughts

This essay is not a guide on how to get into Google. Do neither as I say nor as I do. There are definitely better and less risky paths towards receiving an offer from a Big-N than what I have taken. This is just my account of how I miraculously went from having zero internships to a full-time job offer from Google.

Lastly, don’t forget what I told you at the top of this essay: technical interviewing is its own distinct skill.

Mirroring Repos with GitHub

Wed, 06 Jun 2018 13:00:00 +0000

As I was migrating from GitHub to GitLab on Monday*, I began to imagine the awkward conversation I would have if I was ever in a Microsoft interview. Heck, the GitHub vs GitLab discussion feels like it’s on its way to becoming a religious debate like tabs vs spaces — the last thing I’d want to get into while networking.

After sleeping on it, I decided the best solution would be to have GitHub mirror all my GitLab repositories. That way, anyone I’m showing my code to can use their prefered platform and I don’t have to risk getting into an argument. Only problem is, unlike GitLab, GitHub does not have a “Mirror Repository” option when creating a new project… Time for a work-around!

Solution

As it turns out, git allows you to push to multiple URLs simply by adding one line to your .git/config! Here is the relevant excerpt from this website’s repo.

[remote "origin"]
    url = git@gitlab.com:kirklange/kirklange.gitlab.io.git
    fetch = +refs/heads/*:refs/remotes/origin/*
    pushurl = git@gitlab.com:kirklange/kirklange.gitlab.io.git
    pushurl = git@github.com:kirklange/kirklange.github.io.git

Whenever you execute git push, it pushes to each pushurl. Even if you are pushing to two remote repos that aren’t in sync, git will account for this and push what is necessary to each repo. In other words, if you’ve only been pushing to GitLab since you switched, your GitHub repo will catch up like nothing ever happened. (Even your green squares should sync up!)

If you also want the ability to pull from your secondary repo, you’ll want your .git/config to be of this format.

[remote "origin"]
    url = git@gitlab.com:kirklange/kirklange.gitlab.io.git
    url = git@github.com:kirklange/kirklange.github.io.git
    fetch = +refs/heads/*:refs/remotes/origin/*

However, it’s probably best not to pull from your secondary repo as to mitigate the chances of having to tediously merge the two. Afterall, the goal here is only to have the GitHub repo act as a mirror.

Disclaimer

Fine, this is technically not “mirroring”, but until Microsoft catches up to GitLab in terms of its extra features, this is the best we can do. Please let me know if you have a better solution. If anything comes up, I’ll make sure to update this post and give credit. Thanks!

Source

Stack Overflow: pull/push from multiple remote locations

*Addendum

The real reason I switched to GitLab (for now).

I don’t give a damn whether GitLab is hosted on Azure or Google Cloud. I am well aware that Microsoft isn’t going to claim my code and that they don’t care about my rushed AI class project that is in freakin’ C89 for no good reason. What I care about most is how easily I can host, share, document, and test my projects.

In the past couple of years, I’ve been moving away from Microsoft software in general, going from Visual C++, Visual Studio, and Windows, to GNU, Vim, and (at least on my laptop) Ubuntu. The aquisition prompted me to revisit GitLab because I wasn’t sure whether Microsoft would move the platform in a direction that I would be interested in. Earlier this year, a classmate introduced me to GitLab but I brushed it off because I didn’t understand all that it had to offer.

After importing a couple projects to GitLab and tinkering around a bit, I was pleasantly surprised. A couple pet peeves I had with GitHub like pull request permissions and of course the ability to host private repositories were solved with GitLab. Additionally, having CI built right in to GitLab is pretty nice since I use it extensively to run unit and cross-platform compatability tests. That is not to say that GitLab doesn’t have its own issues. I definitely may find more in the future as it’s only my 3rd day using GitLab, but I figure where’s the harm in trying it out for a couple weeks?

Thanks to the fact that I’m pushing all my repo changes to both GitHub and GitLab, I can easily switch my main platform at will. If GitLab has another database outage, no big deal, most of what I care about is probably still on my local machine or on GitHub. If Microsoft ruins GitHub for me, also no big deal. The more options the better, for both me and the people I am sharing my code with.