A tale of two Silicon Valley experiences

Many months have passed since I graduated from Hack Reactor. Since then, I've undertaken a job search, moved to San Mateo, and started my new job as a software engineer at Kryptnostic, an early-stage startup building secure cloud-based applications. It's been a wonderful ride, and I feel very lucky to be where I am today.

This post is twofold. First up will be my long overdue review of Hack Reactor, and after that I'll share a few of the many lessons I learned while hunting for a job in Silicon Valley.

Was Hack Reactor worth it?

Short answer: Yes.

Long answer: For me, yes, it turned out to be worth it. What Hack Reactor promises, it delivers. When I speak of promises, I'm referring to the fine print of the student agreement, in which you pay $17,780 in exchange for a crash course in JavaScript plus job search training.

On both points, Hack Reactor absolutely excels. The software development curriculum is top-notch. I learned so much and so quickly that it felt like I was downloading information into my brain, which was pretty awesome.

How does Hack Reactor help people to learn so quickly? Different people will give different answers to this question. Some might say the lectures. Others might say the projects. For me, the crucial part of the learning experience was, unquestionably, the opportunity to interact with my remarkable classmates. My cohort was full of kind, brilliant people who encouraged and inspired me to be a better programmer. I learned a ton from working through problems with them, both in my pair programming assignments and in my group projects.

Because of my classmates, the 700-plus hours I spent in that concrete tower with the broken elevators at the southeast corner of the Tenderloin were not just tolerable. They were fun.

People often question the hiring statistics on the Hack Reactor website. I don't blame them; it seems ludicrous to suggest that fledgling programmers with no CS background or prior work experience could land six-figure salaries after three months at a for-profit bootcamp.

Now that I'm on the other side, it all makes sense. Most Hack Reactor grads end up in the Bay Area, which is flush with tech jobs and where the average going rate for software engineers is on the lower end of six figures. Hack Reactor also expends great effort on crafting and culling their student body. The program selects for students who have already demonstrated a certain level of proficiency in coding and trains those students in strictly practical matters: full-stack JavaScript, MVC frameworks, databases, version control, and those pesky algorithms questions that come up in technical interviews. We did toy problems, whiteboarding sessions, and mock interviews, all of which proved useful during my job search.

Hack Reactor also trained us to treat job searching as a job in itself, and to take it seriously, but not personally. We were encouraged to apply to five jobs every day and keep up with our toy problems.

I confess I did neither of those. But I did apply to 50+ companies total, and there was a memorable two-week period during which I had onsite interviews nearly every day. After a while, I finally understood what people mean when they say job searching is a numbers game.

Degrees of Pynchon

We spent two days last week working on solo projects at Hack Reactor. I built a visualization of literary influences, beginning with Thomas Pynchon -- who, aside from being totally amazing, a genius, and one of my personal role models, also has a lengthy section on Wikipedia full of writers who influenced him and writers he's influenced.

Thomas Pynchon's circle of influence

To visualize the relationships between Pynchon and the writers connected to him, I created an arc diagram in D3. Initially, I planned on using D3's built-in chord layout generator, but I fell in love with arc diagrams after seeing so many beautiful examples online (e.g., Bible Cross-References, Command Usage Arc Diagrams, The Shape of Song, among others).

I went down a few rabbit holes, including creating a matrix dataset similar to those required by the chord layout and plotting the writers as nodes on a scale. Thankfully, there's this wonderful Les Misérables character co-ocurrences arc diagram, also in D3, which set me on the right track.

I formatted the influence data into an object with two arrays, nodes and links. Each node contains the name of a writer and a number indicating the writer's category (influencer or influencee), and each link contains a connection between Thomas Pynchon and another writer.

Thomas Pynchon's literary influences

Click for the interactive version. I stole the quote from the Simpsons episode in which Thomas Pynchon reviews Marge's book. For anyone unfamiliar with Pynchon: he does not love cameras.

All the influencers appear to the left of Pynchon, with an arc above the horizontal; all the influencees appear to the right, with an arc below the horizontal. The colors were generated by D3's category20b scale.

