A Look into CoffeeScript

Recently I’ve been writing and reviewing code in a programming language called CoffeeScript. It’s a fun hybrid of JavaScript and Ruby — its syntax has the simplicity of Ruby, and it compiles into JavaScript (which means that to test your code you must run a compiler that changes the CoffeeScript to JavaScript). Curly braces and semicolons are no longer needed, string interpolation is allowed, conditionals and loops sound much more like written language. Here’s a quick example demonstrating the difference between a for loop in each language:


var names = ['Stefanie', 'Ebony', 'Sophia'];
for (var i = 0; i < names.length; i++) {


for name in ['Stefanie', 'Ebony', 'Sophia']

One aspect where CoffeeScript is stricter than JavaScript is in its white-spacing. It's similar to Ruby or Python in that there must be consistency in all the white-spacing throughout your code, otherwise you'll run into a compiler error.

Lots of folks say that there's plenty of similarity between CoffeeScript and what's coming out in JavaScript with ES6, so it leaves one to wonder... what will CoffeeScript's future hold?

Dipping into Backbone.js

In a world where there are seemingly more JavaScript frameworks than there are sheep in New Zealand, one may wonder why someone would choose Backbone over other popular frameworks like Angular and React.

Well, I won’t speak to relative values between frameworks, but I can say that one of Backbone’s key advantages is that it isn’t opinionated. In developer jargon, this means that you have more flexibility in how you develop your apps. This is particularly advantageous if you can foresee how your app will be used in the mid-distant future and want to customize structures accordingly (diagrams are definitely helpful here!). Like many other popular frameworks, Backbone is an MV-framework, meaning that where its data is held and where its data displays/is controlled are two separate entities. Here are a few key constructors of Backbone:


  • Stores not-yet-visualized data
    • Data is manipulated by the ‘set’ method
    • Data is retrieved by the ‘get’ method


  • Array-like structure that contains multiple instances of the same model
    • Can act on those instances via events


  • Visualizes a model or a collection
  • Each model or collection can have anywhere from zero to multiple views, but each view is only set to one model or collection
  • Handles user input (the ‘controller’ aspect of the acronym MVC – therefore, in Backbone, the view holds both the viewer and controller functionalities)

Quick example: I have a music player app. Each song in the music player is represented by a model. All of the songs are held by a collection of song model instances. One can view all of these songs through a library view that displays the songs collection. And you can have a separate view for the player itself. With this simple structure, you can create events that call on methods for playing a particular song by clicking on it. This can be done by checking for a user click on the song in the library view.

This app can have further layers of complexity added as you add functionality to this app. For example, if you want to queue songs to be played after the current song, you can create a collection of queued songs that hold song model instances that have been queued. These become queued upon a user event (e.g., click) on the songs library view. As you continue to add more features, you must consider the relationships between the models, collections, and views you’ve already created. Not only is it a great modular coding exercise, but it’s also a great way to apply effective project management in your app building!

Code Sharing in Pseudoclassical Pattern

Lately I’ve been learning about object-oriented JavaScript. A lot of times when building a constructor, you may want to inherit some code from another constructor. This creates a subclass-superclass relationship between the two constructors. What’s similar between the two can be delegated using a prototypal relationship with the superclass you’re inheriting from, and what you want to be distinct will be overwritten in your subclass with your desired new functionality.

And what’s ‘pseudoclassical pattern’, do you ask? It’s a way of designing a constructor function whereby you can simplify the code by not having to initialize ‘this’, or return ‘this’.

Here’s an example below:

var FurryPet = function(loc) {
  this.loc = loc;
  this.ears = 2;
  this.legs = 4;
  this.tail = true;

FurryPet.prototype.move = function() {
  this.loc = (Math.random() * 10) + 1;

var Dog = function(loc) {
  FurryPet.call(this, loc);

Dog.prototype = Object.create(FurryPet.prototype);
Dog.prototype.constructor = Dog;

Dog.prototype.bark = function() {
  return 'Woof!';
  • Instance differentiation (what’s unique to each Dog instance) of the subclass is called out to the superclass in FurryPet.call(this, loc)
  • Instance similarity is called out to the superclass using Dog.prototype = Object.create(FurryPet.prototype)
  • Dog.prototype.constructor is set to tie back to Dog so that all instanceof Dog on Dog instances return true
  • Dog.prototype has a bark method added to it that’s specifically for Dog objects, and not all FurryPet objects

ES6 will introduce a lot of new functionality over Objects and prototypes – feel free to click on that link to read more!

Preparing Before Hack Reactor Begins

Well, less than two weeks till Hack Reactor kicks off! I’m both ecstatic and nervous all in one – delving into the land of code for 11+ hours per day 6 days per week will definitely be stressful at times but I really can’t wait to transform from ‘aspiring software engineer’ to ‘software engineer’!

Given that I’ve had some time off between when I quit my job on Wall Street and when Hack Reactor starts, I was fortunate enough to finish my precourse work pretty early on. Since HR gives you the work two months in advance of your start date, this is the case for a lot of folks coming in. Below are some types of preparations I’ve been working on to be able to hit the ground running once I start HR:

Personal Health (of course this comes first!)

  • Exercise at a regimen you feel comfortable with: For me it’s around 4x a week for 30-45 minutes per day – half cardio focused with running/biking/jump-roping, half strength focused for my core/arms/legs. Obviously the Bay Area is a very health-centric place so many people would exercise more than me, but if my regimen seems aggressive for you just do something to keep yourself energized.
  • Go to bed at a reasonable hour and get up at one too: Burnout in an intensive situation can happen quickly. I saw it far too often in investment banking – one all-nighter turning into two, three, or more… and let me tell you, diminishing margins to return happen aggressively. Hack Reactor’s schedule will be crazy enough, there’s no reason to over-strain oneself (treat it as a marathon, not a sprint – 3 months is a long time for sprint pace!). Developing this sleep schedule early on will make it so you can easily implement it once the program begins – ignore the rat race!

Areas of Pre-Course Work

  • HTML & CSS: HR doesn’t take much time to focus on these (most of this is memorization/look up later anyhow)
  • Git: bolded for emphasis – getting exposed to the basics of branching and merging is critical to the day-to-day work of a software engineer!
  • HR-created slides: this is what they’ll go into more depth in during the first week of the course, and it’s good to understand them as much as possible before coming in
  • Functions that you created/submitted for the pre-course work: implement them again, or try implementing them in different ways
  • Review over parts that confused you: this was my first exposure to jQuery, and not all of it clicked the first time – so I made sure to review that – both the pre-course material that HR gave and some outside materials

Frameworks / Languages

  • Each framework that Hack Reactor goes over: just to get some baseline exposure; this includes MEAN stack, D3, jQuery, Backbone, Angular
    • CodeSchool gives some great intros on MEAN stack (MongoDB can be found as a screencast), jQuery, Backbone, Angular
  • Nuances of JavaScript: this language has plenty of quirks to get familiar with
  • But at the same time, think of what you’re interested in beyond Hack Reactor, whether it be a programming style like functional programming, a subfield of computer science like machine learning, or a language like Scala. You’re not going to have nearly as much time or energy to explore other areas once you’re in the grind, so good to explore those things for fun now!



Binary Search Trees: What’s the Deal?

In the weeks before Hack Reactor begins, I’ve been fascinated with going beyond implementing a function that meets certain prerequisites or passes given tests – I want to understand how functions can be made more efficiently to use less memory. Ultimately, this is what makes an engineer useful – building applications that are quick in data manipulation. In spending the day going through free tutorials on all kinds of data structures – arrays, linked lists, doubly linked lists, stacks, queues, binary trees – one type of structure really captured my attention. And captures a lot of folks’ attention. To pique your interest in the wonderful world of data structures, I’ll examine binary search trees in depth.

Why is there so much focus on binary search trees? In managing data, one wants to be able to manipulate their structure in 3 basic ways: insertion, deletion, and search. What makes binary search trees so cool is that in the average case, it is efficient with all these tasks.

So what is a binary search tree? It’s a type of binary tree. A binary tree is a tree where any node has up to 2 children (so 0, 1, or 2 children):

  /  \
2    3

A binary search tree is a tree where for each node, the value of all nodes in the left subtree is lesser or equal AND the value of all nodes in the right subtree is greater. Here’s a simple example:

  /  \
1    3

Here, the left subtree 1 is less than its parent 2, and the right subtree is greater than its parent 2.

How would we insert, delete, and search for a node in a binary tree? Let’s go through each in plain English:

Inserting a Node

In inserting a node under the BST data structure, one must consider the following cases:

  • When there are no items in the tree yet: insert this node as the root (top) node
  • When the new node is less than the examined node’s value: move to the left subtree
  • When the new node is greater than the examined node’s value: move to the right subtree
  • When the new node has reached a leaf (bottom node) in a tree: insert the node as a left subtree if it is less than the leaf and insert the node as a right subtree if it is greater than the leaf

Deleting a Node

  • Determine if node actually exists
  • If node exists, you see which condition applies:
    • Node is at the root
    • Node is not at the root
  • In both conditions, there are 3 types of removal (with differences in implementation for each):
    • A leaf node (with zero subtrees): simply remove it
    • A node with just one subtree: remove the node and replace it with its subtree
    • A node with two subtrees: continually look to the left subtree and find the rightmost descendant node
      • As a side note, this can lead to an imbalanced tree, which can lead to inefficient implementation (ideally, you want a perfect binary tree where all levels are completely full or as close to this as possible).

Searching for a Node

  • There are multiple forms of searching for a node (contains, traversal, etc.). For this post, I’ll focus on a contains function. The function will return true if the tree contains the node, and false if it does not contain the node.
  • Loop to determine if node actually exists
    • When the searching node is less than the examined node’s value: move to the left subtree
    • When the searching node is greater than the examined node’s value: move to the right subtree
    • When values are equal: return true
  • If not found, return false

Well, that was fun! Now I’ll go check out my neighborhood’s Eat Real Fest! Love me some local food truck festivities. Come check it out in Oakland this weekend; you’ll be well fed!


Recursion, Loops, Memoization… Oh My!

Upon completing the pre-coursework at Hack Reactor, you sign up to meet one-on-one with a technical mentor to walk through some pair programming (note: I was quite nervous about this, but it’s more about checking in on how you think through problems than being perfect from start to finish!). I’m assuming that the readers of these posts are primarily prospective Hack Reactor and other coding school students, so I’m going to give a bit of insight into some lessons I learned today going through my one-on-one.

There are two takeaways that I gathered, and what I’ll be focusing on today:

  • There are seemingly endless ways to solve the same problem. As I continued to walk through the prompt and refactor my code, I kept coming up with alternative methods to solve the same problem. Once you find a solution to a Coderbyte prompt, don’t stop there – keep looking for different solutions!
    • Today I’ll be solving the same problem in 3 different ways – through recursion, through looping, and through recursion combined with memoization.
  • Learning to talk through your problems to someone else through pseudocode really makes it so you’re accountable for knowing how a problem is solved. It’s meant to explain the code to a non-technical person that knows nothing about JavaScript, like (possibly!) your grandpa.

In this check-in, we covered a problem using recursion. The best way I can explain recursion is that it is a method of problem solving that breaks the input down into smaller and smaller pieces. Once it gets to the smallest indivisible pieces, it builds those pieces back together to come up with a solution. So weirdly enough, recursive solutions call themselves on continually smaller pieces of your problem.

Google’s definition of recursion states:

the repeated application of a recursive procedure or definition

Thereby referencing recursion within its own definition! It’s okay to be confused by this. When camping over Labor Day weekend with two Hack Reactor grads that are both now very successful software engineers at cool San Francisco startups, they referred to recursion as “mind-boggling” and “impossible.” So recursion will always be tough on your brain, but after a bit of practice and a leap of faith you can create some elegant solutions for your problems! Let’s dive into a sample problem to show this.

Let’s do a factorial. It’s a pretty intuitive mathematical concept – the factorial of 4 is simply 1*2*3*4=24, the factorial of 5 is 1*2*3*4*5=120, etc.

Solved using recursion:

Using pseudocode:

var factorial = function(num) {
    // base case: if num is equal to 0, return 1
    // recursive case: call factorial on one less than num and multiply that solution by num
        // for example, factorial(4) is factorial(3) * 4

Using JavaScript:

var factorial = function(num) {
    if (num === 0) {
        return 1;
    } else {
        return factorial(num - 1) * num;

Given that recursive solutions can also be solved using a for loop, let’s look at how this can be solved both using a loop as well:

Solved using a for loop:

Using pseudocode:

var factorial = function(num) {
    // set the result variable initially to 1 (because we're multiplying we don't want to set it to 0)
    // loop from 1 to the number we want the factorial of
        // multiply each number by result
    // return the result variable

Using JavaScript:

var factorial = function(num) {
    var result = 1;
    for (var i = 1; i <= num; i++) {
        result *= i;
    return result;

Often times, people say there is a ‘trade-off’ between recursion and looping. Recursion is considered to be elegant, but often expensive on performance because you’re continually calling the same function on smaller and smaller pieces. Looping is considered to often be superior performance-wise, but it is often a bulkier solution.

To reduce the number of calls needed to be made in a recursive function, people often create memoization within their code. Memoization is a means of storing results for inputs that have already been called, avoiding unnecessary work.

Using pseudocode:

var memoization = function(memo, formula) {
    // Take in initial memo array and formula function as parameters
    // Create recur function within memoization
        // Set result to be index n within memo
            // If such element exists, the memo array already has the solution
            // Otherwise, 'undefined' will be stored
        // If result is not stored in memo:
            // Return formula, passing in recur function and its parameters
            // Store the result of the formula into memo
        // Return result
    // Return recur function

Using JavaScript:

var memoization = function(memo, formula) {
    var recur = function(n) {
        var result = memo[n];
        if (typeof result !== 'number') {
            result = formula(recur, n);
            memo[n] = result;
        return result;
    return recur;

Now we’re about to get into some fun here… let’s implement the factorial function using our memoization function above!

Using pseudocode:

var factorial(num) {
    // Set factorial equal to instance of memoization function
        // Memo argument is the factorial for 0 - the base case
            // If you so wanted, you could also store others (1 for 1, 2 for 2, 6 for 3, etc.) but that'd likely defeat the purpose!
        // Formula argument is the recursive case

Using JavaScript:

var factorial = memoization([1], function(recur, n) {
    return n * recur(n-1);

Hello, World!

Two weeks ago, I quit my job in investment banking at one of Wall Street’s most prestigious firms – something that thousands of kids would kill for. In doing so, I turned down opportunities to interview with the world’s largest hedge funds and private equity shops that can offer over $300,000 per year in compensation.

For what reason? To join a 12-week intensive program at one of the world’s top coding bootcamps and ultimately become a software engineer.

Why I Quit Investment Banking

Well, I suppose I should start with how I ended up in investment banking in the first place. In thinking back on when I made the leap from small-town girl to eager-eyed college freshman, what was top of mind was equalizing the education process so that other kids similar to my background would have the same opportunities as those that went to top prep schools.

I thought that social impact === nonprofit, so I tried that route and got discouraged by how people focused on missions rather than outcomes (i.e., “This organization donates to breast cancer research!” vs. “This organization donates to breast cancer research that is in X phase/trial or provided Y result.”). I felt like it made sense to apply more business-oriented principles to nonprofits. Investors look through public filings before investing in a publicly traded company, and lately there’s been a lot of positive press around high-growth startups that disclose their cash burn rates. So I decided to study business (at large public schools these are often considered prestigious and connect students to jobs at top banks/consulting firms/consumer product goods companies).

In business school, I ended up selecting investment banking because others considered it prestigious and difficult to get into, and people wouldn’t see me – the girl who spent time teaching at a nursery school in Tanzania and working at a microfinance organization in Honduras – as an investment banker, and I wanted to prove them wrong. Additionally, I just didn’t have anything that I was dying to do right out of college. I felt that I needed to ‘build a skillset’ first before doing what I really loved.

Unsurprisingly, upon starting this job I became a pretty sad human. I was chained to checking my email every 15 minutes, responding to each email within 15 minutes, always being available to go to the office or log onto a computer to complete work, doing work that could keep me in the office until 4am or all weekend with a smile on my face, being paranoid about leaving the office before 10pm, and despite all of this work never feeling quite like I’m adequate enough – because I forgot a period in a footnote, or didn’t physically enter the office for a weekend. It’s a thankless job, needless to say.

The scariest part, though, was how far away I was from my value system and the people that have those same values. What many of my coworkers cared about were multi-billion dollar deals, job placements into top hedge funds, going out to swanky Meatpacking clubs. People weren’t thinking about eradicating homelessness, unemployment, illiteracy, problems that affect billions in the most intimate matters of their lives. In retrospect, the best thing investment banking provided me was the drive to work toward these goals immediately – who has time to waste when poverty must be alleviated?

Why I Want to Learn to Code

How did I go from the realms of Excel and finance into software engineering and technology – seen by many as the antithesis of Wall Street? Well, it’s a large jump but lots of others are taking that same leap, as seen here and here. Why work 80+ hours per week with no guaranteed time off and demanding bosses when you can work at a tech company that provides a similar salary with free beers in the fridge and endless kindness?

But that’s not the reason why I’m drawn into becoming a junior developer. Well, the kindness bit is a part of it.

Technology has helped solve some of the world’s greatest resource and information gaps. A couple examples include mobile banking and telemedicine. But even with these great strides, there are still so many problems in the world that I want to fix. One idea off the top of my head are aggregating non-profit financial and social outcome metrics for users to search and share with others. When I think of ideas like these, I want to be able to build them myself to test out their viability rather than relying on someone else.

And I love solving coding puzzles. It’s fun to outline a solution to a problem and test little bits & pieces until I get a fully functioning program. In comparing it with what I was doing at my old job (moving logos and updating financial model assumptions), the work is so much more challenging and interesting. Once I started free online tutorials for JavaScript/Python/Ruby, I admittedly started putting off my actual work assignments to do a small Coderbyte challenge or debug a little code. During the few and far between hours that I was away from work, I replaced brunch and bar plans with coding at coffee shops. I figured that if I loved it this much, it’d make sense to dedicate 100% of my professional time to it to get myself up to speed.

From a professional development perspective, there were quite a few reasons why software engineering makes sense for me. For one, being around people that want to mentor – which is all that I’ve seen in asking for help from friends and strangers alike in my journey to learn the basics of programming – is critical for someone like me that’s just launching their career. Additionally, learning fundamental logic that can be universally applied to solve problems – rather than focusing on the very niche world of financial valuation – is a huge draw.

In looking at the available options for becoming a software engineer, a coding bootcamp made the most sense to me. It would not only give me the constant intellectual challenge I wanted but also immerse me in the tech community out here in the Bay Area. After countless hours scouring Quora, student blog posts, and whatever other sources I could find, I ultimately decided that a school called Hack Reactor was the best choice for me.

Why Hack Reactor?

Hack Reactor’s mission is to bring people “from 20 to 120 rather than 0 to 60,” and this’ll give me a great start in getting up to speed on the technical skills needed for the task at hand. The grads I’ve spoken with and read blogs of and LinkedIn stalked have gotten into all kinds of amazing companies like Facebook and Google… and also all those super cool startups people haven’t heard of just yet unless they’re in tech.

Every single person I talked to continually emphasized that the educational experience at Hack Reactor was unparalleled to their expectations–or anywhere else, for that matter. I’m the kind of person that likes to be continually pushed to higher limits and expectations, so that aligned well with my value system. And on top of that, if I were to invest months of time and income, I wanted to go to a program where I knew there was both intellectual stimulation during and success after the program.

As an added bonus, because I got into the program, I was able to apply for an internship and scholarship at Optimizely… and ultimately became one of the recipients!

A Software Engineering Job Offer Before Learning How to Be a Software Engineer…?

With plans for Hack Reactor solidified months earlier, I was pleasantly surprised to come across Optimizely’s newly developed I/Own It program for aspiring female engineers that go through Hack Reactor’s program. I figured it might be a shot in the dark, but why not give it a go?

As I learned more about Optimizely to prepare for my application, I realized it’d be a great fit for me personally. They’re still a startup yet established enough where I can learn from more senior engineers and get exposure to a variety of teams (theirs range from their core A/B product to mobile to personalization to security and beyond). Additionally, their products are of particular interest to me. I’m very passionate about actively measuring social impact, and the idea of helping others test their own hypotheses is great in that it’s personally rewarding and a product that can help me learn more about product development and management (aspects I’m very interested in learning more about).

I reached out to two HR alums, Andrew from the security team and Lauren from the mobile team, currently working at Optimizely to learn more about their experiences. Both were immensely helpful in walking through what Optimizely values as a company and how the engineering teams work. I knew I had my work cut out for me to give myself the greatest chance possible at working for such a cool place.

Given my eagerness, I may have been a bit of a fangirl in my application. I built a website that had a video about why I’m interested in Optimizely, testimonials from mentors on why I could be a good candidate, and short write ups on my prior experience and what I want to build. I wanted to make sure that if all else fails, people at Optimizely knew how much I’d appreciate the opportunity and that I was willing to work hard for it.

My interview was with an engineer named Dana, and we basically fell in love over Skype. Given that she was a coding bootcamp grad too (App Academy, another great school!) we naturally clicked talking about the transition into engineering. Most of the interview focused on why I want to code and which aspects of code interested me. After the interview I realized that what was originally a “throw an application for fun and see what sticks” process was becoming something that I wanted, BADLY. I checked email multiple times daily over the next week, eager for a response.

And a week from that interview, I got an email saying that I was one of the recipients! I could not have been happier with how everything fell into place over the course of a couple months.

I’m so excited to join Optimizely this January. In recognizing the gender gap in tech they didn’t just pay lip service about diversity recruiting efforts – they took change into their own hands! Male and female engineers alike developed this partnership with Hack Reactor to provide women scholarships and mentorship for the program, and a three-month internship once completing the program. Given how inclusive they’ve been toward me so far even before I’ve started (all of the one-on-ones I have planned with current engineers, congratulatory emails/words of advice, countless invitations to have lunch at the office, etc.), I can only imagine how welcoming they’ll be once I officially join the company!

Now that I’ve been fortunate enough to join such a fantastic group of people, I’m making it my #1 priority to learn as much about coding world as humanly possible over the course of the next 4 months.

What Lies Ahead

Before Hack Reactor begins, I have around a month and a half to be a funemployed free spirit in the Bay Area. So far I’ve joined dozens of meetups for aspiring female coders, activist groups, international development organizations, the education sector, book clubs, poetry readings… the list goes on and on. Trying to make up for all that lost time that was spent in spreadsheets and embrace how beautiful this world can be.

So, I’m now a free woman! With the exception of a few lunch/drink dates scheduled, my schedule is pretty clear. If you’re an aspiring coder, staunch feminist, lover of all things social impact/activism, or otherwise fun & kind person… feel free to get a hold of me on Twitter @HaleyParty 🙂