RP-3/BradfieldCSIReview.md Secret

## BradfieldCSIReview.md

      
    Raw
  

              BradfieldCSIReview.md
            
          
    My experience of the Bradfield Computer Science Intensive

TLDR


I think Bradfield's CSI is awesome
You will learn a bunch of things that you are:

unlikely to learn on the job; but, nevertheless,
very likely to use at the very same job.


If you are determined to stay a front-end specialist for the rest of your career, this probably isn't for you.
It will take a lot of your time.

You get out what you put in.
If you can't put in at minimum 10 hours a week (I put in 20-30, more on that later), this probably isn't for you


But if you think computer science is cool, and you want to actually understand what you're doing, and learn to think critically, systematically, and quantitatively about the supercomputer(s) you watch cat videos on, you will probably love this programme.

My Background and Biases


I graduated from a bootcamp (Hack Reactor) in 2014
I've worked at a bunch of companies you've never heard of
I do not work right now. I'm doing Bradfield CSI full time until I start at either Facebook or Google in January 2021 (still deciding)
I'd taken five Bradfield courses before signing up for CSI
Right now, I live in Sydney, Australia. So while classes are in the evenings in PST, they're at about 10am for me.
I've finished two modules of the course so far. That's about 25% of the way through.

What does CSI look like in practice?

Live instruction consists of two classes a week, each 1.5 hours long. I think the expectation is that you spend 4-8 hours on the pre-work for each class. Sometimes the prework is open-ended, and sometimes it's tightly scripted with a test suite. The class will open with the first half hour on Q&A, and the remainder following a (usually) loosely scripted foray into whatever the topic at hand is.
I say "loosely scripted" because the consensus at Bradfield seems to be that it's more important to cater to curiosity than curricula, so a class on B+Trees could easily end up spending most of its time on serialisation and caching strategies for disk access.
Class sizes are < 20 and classes are 100% remote. I worried that over Zoom this would be unwieldy but it turns out that Zoom gives you a pretty effective illusion that there are only eight people in class, because that's all it fits in its little side panel. I also worried that 20 would be quite big (in-person Bradfield classes were ~12 people), but the reality is that both Oz and Elliott usually end up sticking around after the class's 'official' finish time until everyone's questions have been answered.
My cohort-mates are universally smart and kind people, which goes a long way. Most work at companies that you've heard of and have been engineers for 2-5 years. I'm probably at the older end being a relatively-early bootcamp grad but by far the biggest distinguishing factor between students is probably the time they have available to put into the programme.
Lastly, the majority of the time you spend working on things in this class will be tinkering at pre-class assignments. The difficulty of these vary, and depending on where you are in your career they will test you. You'll be working with fiddly low-level things a lot in this class, so you need to have sufficient judgement to know when, for your own good, to write a little unit-testing suite, or when to break things down into logical abstractions, or when to hack something together and tidy it up later. These things will come up tangentially in the class but are not taught explicitly. I think a good benchmark for yourself is "Can you watch a random video on computerphile and implement that idea yourself comfortably in half a day without guidance". If yes, you're probably at a high enough standard for CSI (my opinion only).
Module 1: Computer Systems