Other circles of influence

I also wanted to visualize the influences of the other writers. Initially, I added all their connections to Pynchon's graph. This worked for Vladimir Nabokov but failed for Emily Dickinson, who was influenced by a writer who appeared to the right of her (Ralph Waldo Emerson) -- resulting in a backwards connection.

The solution was to create new graphs and layer them on top of Pynchon's. So, clicking on Nabokov's name (for instance) will fade out Pynchon's graph, increase the size of Nabokov's name, move his name and dot to the center of the page, draw a line from his name to the center dot, and display his influence graph around that new center. Mousing away from Nabokov's graph will delete his graph and bring back Pynchon's.

Vladimir Nabokov's literary influences

Vladimir Nabokov's literary influences

Figuring out how to rearrange the new graph around the new center dot was probably the most difficult part of the entire project. I passed the center position to the new graph and gave the influencer dots a negative x-axis position so that they appeared to the left of the center dot.

Hover selections

The last feature I added was a hover selection event. Mousing over a writer's name will fade out the entire diagram except for the name, dot, and arc belonging to that writer.

Hovering over William S. Burroughs

Hovering over William S. Burroughs

This was the second most difficult part of the project, because of the preexisting fade effects associated with the click event. The entire graph fades out upon clicking a name, and the entire graph fades back in when the mouse leaves the new graph.

I ended up initializing a boolean to keep everything in check: multipleGraphsOnPage starts off as false, becomes true when a new graph is created, and reverts to false when the new graph is deleted. The hover selection event is enabled only when multipleGraphsOnPage is false.

My project completion strategy

The purpose of the solo project was not to build a perfect product, but a minimum viable product. Hack Reactor instructed us to reduce the size of our scope in half, twice -- which I didn't even need to do, since I'd deliberately chosen a very small scope to begin with. The extra time afforded me the chance to polish the look and feel of my project, including the animations, and dive deeper into D3.

This project was really fun. D3 is by far my favorite JavaScript library ever, and I can't wait to make more visualizations with it.

The Design of Everyday Blogs

At the risk of losing all my design cred, I'll admit I put practically no effort or even thought into the way my blog looked until about a week ago. To put that into perspective: I wrote my first post here in May 2013. For most of the time since that point, it's been some variation of this default Bootstrap theme provided by Nikola, the static site generator I use:

My blog, circa February 2015

Nikola, while excellent, has slim pickings for themes, and none of them are quite what I want my blog to look like. So when it came time for the big overhaul, I started (almost) from scratch with a new theme.

The process

Nikola themes live within the appropriately named themes directory. My files are structured as follows:


Here's an overview of what these files do (taken from the Nikola theming reference):

File Name Purpose
theme.css Custom CSS
base.tmpl Defines the basic layout for all pages
index.tmpl Defines pages that contain multiple posts (the "index" pages)
post.tmpl Defines an individual post
engine Text file containing the name of the templating engine your theme uses. The two options are mako and jinja.
parent Text file containing the name of the theme from which your theme inherits. Mine inherits from base.

That's it! I used the similarly bare monospace theme as a guide. You can spruce up your theme with additional templates (see the zen theme for an example), but I decided to keep mine simple.

Now for the fun stuff!

There's another reason why the default theme didn't work that well for my blog: I'm wordy as hell. I don't write posts; I write essays. So, rather than change my style of blogging, I thought I'd pull off an illusion. My main objective in redesigning this blog was to make it resemble a series of digestible sentences, as opposed to the giant wall of text that it actually is.

For inspiration, I looked at Medium, Longreads, Nautilus, Aeon, and all the other beautiful text-heavy sites that have cropped up in recent years.


Typefaces can make or break a design. For the headers, I picked Lato, my favorite web font of all time; for regular text, Lora, my other favorite web font of all time. Both are available on Google Fonts. To improve readability, I increased the size of the text and the space between each line.


The link styles (salmon color + hover transitions) are from an old WordPress theme I created back in 2012, before I became a front-end developer. My CSS may have improved since then, but my visual tastes haven't changed much.

