CS Advice for Students

7/24/2020

This fall school-related, informal in-person interactions are going to be even harder to have than they usually are. But since these interactions can end up being so valuable, I figure I'll put down here the takeaways I've gotten from some of mine to hopefully fill this gap a bit. First I'll give some general "life advice" and then some more CS-specific resources.

My main thoughts on undergrad are this: 1. fuck gpa and 2. side projects are important. These two things end up being closely related.

Getting to Yale, my one connection there was the daughter of a family friend who was a third-year. Her boyfriend was an applied math major who took me under his wing. He was transitioning towards programming and machine learning so we ended up taking some classes together. His first piece of advice to me was to "break the seal" of getting straight A's as soon as possible. For kids who have only ever seen the letter A on their report card, that first B+ can be devastating. But once you realize it's not the end of the world to get a B, it can give a better perspective on how to spend your time in college. For you readers who already have no illusions about graduating with a 4.0 this might sound dumb, but consider that if A's don't really matter, then B's don't either, and neither do C's.

The way I see it is that the workload of a class has two components: the work needed to learn what you need to learn, and the work needed to get an A. In the mythical dream class those two work components actually perfectly overlap. In very good classes the work to get an A is a superset of the work to learn what you actually need to know. But I think in most classes these two work components are almost entirely disconnected. What I mean by this is that your grade in the class is not what you have learned, it is what your professor (or more likely, overworked and underpaid TF), thinks you have learned. Who cares what they think? Once you recognize that certain work required to get an A is not actually helping you to learn, and that it just doesn't matter if you get an A or not, then it frees you to prioritize different and more valuable work.

To try to prove my point that grades and learning are totally different things, I humbly submit my own record. Of my 12 computer science classes, only in 4 did I get a full A (and it's no coincidence that all of those involved big open-ended projects).

Despite the story my grades tell, I learned so much in all of those classes and I feel only gratitude for my professors. And I still aced the interviews for Facebook back when working there was cool (my thoughts about Facebook have changed, to say the least). At the beginning of CPSC 223 and 323 Prof. Eisenstat would explain the curve of the class. How something like the bottom 1/8th of the class would get a C+ or below. Anecdotally, most of the people in that bottom 1/8th were dropping the major. But you don't actually have to if you feel like you're still learning what you need to.

Following this advice is easier said than done, though. Without any other form of feedback, it can be difficult to tell if you actually are learning what you really need to with a C+ staring you in the face. However I think computer science is unique in that you don't need anyone's permission to create your own stuff. Which leads to the side projects.

It's kind of a meme at this point that successful tech gatekeepers expect applicants to do side projects "for fun" on top of all the other shit they have in their life. My thoughts are a little different in that I think you should be doing side projects instead of the regular busywork. I think this work opens doors that mere A's do not, and there's nothing that proves you've learned something like deploying a website, making a little video game, writing a web scraper, or even just making a button render on the screen that depresses just the right way when you click it.

On the career opportunities front, my informal mentor I mentioned above wrote a toy neural network just for the hell of it. He showed it to a professor and the professor said this toy was better than the neural net setup they had at CERN and invited him to Switzerland that summer to fix theirs. Similarly, a friend and I made a lightweight chrome extension called Tab Team to help us organize our many many tabs across different topics. I didn't think it was a big deal, but every Facebook (and later Google) interviewer picked it out of my resume to talk about.

I don't think we as students should be doing projects just to make ourselves look better to our capitalist overlords, though it can admittedly come in handy. I think we should also prioritize fun projects because that's just what we want to do. And the best side projects are those that we can also submit for a grade for a class assignment. One of the saddest missed opportunities that a student can fall into is phoning in a class project they were actually super excited about because they feel pressure to also put a lot of time into the useless busywork assignments needed to get an A in some other class. If a project gets you excited to get out of bed in the morning, for a class or not, then freaking do it! Phone in the busywork and do the project that gets you going because that's your real ticket.

I think among Ivy Leaguers there's also a pressure to be "on" all the time and that everything you do should contribute to your resume or career opportunities. Ivy Leaguers only give themselves a pass when it comes time to get drunk. But I think it's also important to have sober activities that you do just for fun, especially if they are social. For me these were rock climbing and peer tutoring. But I also loved (and still love) to fiddle around with cellular automata.

This has started to get long and rambly. Hopefully this is helpful, non-obvious advice! As far as CS-specific technical resources, I'll describe a few here:

CS Resources

Project Euler is the best one. It's a series of math problems that get progressively harder as they go. They are all theoretically solveable by hand, but the intention is that you will use code to solve the problems. When you enter the solution, it unlocks a forum available only to other people who have solved the problem where people discuss how they did it. The problems scale in difficulty well (problem 1 is fizzbuzz) and reading the insanely optimized or esoteric ways other people have solved them is great. If you can solve the first 50 problems then you likely have enough CS know-how to get by as a FAANG engineer. My friend key is: 270560_73ecdcbbea6ff54d16e466ef3a8fae6b if you want to compete ;)

For a challenge, try solving the problems in a language you don't know, like prolog, or Forth, or maybe Piet (check out the sample programs!)

Bret Victor makes amazing demo-essay hybrids that explore programming and design concepts: worrydream.com

This humorous page shows different, increasingly ridiculous, implementations of the factorial function in haskell. Trying to actually understand some of these is a good exercise.

For tech interview prep I used Interview Cake. Back then more stuff was available for free, but it seems like you can still get pretty far with their resources without having to pay. Though honestly solving project euler problems is also a good way to get in this mindset.

Here's another good CS blog. This essay in particular explains the difference between compiled executable programs, interpreters, and compilers, in a way that is more fundamental than the mere mechanics of using interpreted/compiled programming languages.

Finally, not a link, but the book The New Turing Omnibus by Alexander Dewdney is a great CS resource. Each chapter introduces another CS concept, is only like 5-10 pages long, and has thoughtful exercises at the end. I went through this book the summer before going to Yale and did not encounter a single entirely new concept in Intro to CS as a result (though it was still good to go over them again and implement them all in Racket). The chapter on neural networks provides some Basic-like pseudocode which (I think unintentionally) has a couple critical typos in it to make sure you really understand the concept if you want to implement it yourself (ask me how I know this...).

Back to Blog