In this class we learnt how a CPU actually works. We built a simple virtual machine in Golang to get familiar with the Fetch-Decode-Execute cycle, then studied binary encodings in depth before getting to the meat of x86-64 assembly. I'd previously taken Computer Architecture as a standalone course with Bradfield but the CSI systems course is much more hands-on. If you haven't studied CPUs before (likely, given you've read this far), here're three quick self tests you can use to find out how naïve you are about the subject.

Which of the following (if any) is significantly faster than the other?

(a) Summing up the integer values of a linked list storing numbers
(b) Summing up the integer values stored in an array


Which of the following (if any) will run significantly faster than the other?
// Create an array of 10 million random integers from 0-100
int oneMillion = 10000000;
int dataSize = oneMillion * 10;
int result = 0;
int* data = malloc(sizeof(int) * dataSize);
for(int i=0; i<dataSize; i++){
   data[i] = rand() % 100; // random int between 0 and 100
}

// OPTION A: Sum up all the numbers
for(int i=0; i<dataSize; i++){
   // add up the nums <= 100 (all of them)
   if(data[i] <= 100) result += data[i]; 
}

result = 0;

// OPTION B: Sum up just the ones < 50
for(int i=0; i<dataSize; i++){
   // add up the nums < 50 (~half of them)
   if(data[i] < 50) result += data[i]; 
}

// Question: Which will run faster; option A or option B?


What will this print in your browser's dev console?
"🎉".length


If you confidently answered (b, a, 2) and know why, then you've already grokked the foundations of what you'll learn in Systems. If you didn't, well, you're in for a ride!
Bradfield's systems teaches you to reason about things like this from first principles. You'll learn to look at the first (linked list) and realise that it has terrible cache locality. You'll reason that dereferencing a pointer in main memory will take a couple of hundred nanoseconds. You'll note that after the initial fetch in an array, you'll be summing up things almost entirely in L1 cache. You'll know that L1 cache references take < 1 nanosecond and reason that summing the numbers in an array should be about 100x faster. If you're feeling particularly good about it, you might even imagine what the C code for this would look like and do a line-by-line estimate of how long each operation should take. You'll realise that if your language and CPU support SIMD instructions the array addition will be effectively parallelised and probably be four or eight times faster than your original estimate. And if you're like some people in my cohort, you'll whip out Agner Fog's instruction timings and estimate, pretty accurately, how long this program would take to execute for a given list on a given intel CPU after hand-writing the x86-64 assembly yourself.
These are superpowers. As programmers, especially web developers, we work at progressively higher levels of abstraction, seldom understanding what we're actually doing. And sometimes, abstractions leak. If you were designing a twitter-like service, would you restrict users to 240 characters, or 240 bytes? Do you know the difference? What does your decision mean for non-english writers? What if you were writing a customer feedback form that's limited to some number of characters in Javascript? Could you count the number of characters in a string? How did you account for emoji? If you don't understand what character encodings and the unicode table are, you're virtually guaranteeing yourself a firefight and a nasty bug report in the future.
Well, there are two ways you can approach learning this stuff. You could study UTF-8, and read a bunch of articles, or you could learn about computer systems generally, memorise nothing, and be able to work everything out from first principles with a few pivotal facts at your fingertips. To my mind, this is what you'll learn in CSI's systems.
And of course, you learn that through a bunch of hands-on exercises. You'll learn to translate C code into nasm x86-64 assembly yourself, writing a few simple recursive and iterative programs in assembly. You'll write a fast matrix multiplication in C using SIMD instructions and what you've learned about branch prediction, pipelining, parallelism and cache locality. And you'll practice this stuff by implementing a kernel convolution on a JPEG image in Golang, and trying to make it as fast as possible.
To be clear,  I loved every second of CSI's Systems.
Module 2: Practical Data Structures

If you went to a bootcamp like I did you're probably familiar with hash tables, linked lists, various trees and other basic structures. But the production apps and systems we rely on today have waaaay more stuff going on. Relational databases are built on top of B+ Trees. ElasticSearch, LevelDB and a bunch of write-heavy workhorse data systems are built using Log-structured Merge Trees. Set cardinality is computed memory-efficiently with HyperLogLog. Bloom filters are everywhere. There're a ton of things that your bootcamp never got into that are nevertheless used in practice and are very, very cool.
Well, in this module we get to implement and understand the intuitions behind each of these inventions. We've implemented most of them so far (I submitted my own HyperLogLog implementation just this afternoon 🎉), but where I think studying these really comes in handy is in understanding the internals of systems you probably use at work everyday and are mystified by.
The story-arc of this module sees you through implementing the components of LevelDB. You'll make your own bloom filters to avoid expensive disk reads, write your own skip lists to maintain a sorted set in-memory, come up with a compact serialization format to flush your sorted set to disk, and then write up a little compaction algorithm to understand the tradeoffs that make something like a log-structured merge tree as ubiquitous as it is.
Along the way there are brief forays into Merkle Trees (to efficiently locate diffs between large files, and also prove various facts in cryptocurrency implementations), roaring bitmaps and B+Trees. Complete or partial implementations of these are optional. I made my own Merkle Tree and run-length-encoded bit sets, but never got around to B+Trees.
In general, there's plenty of cool stuff to do and Elliott was pretty happy to assign you "stretch goal" implementations if you're feeling particularly brave.
Other modules

I’ve now completed two out of eight total modules. From here, I have Computer Networks, Advanced Programming, Operating Systems, Relational Databases, Distributed Systems and System Design and Operation to go. There’ll also be a final capstone project and “thesis defense”. There’s more info about all of the above here.
One thing I skipped over is the self-guided prep phase. CSI technically starts with 1-2 months of preparation, to bring everyone up to a similar level. The prep-phase curriculum is pretty broad, covering basic algorithms (graph search, heaps, backtracking etc), discrete maths (n-choose-k intuitions, logs etc), C (sufficiently well-understood to reimpliment ls), Go (sufficiently well-understood to write a little web server) and unix utilities (grep, sed, awk, ps, and their ilk). This was guided along by weekly checkins with Oz and Elliott, typically on Wednesday nights (PST).
Most of this was familiar to me but to have a structured curriculum was useful since it provided little milestones for me to reach in my spare time. Weekly checkins, by the way, still occur over the duration of CSI and are both invaluable and fun. Sometimes there's a guest speaker (typically a senior engineer with relevant experience to whatever we're studying, but also sometimes just people with interesting perspectives and stories to share), but most of the time we'll either chat socially or have Oz/Elliott answer ad-hoc questions that popped up during course work.
Should I do CSI to better my career?