My first pass at the new theme had an entirely white background, which tested poorly. "It's really white," commented one of my Hack Reactor classmates, as he shielded his eyes from the glare.* I subsequently reduced the white space and added a background from Subtle Patterns. I picked a food icon pattern because, well, I love food.

Other changes

I removed the Share button that used to sit in the bottom right corner. It took me forever to figure out how to do this, but all I had to do was uncomment the SOCIAL_BUTTONS_CODE = "" line in conf.py.

Final thoughts

Designs are never finished, but I'm happy with how my blog looks right now. I plan to implement a hamburger menu for smaller screens within the upcoming weeks. If you have any suggestions, or find your viewing experience to be less than optimal, please let me know.

* With much gratitude to my Hack Reactor classmates for giving me the necessary push to redesign my blog.

Off to Hack Reactor

I'm going to Hack Reactor next week!

Hack Reactor is a programming bootcamp -- the most intense of its kind, at eleven hours a day, six days a week, for twelve weeks. Pretty much everyone I've mentioned it to has recoiled in horror, imagining what it would be like to spend so much time cooped up in front of a screen. Yeah, I know. It sounds terrible. It might even sound nonsensical. But here I am anyway: packing my bags, preparing to fly to San Francisco in a few days, and writing about the program that will take over my life for the next three months.

Last August I happened upon A List Apart during work hours, likely in search of CSS help. I'm sure I found what I was looking for, but what caught my eye was an ad for Hack Reactor. Twelve-week immersive programming bootcamp! Six-figure average starting salary! It seemed too good to be true.

The only programming bootcamp I'd heard of was General Assembly's Web Development Immersive, which had briefly interested me until I lucked into a front-end development role at my company back in 2013. I'd even taken a couple of General Assembly classes -- Intro to Data Science and Analysis (at their Santa Monica campus) and Optimizing Landing Pages for Conversion (online) -- neither of which had impressed me.

But Hack Reactor looked like a completely different species of bootcamp. It looked like something I needed.

Many people have questioned why I would need a bootcamp when I already have a career in web development. So I feel compelled to explain my reasoning here.

I may not be a novice programmer, but I learned to code recently enough that I remember what it was like to be a novice programmer and how much I struggled to even get to that point. I'm a late bloomer: after years of grappling with for loops and other basic concepts, I finally managed to make sense of programming at the ripe old age of 23. (In fact, I was weeks, maybe even days, away from 24 at that point.) The book that did it for me is Natural Language Processing with Python -- a truly wonderful read, if you're more inclined to language than math, as I am.

Learning to code was a terrific, frustrating, enlightening experience. When I realized I could solve problems in Python, I was shocked. People had told me that it was impossible to learn to code after a certain age, that developers had an "innate ability" that I didn't have. (By the way, if anyone ever says such complete and utter bullshit to you, you must prove them wrong.)

Soon after I taught myself basic Python, I offered to build a WordPress theme for a project at work, through which I picked up jQuery and a tiny bit of PHP. Within half a year, the company decided to move me from the business team to the development team; from there, I learned a ton on the job and eventually served as the sole front-end developer and designer. By August 2014, when that Hack Reactor ad showed up on my work computer, I had more than a passing familiarity with JavaScript. I wrote it almost daily. I'd used AngularJS for three different projects. And if you'd asked me, I would have told you, yes, I know how to code...

...while a dark, ever-evolving nugget of truth blossomed in the back of my mind, containing my lack of knowledge of closures, compilers, systems, dependency injection, Big-O notation, hash tables, pointers, concurrency, multithreading, inheritance, and everything else that differentiated a computer science prodigy from clueless, fumbling me. There were countless times when I honestly had no idea what I was doing. I flailed around in the darkness, fashioning solutions out of bits and pieces of StackOverflow answers. Programming was like magic to me. I had vague notions of why things worked out in the end -- but only vague, and only notions.

Before you start thinking I've got impostor syndrome, let me bring up this post, which Hack Reactor recommended. I don't identify with this mindset at all. For one, I actually am an impostor. And second, I actually don't have a background in computer science or anything related to it. Unlike the author, I didn't take programming classes in high school, didn't study CS/CE in college, never cofounded a software startup, and never worked for a tech giant.

Here's my history with computers prior to the age of 23. When I was eleven, I fell in love with the Geocities-era web and taught myself HTML and CSS. But I had no interest in programming whatsoever. In high school, I was convinced that I would be a novelist (that didn't pan out). In college, I was convinced that I would be an architect (that didn't pan out either), and I was the most Luddite architecture major you could imagine. When our professors told us to use Photoshop, I stuck with Microsoft Paint; when I saw my classmates saving time by using the AutoCAD command line, I turned up my nose. I produced hand drawings whenever possible. I put off learning Rhino, the school-sanctioned 3D drawing program, until mere days leading up to my final review. And my 3D renderings were wretched: oddly colored, unrealistic, physically unsound boxes. Needless to say, I had no future as an architect.

When I graduated at 21, I had a strange epiphany that I would make my living off computers. What's even stranger is that it turned out to be true. But I still haven't shaken off the Luddite cloak, which is ultimately why I decided to apply to Hack Reactor.

After seeing the Smashing Magazine ad, I researched all the programming bootcamps I could find. I immediately ruled out the ones that taught Ruby on Rails (which, by the way, is nearly all of them). Eventually I settled on two: Hack Reactor, my first choice by a long shot, and MakerSquare, as a backup. Hack Reactor appealed to me because of its laser focus on one language, JavaScript, and its intensity.

The MakerSquare interview came first. They stood me up. The admissions coordinator scheduled another interview, but alas, no one showed up to that one, either. How ridiculously unprofessional! So I canceled my application. (The funny part is that Hack Reactor recently acquired MakerSquare.)

When my Hack Reactor interview rolled around, at 10 a.m. on a bleak September Saturday, I was pessimistic. I downloaded Skype onto my computer about half an hour before the interview. The last time I'd used Skype was in 2011 or so, and I'd never used it for video calls. At 9:50, my interviewer messaged me, saying that he would begin the interview soon. Around that time, I checked the calendar confirmation email, and that's when I realized it would be a technical interview.

That's right. I confess to having done zero preparation whatsoever for my Hack Reactor interview. DO NOT DO THIS. It was a dreadful mistake on my part, and the only reason I managed to cope with coding in real-time on a Google Doc with zero prep was because I'd been writing JavaScript nearly every day for over a year at that point. I was nervous as hell. Fortunately, my interviewer was really cool. He gave me plenty of hints and encouraged me to talk through my thought process. Thanks to his help, I managed to complete the functions he asked me to write, but I came away feeling like I'd bombed the interview. He told me I would hear back within a week.

Two days later, I got to work, fired up my email, and what did I find? An enrollment agreement and acceptance letter from Hack Reactor. I checked the email headers and freaked out. They'd sent the decision to me within three hours of the end of my interview; I simply hadn't seen it because my application was tied to my GitHub account, which was in turn tied to my work email address.

I wrote back to the HR admission team. I deluged them with questions. I connected with HR alumni on LinkedIn and deluged them with questions. I pushed back my start date from December 8, the cohort I'd applied for, to February 2. I sat on the enrollment agreement for a couple of months.

Then I decided to go.

Hack Reactor used to devote the first two weeks of the course to JavaScript fundamentals. Now they require students to complete a separate precourse curriculum, ensuring that everyone possesses a certain level of JavaScript knowledge before starting the program. I'm under oath not to reveal details about the precourse work, but, as other bloggers have mentioned, it involves cloning a popular functional JavaScript library as well as the front-end of a popular social media site.

My advice for the precourse work? Complete it as soon as possible so you don't have to worry about it. The estimated amount of time is 50-80 hours. I'm pretty sure I completed the precourse work in fewer hours than that, but I also rushed through it to make time for the edX functional programming class I mentioned in my last entry. Looking back, I'm happy I stayed with the functional programming class, as it sharpened my brain and made the precourse work look quite simple by comparison. But I'm not sure I would recommend doing this, especially around the holidays. It was stressful.

Deciding to attend Hack Reactor isn't like deciding to go to college, or deciding to accept a job offer. It's an expensive, unaccredited program, and people will wonder if it's a scam when you tell them about it.

Career-wise, it's probably the most difficult decision I've ever made. To be honest, I'm still not sure it's the right choice, but all I can really do at this point is look forward to the future. I'm beyond excited. Plus, Hack Reactor encourages blogging, so I'll be posting here more frequently!

Review: Introduction to Functional Programming

Recently I completed Delft University's fall 2014 offering of Introduction to Functional Programming (FP101x) on edX. I've been interested in functional programming for a while (caught the bug when I learned about Python list comprehensions), so I was really excited for this class. It turned out to be one of the better MOOCs I've taken, and definitely the most challenging.

My takeaways from the class:

Functional programming is cool

Erik Meijer, the professor, is funny and brilliant, and I came away from many of his lectures thinking, wow, that was fascinating. I've read before that learning how to program in a functional style is like learning how to code all over again, which I found to be true. This class opened my mind to a totally different way of reasoning about the structure and composition of programs.

Beginners, beware

The prerequisite for FP101x is at least one year of experience programming in an imperative language. I've been working with JavaScript since early 2013, and I learned basic Python and C before that, so you'd think I would be fine. NOPE. Both the homework (multiple choice) and labs (programming assignments) started off simple but got mind-numbingly difficult toward the end. The last two labs in particular really stumped me -- we had to implement Poor Man's Concurrency and rose trees, two subjects that weren't even hinted at in the lectures. And don't even get me started on monads.

I got the sense that Prof. Meijer doesn't typically teach beginners. Based on the assignments and his forum posts, he seemed to have really high expectations of what a MOOC student would be able to accomplish with little guidance and limited time. For me, a total novice, the second half of the class was a struggle. Fortunately, there were plenty of kind, generous folks who took the time to help out their classmates in the forums.

To anyone who's considering taking FP101x: learn a bit about category theory first. Also, basic Haskell would be good. The class is language-agnostic, but Prof. Meijer used Haskell in all the lectures and homework assignments. From my travels around the discussion forums I'd wager that most of us ended up solving the labs in Haskell, too, although the instructions were provided in multiple languages (Scala, F#, Groovy, Frege, Ruby). It would have been much easier for me to digest the concepts in this class if I hadn't had to learn an entirely new language as well.

But, speaking of Haskell...

Seriously, what a gorgeous language.

I don't understand it. That is, I understand enough of it to know I don't understand it at all. Regardless, I can still appreciate it on a superficial level.

Say you have a list, and you want to apply one function to the members of the list in odd positions, and another function to the members of the list in even positions. Here's a quick JavaScript implementation:

function oddEvenMap(list, oddFunc, evenFunc) {
  for (var i = 0; i < list.length; i++) {
    if (i % 2 === 0) {
    } else {

And here it is in Haskell:

oddEvenMap :: (a -> b) -> (a -> b) -> [a] -> [b]
oddEvenMap f g [] = []
oddEvenMap f g (x : xs) = f x : oddEvenMap g f xs

No variable assignments. No for loops. Haskell is stunningly beautiful and concise. (I realize the comparison to JavaScript isn't fair, but that's the language I know best.)

Lastly, edX is a great MOOC platform

In 2014, Coursera was my MOOC platform of choice, as I'd finished three classes through it at the end of 2013 (Computing for Data Analysis, Data Analysis, and Machine Learning).

Now edX has taken its place, primarily for usability reasons. Coursera's interface is passable, with many Bootstrappy elements; the videos seem to go on forever. edX's interface is thoughtful and intuitive. Two of my favorite aspects: the video player, which has speed controls and highlighted subtitles that scroll in unison with the instructor's speech, and the homework submission system, which checks each answer individually.

I will definitely be returning to edX for more classes later this year.