I don't really know how to answer that. There used to be a tradition at Bradfield in-person classes that we'd start the first class by having everyone introduce themselves and describe what their aspirations are for the course, and what they're hoping to get out of it. I was typically the only person in there whose answer was "I dunno... I just like knowing this stuff ¯_(ツ)_/¯". In hindsight, and having done a job search recently, I have a more nuanced answer.
As I said earlier, I'm a bootcamp grad, but on paper, I have six years of engineering experience. This means that when I applied to big names for the first time (Google, Facebook and Amazon), the recruiters slotted me in for "Senior Engineer" roles. I don't need to tell you how intimidating this is. "Googler" is our generation's alias for punchlines that end in "Sherlock". I am no Sherlock. In my mind, there was no way in which I was going to be a "Senior Software Engineer / Tech Lead" at Google or Facebook. Especially as a bootcamp grad.
I read a few articles that were part of the 'free tier' of popular online system-design courses, but for the most part I've never worked with big data systems, so didn't want to fake it and get caught out. I've read the Dynamo and Spanner papers while studying databases at Bradfield but if you asked me whether your app should use Cassandra or HBase I'd have no idea unless I went away and read about them for a few days.
Knowing this, I took a few months to brush up on my algos and deliberately did not study system design. I figured I'd excel at my strong points, get docked a few points for seniority since I haven't worked on "planet scale" stuff, and if I'm lucky, get an L4/E4 offer.
Naïvely walking into my interviews with this background, I was pleasantly surprised to find out that the sort of thing I've been studying at Bradfield for the fun of it over the last few years was exactly the sort of fundamental grounding I needed to not just "survive" system design interviews, but enjoy them. It turned out that neither my Google nor my Facebook interviewers really cared about what big data buzzwords I knew—they were much more interested in my fundamental understanding of how computer systems work. My system design interviews felt like an in-person databases class with Oz or Elliott.
I came out of the other end of the wringer with senior-level offers from both or them, and Amazon. I credit most of that outcome to my time at Bradfield.
So, could this better your career? Well... it did for me, but you should make this decision for yourself. I took CSI at Bradfield because I enjoy these classes about as much as I enjoy a good holiday. People routinely spend far more than Bradfield tuition on a holiday so for me, Bradfield is well worth it, especially compared to the alternatives.
But just as important as signing up is making sure that you're personally in a position to get the most you can out of it. Ask yourself a few questions like:

Can you make yourself free for an average of two hours every day, at minimum?
Are you happy to plan your personal life around these classes for a year?
Are you actually interested in systems-level concepts?
Is a credential important to you? (Bradfield is not accredited)

Should you go for it, and you do it for the right reasons, I'm pretty confident you'll have an awesome time.