Randall Koutnik

Passing the generic tech interview

Mon, 17 Aug 2020 00:00:00 +0000

The software industry sucks at interviews. Most companies don’t have a standardized way of comparing candidates and those that do don’t put much thought into them. It’s usually convening the hiring panel and getting a thumbs-up from everyone. This means that the job of an interviewee is not to demonstrate that they have the skills needed for the job at hand. Instead, an interviewee’s primary goal is to get the interviewer to like them.

I hate this. I’d much rather be judged by my ability to do the job at hand instead of playing these psychological games. Unfortunately, that’s the reality we live in. Here’s a few lessons I’ve learned over the years. While the advice in this post is very “works on my machine”, I hope you can pick up a few things that’ll help you in your future job-seeking endeavours.

I’ve interviewed a lot, thanks to my status as “the Typhoid Mary of startups” requiring that I find a new job a little too often for my own comfort. When I’m sitting down for an interview, my initial goal is to figure out what the interviewer across the table wants. Usually, I do some backchannel communication to figure out what the interview culture is like at the company. Occasionally, the company has put some thought into interviewing and the following doesn’t apply (i.e. Netflix).

In most cases, I need to gear up and reread How To Win Friends and Influence People. Once I’m at the interviewing table, it’s all about making the person across from me happy. I’ve found that interviewers usually fall into a few broad categories:

Here because they were told to

The company has done nothing to help this person become a good interviewer. They almost certainly googled “JavaScript Interview Questions” five minutes ago. It helps to know the answers to the interviewer’s questions, but it’s more about making them relaxed. Crack jokes, lob softball questions at them, add comments about how cool the company is. I want them to walk out thinking “that wasn’t so bad, Randall’s a pretty cool guy”. Bonus points if you’ve got something impressive to show off (open source work, a neat tech talk). Try to work that in somewhere if possible.

Here to show off how smart they are

Oh boy. They’re here to interrogate you and “prove” they’re smarter than you are with tricky questions. These questions usually take the form of a simple task, with increasingly-difficult-yet-absurd burdens added in (“now do it without if statements”). Other times it’s time for JavaScript Pub Trivia, with a side helping of sneering disdain if you get anything wrong. If I’m interviewed by someone in this category, the company immediately gets tossed into the “absolutely not” bucket. Usually I just go with rote answers or, if I’m feeling cheeky, dance around the tricky questions they ask.

Here to ask The Specific Question

Often, interviewers have one big question they ask at every interview. These can be fun. I try to make it a back-and-forth thing, instead of me sitting there silently solving away. They’ve probably seen dozens of solutions, so I try to ask questions around the problem (“what about this?” “What happens when X?“). Even if we don’t cover those areas, I want to stand out in their mind from everyone else who just followed instructions.

(When I’m interviewing without guidance, this is the style I use)

The Culture Fit Interview

“Tell me about a time when….“. Luckily I’ve got tons of stories (see Typhoid Mary). The key is to spend about 40% of the storytelling time talking about my own failings and what I’ve learned. Bonus points if I can follow it up with another story where I applied what I learned. Most folks on my side of the table only talk about their successes, which makes sense on the surface (it’s an interview, show off your good side) but from a “make this person like me” standpoint, it just comes off as arrogant.

One common thing I do in all but the showoff category is that I ask about what they do at the company. This helps me figure out a bit more about the company itself but the primary purpose is to get the interviewer talking about something that’s important to them. (People who feel their job isn’t important usually don’t get picked for interview panels). Once I know what their role is, I can reflectively listen. This ends up being pretty flattering to the interviewer without actually coming across as such.

Usually, I’m asked for feedback immediately after the interview. If asked for feedback, I’m not going to be honest. That doesn’t mean I’m going to lie, it means I’m going to give the feedback I think the interviewer wants to hear. In most places, that means something that looks like:

“Oh, that was great!”
“I especially appreciated… (point out something that was nice)” Some examples: “Everyone made time for me to ask questions” or “thanks for bringing me water, my throat was parched!”
“One concern I have is… (here’s a great opportunity to provide a layup for the interviewer/recruiter to answer)” Usually I mention something I know they can solve (commute => WFH/shuttles) that hasn’t been mentioned yet in the interviews.

Again, all of this is a moot point if the company’s put some serious thought into what sort of candidates they’re looking for and how their interview process selects for that. But that’s a rarity, and this philosophy has worked out for me - I haven’t had trouble finding a job in my 7(!) job searches. Caveats apply, but this post is already too long.

Also notable is that this strategy optimizes for offers, not finding the best fit for me. I’ve pretty much given up on determining the latter via interview, as everyone’s faking it on all sides of the table. The only effective thing I’ve found is knowing someone on the inside who can be blunt with me about the real culture (and even that doesn’t always work).

The Corporate Culture Gap

Sun, 03 May 2020 00:00:00 +0000

I was involved in a recent chat conversation around the concept of “Culture Buddies.” The idea is to help onboard new employees by having a current employee assigned to them with the specific task of helping the new employee acclimate to the company’s culture.

I had a direct and immediate dislike of the idea.

(Note: this is different from finding a trusted friend at a company to help you navigate the sticky parts - something I strongly recommend).

The fact is, virtually every software company has a significant gap between culture-as-imagined and culture-as-practiced. For example, many companies claim to “hire the best” but still pay below-market. However, pointing out this contradiction is not a great way to further your career.

Now let’s imagine a corporate Culture Buddies program. The type of person who’d be selected to be a “Culture Buddy” is likely someone who will present culture-as-imagined even when it does not line up with culture-as-practiced. The company wants to present culture-as-imagined to new hires. When I start a new job, I’m looking for the opposite - I want to know what the exceptions to the stated culture are so I don’t end up running face-first into them (which I’ve done many times in my career).

Often the difference between culture-as-imagined (CAI) and culture-as-practiced (CAP) isn’t visible to those higher up, as those lower down smooth over issues to preserve the image. If your company has a significant gap between CAI and CAP, then a buddy system designed by those very same higher-ups won’t help you. You have bigger problems. Oh, and your company definitely has a significant gap. Basically everyone does.

So what should we do?

The Corporate Culture Gap

A company needs a goal. Without a goal, you can’t have alignment - there isn’t anything to align towards. Without alignment, you can’t build trust, and without trust, you’re lost in a hopeless maze of micromanaging.

So you need a goal. What makes for a good goal is a bit out of the scope of this discussion. As the leader of a company, you need to: Make sure everyone knows the goal of the company (so repeat it whenever you can!) Make sure everyone knows their part of the goal

The most egregious splits between CAI and CAP I’ve seen were because there was a stated goal (or worse, multiple stated goals) and it was abundantly clear to those paying attention that the actions of the company (and the orgs within the company) were not in alignment with the goal. This is called the Corporate Culture Gap. Speaking up about actions not being aligned with stated goals results in being labeled “not a culture fit”. This label does significant harm to your career, and can often result in termination.

Some people just don’t care about the culture gap. They just go into work, move some tickets from left to right, and go home. Others are culture cheerleaders. They focus just on CAI and ignore/justify the difference. Some people just want to be a follower (and that’s ok!). Finally, there are people who care deeply about key pieces of culture-as-imagined. Most likely, the gap impacts them directly. (CAI: “We Value Diversity”, CAP: “We Underpay Everyone Who’s Not A White Dude”). For the group that cares deeply, there are those that speak up, and those that pretend to be cheerleaders. In any company with a non-trivial gap, those that speak up are not appreciated. Those that pretend can end up being effective, if miserable.

To put it simply, the cruel irony of company culture is that you can only speak up to say “This is a psychologically unsafe environment” in a safe environment.

So, I started this section by talking about goals. What’s the goal of our culture buddy program?

As a new employee, my goal is to learn as much about CAP as possible so that I can be effective within the system. I won’t trust a buddy given to me by the company, because I’m looking to find the parts of the company’s culture that it can’t (or won’t) see.

Small Gaps

If there isn’t a significant culture gap, then that’s awesome! Any engineer who’s had a few jobs has been burned by this gap enough that they’ll need some really solid proof that the company means what it says. Personally, I’ll write off anyone assigned as a cheerleader.

In this small-gap case, new employees take some time to adjust, but get there eventually. This happened to pretty much everyone who joined Netflix. There’d be an initial period where they’d be thinking “you don’t actually mean you let engineers do what they want” but as newcomers tested and experimented, they’d realize that yes, for the most part, Netflix lived up to its culture. (Was there a gap? Certainly. But it’s the smallest gap I’ve seen and management was open about times when the culture failed.)

So in the small-gap case, from management’s perspective, a culture buddy may help things along and get the new employee adjusted a bit faster. Though not that much faster, because in the small-gap case, everyone’s living the culture anyway so a specific person may not be that helpful.

In the large-gap case, on the other hand…

Large Gaps

If you’re a manager at a large-gap company and are aware of (and dislike) the gap, then the goal is to build a small-gap team. An onboarding buddy will be enormously helpful here to help the new employee guide the rough waters that would result in the cultural mismatch between a small-gap, goal-driven team and the wider, large-gap company. However, this’d be a pretty high-touch situation, for obvious reasons.

If you’re a manager/leader at a large-gap company and either unaware of the gap (or aware and don’t care, which is the same thing), then the purpose of a culture buddy system is a little more vague. I find it a bit more difficult to write about this situation without just getting all cynical everywhere.

An Example Gap

Let’s look at a specific example to illustrate the difference between Culture As Imagined and Culture As Practiced: Feedback.

Culture-as-imagined (CAI), every company ever says that feedback is important. Feedback becomes a Key Cultural Value, companies offer classes on effective feedback, managers talk about how valuable feedback was to them, etc, etc. This looks great until someone actually gives constructive feedback. Suddenly, the culture gap becomes very visible.

Some managers treat feedback as confusion, and instead of responding to the feedback, they keep on explaining, as if it was abundantly clear how they were right. Feedback was something tossed into a void. In this case, employees learn to shut up and nod. Worse, these managers think they’re doing a great job! After all, if they were doing a bad job, someone would say something. Other managers start screaming fits whenever they’re questioned. Heck, one place I worked, all feedback was just straight-up ignored.

Early on in my career, I would run into this cultural mismatch right off the bat. I’d see something that could be improved and give feedback - just like the culture docs said! At best it would fall by the wayside and I’d discover that the company wasn’t really interested in my feedback. At worst, I’d endure a public berating in front of all of my new teammates. Either way, I burned a lot of social capital because I followed the company’s stated values.

I can’t say I always gave feedback well - this is something I’ve improved a lot over the years, with a long way to go - but the companies set new employees up to fail. This might even be the catalyst for a culture buddy system! “Hey, new folks end up with a rough start, maybe we could help them out.” Good intentions, but the problem here isn’t the onboarding, the problem is you’re lying to your employees. Fix that, and the onboarding problem gets fixed too.

Conclusions

Any leader who wants to be a good leader (and not just “in charge”) needs to keep the corporate culture gap in mind through all of their decisions, large and small. Adding a “culture buddies” program is just a band-aid on a much larger problem. The best companies out there recognize the key to a smooth onboarding isn’t further indoctrination but building trust by being open and honest internally about how the corporate culture works in practice.

Thoughts? I’d love to hear them. You can reach me at blog@rkoutnik.com or in shorter form at https://twitter.com/rkoutnik

Exploring JavaScript's types

Sun, 30 Sep 2018 00:00:00 +0000

You’ve seen the hype around TypeScript and are wondering exactly how these types help us programmers out. If you’ve made it this far into your career without learning about intuitionistic type theory or what T = ∃X { a: X; f: (X → int); } means, that’s just fine. There are plenty of fantastic languages out there that don’t require knowing what a “type” is, so it’s possible to get quite far without diving into the complicated stuff. For the record though, I have no idea what those things are either, I just ripped them off Wikipedia.

Anyway - on to TypeScript, a much more approachable typed language.

What’s a ‘type’?

A ‘type’ means ‘some category of value’ and is usually assigned to a variable. We can say “this variable will contain a number” with the following syntax:

let userAge: number;

At this point, we haven’t defined what someVariable is, just that it can only contain a number. If we try to stick something in there that isn’t a number, then we’ll get a big ol’ complaint from TypeScript:

The angry red squiggle here is because we’ve told TypeScript that userAge is a number and what we’re assigning is a string. No need to worry about structural type systems vs nominative type systems, this is all stuff you probably know already but lacked the vocabulary to explain.

There’s a whole bunch of types that come out of the box in the JavaScript language:

String
Number
Boolean
Null
Undefined
Object
Symbol (added in ECMAScript 6)

These types are known as primitive types because they’re the basic building blocks every other type is made up of. They’re a bit like the elements in physics. The typeof operator will return a string definition of the type…mostly.

Most of these are pretty straightforward, number is a number, boolean is true or false and Symbol is something fancy to give conference talks about. (Kidding - Symbol does have its uses but that’s another post). The most important type here is Object: A variable that has properties of its own. Each property can have its own type. However, there’s a few surprises in this list: there’s no array or function and undefined and null are separate types.

`null` vs `undefined`

Mostly, null and undefined were both added to the language because it was whipped together so fast. Some argue that only one is needed (both represent “there’s nothing here!”) but they’ve come to mean different things. null is deliberate - the programmer has intentionally set this variable to nothing. undefined means that no value has been set yet. This is just a convention, so don’t expect everyone to agree on it.

Where’d `array` and `function` go?

There are two big omissions in the list of primitive types. They certainly still exist, but this is one of the quirks of JavaScript, thanks version 1 to being defined in a little less than 2 weeks. Technically speaking, both array and function are of type Object, though the typeof operator kinda gets this right:

let arr = [];
let fn = function () {};
typeof arr; // 'object'
typeof fn; // 'function'

In JavaScript, arrays and functions are just objects with some special abilities added on, which is why the following works:

let arr = [];
arr.foo = 'bar';

We just added an entirely new property to this array instance! We can do this because an array is still an object, and objects let us define arbitrary properties. (TypeScript will still get mad at you). Arrays are “An object that can contain a list of things and has some methods and properties related to that” and functions are “an object that can be called (that is, do something when parentheses are added)”. Both of these are built by starting with an object and adding some extra properties onto it.

Assigning types in TypeScript

In TypeScript, a colon is used to indicate a type definition, like above with let userAge: number. An array of things can be defined by adding square brackets after whatever type of thing it is, so an array of numbers is defined by let userAges: number[]. Functions are usually defined at the time of assignment (see Type Inference below) but in a pinch can be assigned as such:

// takes an int and returns a string
let func: (val: number) => string;

The special any type

JavaScript is a loose language (to put it politely) and so sometimes we may just throw our hands up and say “I have no idea what type this is!” In that particular case, TypeScript provides the any type.

let numArr: number[] = [];

// legal
numArr.push(17);
// illegal
numArr.push('hello');

let whateverArr: any[] = [];

// both legal
whateverArr.push(17);
whateverArr.push('hello');

// It's still an array though!
let error = whateverArr + 17;

Creating your own types

This set of primitive types is great to start out with, but any serious application will need to define its own types. Fortunately, that’s provided through the type keyword - used like let or const but for declaring a type. For instance, the previous post had an array of user objects:

let users = [{
  id: 7,
  firstName: 'Robert',
  lastName: 'Smith'
}, {
  id: 12,
  firstName: 'Dana',
  lastName: 'Jones'
}];

In this case, a user is an object, and that object has three properties, two strings and a number. (Starting to see how we build more complex things from primitive types?) Adding in the type looks like this:

type User = {
  id: number;
  firstName: string;
  lastName: string;
};

let users: User[] = [{
  id: 7,
  firstName: 'Robert',
  lastName: 'Smith'
}, {
  id: 12,
  firstName: 'Dana',
  lastName: 'Jones'
}];

A little more verbose, but this means that the users array will be used consistently around your entire application and catch a whole bunch of bugs before they get a chance to mess everything up (for instance, typing userId when you meant id). The larger the application (and the team working on it) the more powerful these benefits become.

Type Inference

If all this talk about defining all these kinds of types sounds tedious, don’t worry! TypeScript is smart enough that it can figure out most types without any input from you.

// TS knows age is just a number
let age = 42;

// Even without type definitions, this will cause an error
let display = 'I am ' + age + ' years old';

Finally

If you have a headache, I don’t blame you. This was supposed to be simple, and then JavaScript has to make things all complicated with the various asterisks and exceptions. Unfortunately, it gets worse. Next week, we’ll talk about how to use generic types and create our own version of an array.

Why is TypeScript so great?

Mon, 24 Sep 2018 00:00:00 +0000

In my developer career, I don’t think I’ve met anything as revolutionary as TypeScript. There are plenty of shoulders TypeScript is standing on (everyone who worked to get JS devs to accept build systems!) but TypeScript is a brilliant cumulation of that work that’s fundamentally changed how I do my job. So much so, that I finally switched off my beloved Sublime Text to Visual Studio Code for better TypeScript support.

(As an aside, the fact that I’m using a Microsoft editor to write a Microsoft language and that both are open source still feels weird)

For those of you new to frontend development (or those who are returning after a long hiatus), TypeScript is a new language that’s a superset of JavaScript that adds optional types into the mix. Here’s a snippet of TypeScript:

let currentUserId = 7;
let users = [{
  id: 7,
  firstName: 'Robert',
  lastName: 'Smith'
}, {
  id: 12,
  firstName: 'Dana',
  lastName: 'Jones'
}];

let currentUser = users.filter(u => u.id === currentUserId);

console.log('Hello,', currentUser.firstName, '!');

Most importantly, you’ll notice that there aren’t any type annotations or other funky business in this snippet. All JavaScript is also valid TypeScript. This is TypeScript’s greatest asset. All you need to do to convert a codebase to TypeScript is a single command:

find . -name "*.js" -exec bash -c 'mv "$1" "${1%.js}".ts' - '{}' \;

(ok, ok, so there’s more to it than that. We’ll get to that later).

So all your JavaScript is valid TypeScript. So what? The answer lies in just how dang smart TypeScript is. It’s not just “We jammed a bunch of types into JavaScript”, but an entire ecosystem of tooling around that, all built with the developer in mind. It took some time to get where we are today (I gave up on TypeScript several times in the dark days of v0.x).

TypeScript takes a look at the above snippet and knows that users is an array of objects and filter is a method on an array that returns another array. Therefore, currentUser is an array and …wait a minute! Arrays don’t have a firstName property! TypeScript then slams a red squiggle underneath this glaring issue, allowing you to fix it right in the editor itself. No need to content switch to the browser, stare at a bizarre undefined that shouldn’t be there, and eventually track it down to a filter that should be a find.

Before TypeScript, I made these kinds of mistakes all the time and caught most of them before they got to production. Now I still make these sorts of mistakes all the time but they’re caught immediately instead of creating incredibly quirky bugs.

TypeScript changed the game even without needing to modify our code at all. Even at the start, it’s a super-linter that allows us to offload an enormous amount of working memory about our codebase and JavaScript to a tool, allowing us to spend those brain cells on a better architecture and writing mushy love letters masquerading as blog posts about said tools.

TypeScript is incredibly powerful as a super-linter and would be just fine if that’s all it did. Next time we’ll talk about types, how to define them in TypeScript, and just why that’s useful.

Stateful Filters in RxJS

Mon, 17 Sep 2018 00:00:00 +0000

I’m just finishing the last stages of writing Building Reactive Websites with RxJS, to be published through Pragmatic Publishing. I’m a huge fan of RxJS, even if it is a bit complicated to get used to. In an effort to demystify this library, I’d like to walk through a few case studies over the next few weeks and analyze how to use it in real-world scenarios.

The first case study comes from one of my old jobs at a cybersecurity company. This company had an offering where they’d crawl The Dark Web (I still can’t belive sales folks said that with a straight face) and look for keywords set up by clients. Ostensibly, this tool could be used to detect leaks of software and/or internal documents. In order to achieve this scanning ability, we need to build a filter that can be dynamically updated.

The crucial thing to think about when writing software using RxJS is to model everything as a stream of events over time. If your application does not lend itself well to this modeling, RxJS may not be for you. Fortunately, this task is easy to model as two separate streams. One, from Kafka, is new data from the crawler. The other comes from a database poller and contains the keywords our filter needs to test against.

We’ll start off with two magic variables that represent these streams, as dealing with Kafka is outside the scope of this post. Appending a dollar sign to the end of the variable is a convention used to show that variable is an observable.

crawlResults$;
latestKeywords$;

RxJS already has a built-in filter operator, so this would work, at least until the list of keywords was updated.

crawlResults$
.pipe(
  filter(content => keywords.some(content.includes(keyword))
)

The tricky part of this challenge is that we’re implementing a stateful filter. Clients could update the keyword list at any time. We’ll need to store that state somewhere. One option is to just create an array of keywords and manually keep it updated:

let filterKeywords = [];
// every five minutes
interval(5 * 60 * 1000)
.pipe(
  mergeMap(() => dbQuery())
)
.subscribe(newFilterKeywords => {
  filterKeywords = newFilterKeywords;
});

This leaves us holding the bag around both state and managing subscriptions. In this example, we need to make sure that the subscription is properly disposed of, otherwise we might accidentally create tons of pollers and overwhelm the database with queries (this never happened, I don’t know what you’re talking about and don’t belive anything my former coworkers say about this).

The obvious advantage of RxJS is modeling everything as streams but a lesser-known advantage is that RxJS provides many ways to store state inside the framework, ensuring that the library worries about subscriptions and filtering. Combining two streams together in RxJS is known as ‘merging’ and there’s a variety of merge operators to utilize here. Most merges don’t maintain an internal state and just send data on when they get it. Here, we want to know the latest value from both streams on every event, so we turn to combineLatest. The combineLatest constructor tracks multiple streams and on an event from any stream, emits the latest value of all streams as an array.

combineLatest(
  crawlResults$,
  latestKeywords$
)

We’re almost there. The one remaining problem is that whenever latestKeywords$ updates, this might pass along the latest hit from the crawler as well. There’s one operator that’ll save us: distinctUntilChanged, which is a stateful filter that only passes a value if it’s different from the previous value. Throw in a map to extract the results from the keywords, and this looks like:

combineLatest(
  crawlResults$,
  latestKeywords$
)
.pipe(
  filter(([results, keywords]) =>
    keywords.some(results.includes(keyword))),
  map(([results, keywords]) => results),
  distinctUntilChanged()
);

Tada! A stateful merge filter, with the heavy lifting offloaded to the RxJS library. If you want to learn more about RxJS, including building many functional examples, check out Building Reactive Websites with RxJS, now in beta.

Incentivize Teams, not People

Sat, 17 Mar 2018 19:51:00 +0000

Any programmer worth their salt is willing to help team members out when they’re in a pinch. Software development is a team sport, after all. Unfortunately, management can often completely miss the point and create perverse incentives that wreck a team’s cooperation and communication. If you’re a software manager, here’s a quick self test:

Put together a list of all of your incentives, from compensation increases & promotion to “Who gets the new project”. Make sure to include things like a regular team lunch or a “Employee of the Month”. Now, go through that list and ask yourself the following question for each item:

“If Bob goes over to Alice and says ‘Do you have a minute? I need help with something.’, does this incentive move Alice towards helping Bob?”

Let’s go through some common management antipatterns and what impact they have on Alice’s answer.

The worst of the worst are programs that link cash or other bonuses to individual performance goals. Tying individual performance to comp means that the better financial decision for Alice is to make an excuse and focus on her own work metrics instead. Bob’s unhappy because he’s still blocked. Alice is also unhappy because she has to choose between focusing on her work or falling behind on her performance goals. Do you really think more cash will increase morale enough offset this massive break in teamwork?

On the other hand, some bonus programs reward engineers with bonuses that are dependent on company performance (the biggest team there is!). Alice earns more if the entire company does well, rather than focusing exclusively on Alice’s own objectives. Now Alice’s extrinsic and intrinsic incentives are aligned. She can help Bob, safe in the knowledge that the company wants them both to succeed.

Some companies (like my employer, Netflix) go a step further and do away with bonuses entirely, providing top-of-market pay instead, coupled with explicit trust in the employee to do what’s best for the company in any given situation. Netflix’s expense policy, “Act in Netflix’s best interests”, is the archetypical example.

Promotions can be another sticking point. If there’s an open req for a higher-level position that both Bob and Alice are hoping to get, they’re stuck in the same quandry. Google is infamous for only looking at feature development when making promotion decisions and leaving everything (and everyone) else to the wayside. Unsurprisingly, this means they’re launching another chat app while letting Google Reader die.

It may not be as direct as helping a coworker synchronously. There are many other ways engineers work for the betterment of the team/org/company: writing documentation, providing product feedback, sitting in for UX testing, giving internal talks, and more. One option is to sit down and create individual performance metrics for all of these activities. The better option is to remove perverse incentives and let the team do what they do best: build great products.

(Your interview process is filtering out the brilliant jerks, right?)

Hacking Calculords part 3: A math-free intro to neural networks

Sun, 21 Aug 2016 00:00:00 +0000

So far in the calculords series we’ve accomplished:

Part 1: Solving a level of Calculords in sub-sandwich time
Part 2: Building an API between Calculords and our code

Despite what your college might have taught you, there’s another layer beyond all the Big-O notation the ivory tower academics like to squawk on about: O(sandwich). Specifically, if I run this code, do I have time to go make myself a sandwich before it finishes? If so, it needs some optimization. As fun as all of this was, there are two fatal flaws to our intermediate solution:

Firstly, there weren’t enough buzzwords. Anyone who’s made it to Junior level CS classes knows about garbage collection and dynamic programming. We need some seriously hot terms on our resume in case scrawling “I work at Netflix” on a napkin doesn’t suffice at convincing future bosses of our awesome potential. For this post, we’ll be delving into the second-hottest term out there: Neural Networks (I’d go with the hottest, T-E-N-S-O-R F-L-O-W, but that buzzword burns at just over 1,500°C and recruiters got tired of my resume melting holes in their desks).

Secondly (and more importantly), our previous algorithm still requires our fallible human fingers which are much better suited to eating that sandwich. Each round, we need to type in all of the numbers that appear on the screen and then follow the precise instructions it spits back out. One fat-finger and we’ve lost our 1.5x Perfectionist medal. The horror!

Networking

I had collected plenty of screen captures of a level in progress along with the data I’d inputted via the GUI from previous editions. Despite my best efforts, there were some duplicates and plain ol’ bad data in the dataset. Each level represented 6 datums for the cards and 9 for the integers, so I hoped this would be enough data to train my computer to play a video game for me.

The simplest answer would be to take a screenshot and look at a few key pixels to tell if a section of a number was ‘on’ or ‘off’, much like a digital clock (remember those?).

We’ve gathered enough information to tell which pixels are significant just by looking at our sample data. On the other hand “looking at pixels” doesn’t get to the front page of Hacker News and we’re serious programmers. Why do the sensible thing when we can ridiculously overcomplicate?

At this point I need to take a quick break from the grandstanding and actually talk about what a neural network is. There are two building blocks you need to know about: the neuron and the link. If you’re at all familiar with graphs, this is a Weighted Directed Acyclic Graph (WDAG). If you’re not familiar, a graph is a bunch of nodes connected by links. ‘Directed’ means the connections only go one way, and ‘acyclic’ means that if you start at any given node and follow all the directed links, you’ll never get back to the node you started at (there are no cycles). Weighted means that each connection has a different value. Pictures help, so here’s one:

Each circle is a node, the arrows connect the nodes, and each arrow has a value, or ‘weight’. Circles and arrows are nice (at least in CS, they’re less swell when applied to 8x10 color glossy pictures to be used as evidence against you) but where does the learning come in? Imagine all of our lines are carrying a signal (with a strength somewhere between zero and one) to their destination neuron. The neurons (our circles) have a tidy formula attached. I won’t display any formulas here since I’m allergic to sigma functions (the ones with the big funky Σ) but I hope you’ll get the picture. The neuron takes all of these signals, runs ‘em through our fancy formula and comes up with a number to output. Sometimes you’ll hear mention of a ‘perceptron’, which works the same way as the neuron but only outputs zero or one.

When we send in some training data (containing both a set of inputs as well as the expected output), the network runs through all of these calculations and comes up with an answer (not necessarily the right one). It then peeks at the right answer, and goes through a process called ‘backpropagation’. Starting with the final column (the fancy data science types call this a ‘layer’) each neuron adjusts the weight of its inputs a smidge (even if the network got the right answer!).

If the input value matched the correct answer (either high or low), the neuron gives the input a smidge more weight (and vice-versa for a non-match). The precise amount of smidge is called the ‘learning rate’. A big learning rate means faster learning but might overshoot the optimal balance. A smaller rate will take longer to train but is more likely to find the ideal. Picking a training rate is more of an art than a science (though “senior data artist” as a title won’t get you very far).

The actual details are much more complicated, but c’mon, we’re software engineers, there’s a library for that. Let’s dive into our examples:

There’s two networks we need to build. One is for the right-hand side of the play area, and only needs to recognize the digits from 0-10. The images we will be working with are tiny and so we only need to architect a naive network. The left-hand side involves double-digit numbers, so we need to be smarter about our network architecture if we don’t want to spend ages training.

Network #1 (right side)

The construction of our naive network will be three parts, looking roughly something like this:

Input layer

Our input layer will include one neuron for each pixel in the input image (resulting be 25 * 38 = 950 neurons). I’m lazy, so I ended up scaling down the image (from 50 x 75) to reduce the total size of this layer. Training time is a function of how many neurons and connections there are (multiplied by how much training data you have).

To further reduce the complexity of the input layer, I’ve converted the images to grayscale. This means the network need only concern itself with how bright a pixel is instead of the colors. In this particular problem, the background on the right could be red or blue - but that doesn’t change the number displayed. Grayscale means our network doesn’t need to worry.

Let’s review at the reductions made. Remember, every data point means another neuron, and each input node will connect to every node in the middle layer. Even small reductions mean big time savings.

Image State	Data Points	Input Neurons	Connections
50x75 full color	50 x 75 x 4 (RGBA)	15,000	150,000
25x38 full color	25 x 38 x 4	3,800	38,000
25x38 grayscale	25 x 38 x 1	950	9,500

Middle layer

This layer isn’t immediately exposed to our program, so we call it a ‘hidden layer’. It’s this layer’s job to decide which of the perceptrons from the input layer are significant and reduce the weight given to the rest.

I’ve put 100 neurons in this layer mostly because 100 is a nice round number and that seemed to work out. Remember, this is a simple task so we don’t need to think too hard about what neurons go where.

Like the input layer, every neuron in this layer connects to every neuron in the output layer. This style of multilayered network where each neuron connects to all of the neurons in the next layer is called a ‘feed-forward’ network.

Output layer

This layer is the one that’ll actually answer the question that’s been burning in our minds this whole time: is this a three?

There are ten possible output values, so we have ten neurons in the output layer. The strength of the signal these neurons emit is the percentage chance that particular neuron thinks the image represents that number. This means that the summation of all of the signals differ greatly from the expected 100. In fact, (much like children) two or more output nodes might decide that they very much have the right answer and it’s everyone else who’s wrong.

Getting an actual answer

The simplest and most common way to resolve these disputes is to apply the softmax algorithm. Softmax is an incredibly complicated system that works like so:

Take the largest number in the outputs. Make it a 1
Make all the other numbers 0

…sorry, did I say incredibly complicated? I must have meant the other thing. Most networks used for classification tasks like this one use softmax at the end.

Here’s the code for this first neural network.

Network #2 (Left side)

We have a lot more pixels to look at on the right-hand side coupled with a larger number of possible outputs. A feed-forward network will have a LOT more nodes and connections than our previous task. Given that training a network takes ages, it’s in our best interest to architect the network to reduce the number of connections. In this case, I split up the image into smaller overlapping sections and created a cluster of input neurons for each section:

This has the advantage of ‘compressing’ a section of the source image down to a few (in this case, three) nodes - much fewer connections and therefore faster training without much loss of granularity. Each colored square in the above diagram represents a single input cluster here:

Network	Inputs	Neurons	Connections
Feed-Forward	48 x 36	1,728 + 100 + 34 = 1,862	(1,728 * 100) + (100 * 34) = 176,200
Input Clusters	192 x 25	4,800 + (3 * 25) + 34 = 4,909	(4,800 * 3) + (3 * 25 * 34) = 16,950

Everything else

Aside from this first-layer architectural change, this network works the same way as the first one. There’s a middle hidden layer, an output layer, and softmax picks the best result out of the output neurons.

You can find the code for this second network here.

Back to Calculords

Phew, that was a lot of knowledge dumped in not-enough paragraphs. Fortunately, we’re almost there!

To recap, here’s the system:

I push a button in some UI. This triggers a screenshot of the device. NodeJS chops up the screenshot and runs it through two neural networks to determine the current game state.

Once the state is determined, it’s pushed through a Rust executable running a dynamic programming algorithm that will find the optimal solution for our current state. Said solution will be automatically plugged back into the phone, deploying troops automatically.

With this chain of tools, functions and hastily-typed blog post in place, I no longer have to suffer the indignity of gasp playing a mobile game! I’m free!

Breaking: Calculords 2 development is well under way! Keep an eye here to see news, art, features, and timeframes. pic.twitter.com/NIOL5gjeUr
— Calculords (@Calculords) January 2, 2016

NOOOOOOOOOOO!!!!!!

You can check out Calculords for yourself here.

Advice on recruiting emails

Mon, 15 Aug 2016 00:00:00 +0000

Originally, I wasn’t going to respond but I’ve got a soft spot in my heart for startup founders. If you don’t mind, here’s some unsolicited advice on recruiting:

When I’m looking for a job, I have three big questions in mind:

Will I have autonomy to do the best job I can?
Can I explore new areas instead of doing the same job over and over again?
Will the pay & total compensation be enough so I don’t feel cheated?

The first question, autonomy, is the biggest. Every startup claims that I’ll have “massive impact” etc, etc. All of us know that’s table stakes. My worry is that I’ll show up and be tasked with merely implementing someone else’s vision. We know engineers don’t join startups to implement, they join to grow and be a part of the creation of something amazing. You’d go a long way toward winning over potential recruits if you can convince them that they’ll be Solvers & Finders, not Implementers. Netflix knocks this out of the park - see the Freedom & Responsibility / Context, not Control sections of our culture deck. I understand you’re absolutely strapped for time, so creating a giant culture deck probably isn’t the best use of a Thursday. On the other hand, if recruiting top-quality talent is important, surely a sentence or two shouldn’t be a problem?

Secondly, let me let you in on a little secret: I don’t enjoy pure UI engineering. The last two jobs I’ve taken, I made sure that while I would mainly do UI (what I’m best at) I’d also have the opportunity to grow in other areas (stream processing, distributed systems, leadership). I believe Mark referenced this by mentioning “your experience in developing user-focused, scalable solutions”. More detail would be fantastic and help convince me to look further into your startup.

Finally, compensation. This is a tricky one to discuss as startups can’t compete with the big companies by definition. Naive founders try to pitch equity as compensation but only naive engineers buy that (and yes, that was me once upon a time…). I assume you don’t want to hire naive engineers. You don’t need to be top-of-market (that would be foolish at your stage) but instead just convince me I won’t be ripped off and/or asked to work obscene hours. This would be a good place to hammer home some of the perks from my first two points - there’s more to compensation than cash & options.

One quick note: Terms like ‘market leader’, ‘disrupting’, etc are so overused as to have lost all meaning. Overreliance on buzzwords is a big flag for “this person doesn’t know what’s actually special about them.” You’re building something amazing - don’t obfuscate that with meaningless filler words.

Good luck in your hunt!

The git's guide to git: Commits & their messages

Sat, 16 Jul 2016 00:00:00 +0000

The core unit of git is the commit. A commit is simple on the surface (some code changes and a message). Such simplicity belies the complexity within.

When to commit

I’ve heard many opinions on when one should commit from “commit early, commit often” to “one commit per release” (yikes).The only method I’ve found that consistently reduces developer headaches is to make one commit per change.This requires some discipline to break up small changes into their own commits and squashing multiple commits that all accomplish parts of the same change. “Change” itself is subjective, my rule of thumb being “The smallest edit to the code that can be considered complete”. Half a refactor might be able to run & pass tests but it’s not ‘complete’.

Making one commit per change supercharges tools like git bisect and git revert. As tempting as it is to integrate several small changes in a single commit, you’ll be much happier with multiple commits if one of those changes need to be reverted later.

Commit messages

Technically speaking, commit messages aren’t that exciting. There are two ways to write ‘em. If you run git commit, git will helpfully open an editor to write the commit message. (Unhelpfully the editor is always Vim, git is credited with being the only reason developers know how to exit Vim [0]). On the other hand, you can add the -m flag to add an inline commit message: git commit -m 'my commit'.

On the other hand, if you’re not a mythical 10x programmer, you work on a team with other people. (if you are, we could use a fellow like you). Even if you are flying solo, you’re on a team comprised of now you, one-month-ago you, two-month-ago, etc. We all need some trail of breadcrumbs to follow whatever insane trail of logic February us was thinking.

Which is why commit messages like this really tick me off:

commit 32f4410abb2a901016c4a8b23c4b487e36be9916
Author: Randall Koutnik <souper_leet_h4x0r@rkoutnik.com>
Date:   Tue Jun 14 15:05:51 2016 -0700

    Fix error on alert page

What was this guy thinking? Seriously, what was he thinking? I need to know the motivation for this commit - why, of all possible uses for his time, did this coder decide to make this one?

Context is king

When I was in college, I took Calc 2 and passed by a single point. I am not good with advanced math. As I was cramming for the Calculus final, searching the textbook for any hint of explanation that would impart an understanding of antiderivatives, I came across the most terrifying sentence ever written:

The explanation for such a phenomenon is so trivial it is left as an exercise for the reader

I hadn’t exercised in three days, so I went for a run. This didn’t help my understanding of integration by parts at all. The author of the textbook is well-read in calculus, as he literally wrote the book on it. He had a much greater context for calculus than I did and assumed I’d be able to pick up the finer points.

The author of the commit message above knows what bug was fixed. Their issue is in assuming the reader has the same context.

The three questions

Commit messages need to answer three questions:

What changed?
How was the change implemented?
Why was that change nessecary?

The commit above only answers “what” (and poorly at that). We’re still left wondering which error? Any code that’s existed for 90 seconds has multiple errors. If I know that a fix when cloning alerts that had an ampersand in the name introduced a regression and am combing through the history trying to find said commit, this message is near-useless.

This message also doesn’t provide a high level “how” of the fix. Was the answer better parsing? A less-restrictive regex? Skipping all the relevant unit tests? Answering “how” in the commit message saves the reader the effort of reading through the diff.

Finally, and most importantly, why? Fixing errors is important, sure. Why this error? Most modern git systems allow linking to an issue tracker; apply links liberally. Some, like GitHub, allow you to close an issue with a commit message containing Fixes #1234. Two birds with one stone!

A better commit

Let’s take a swing at fixing up the commit above. Using our new heuristics for message quality, we need to add:

Why the commit happened (through some external links)
How the change works
More details in the summary

commit 32f4410abb2a901016c4a8b23c4b487e36be9916
Author: Randall Koutnik <souper_leet_h4x0r@rkoutnik.com>
Date:   Tue Jun 14 15:05:51 2016 -0700

    Fix name parse bug when cloning alert with a '&' in the name

    Previously, the API would choke because we weren't escaping '&' in alert names on cloning.
    Now the clone service escapes the name before the API call.

    Fixes #1337

We now have a neat little summary, an explanation of the actual fix and a connection to external details. Now if (horrifyingly) some part of the system relied on unescaped data, we’d know exactly what commit to start with when the regression tickets come piling in…

[0] Seriously, you can set the editor git uses either through git config --global core.editor "your-editor-here" or the environment variable GIT_EDITOR.

Hacking Calculords part 2: Who needs fingers?

Tue, 14 Jun 2016 00:00:00 +0000

When we last left off, we had a handy-dandy algorithm that used dynamic programming to find the optimal solution to a Calculords level in a sane amount of time.

The biggest downside was that I still needed to manually transfer a bunch of numbers from the screen to the algorithm, and then painstakingly tap the results back into the phone, one by one. Since there was a puny meatbag involved, there were a lot of errors and I couldn’t live without the 1.5x “Perfect!” bonus.

Two paths lay before me, each glittering with possibility:

Write an interface to programmatically punch solutions into my phone
Do something useful with my life

The answer was crystal clear. What follows is the second entry in the journal of my journey to math and madness.

adb

After an hour of talking at my computer, I concluded that there was no native voice-activated Android control system on OSX. Dismayed, I turned to the next best thing: the adb tool. adb lets a hacker interact with an Android device without touching it at all. I’m sure iOS devs are applauding right now at the thought of never needing to touch another dirty droid again.

There are three things we need adb to do for us:

Take screenshots
Figure out the x/y coordinates of taps
Send taps

On macOS, install adb via brew install android-platform-tools; you’re on your own on other platforms, sorry. This is less a tutorial and more preemptive documentation in case I ever need to plead insanity. Once you’ve installed adb, enabled developer mode on your phone, and plugged everything in, use adb devices to make sure it’s all hooked up:

$ adb devices
List of devices attached
0123dd02f0babcde  device

(don’t worry, that’s not my real serial number)

Screenshots

Why, you may ask, do we need to take a screenshot of a device that’s right in front of us?!? Dear reader, you underestimate my ability to screw things up. During manual input, I need to rapidly glance back and forth between phone and computer. There is an abundance of things in between, such as a keyboard, pizza, and occasionally my cat. Any one of these things could momentarily distract me—flipping bits in my brain—and I’d enter the wrong number, causing minutes of lost ‘productivity’. The obvious answer is to double-check my work but then we’d run into the infamous Two Generals Problem, where two generals were having a nice lunch but the waiter got lost & the kitchen never received their order, so they decided to give up the whole war thing and become distributed systems experts.

In any case, a screenshot allows us to show the phone’s screen as close to the inputs as possible, greatly reducing errors and neck strain:

We’re using adbkit here to pull off the incredible feat of taking a screenshot:

let takeScreenshot = () => {
  let id = uuid.v4();
  let fileStream = fs.createWriteStream(`./public/screens/${id}.png`);

  return client.screencap(process.env.SERIAL)
    .then(function (screencap) {
      return new bluebird(resolve => {
        // Create a new promise that resolves when we've finished writing to file
        // Otherwise we get half-written nightmares
        screencap.pipe(fileStream);
        screencap.on('end', () => {
          resolve(id);
        });
      });
    });
};

Hurrah! Now we can procrastinate slightly faster and with fewer mistakes than ever before!

Input!

Now, we don’t need to look at the phone before the algorithm runs. In order to keep our necks un-sprained during the back nine, we need to coax adb into sending input into the device for us. Thankfully, 2/3ds of this is simple:

adb shell input tap x y

We want to execute a shell command that sends a tap event to a set of coordinates. Finding the right coordinates turned out to be a backbreaking journey.

The Problem

On the surface, things are simple. adb provides a getevent function that echoes out all the details of events on the device, including the x/y coordinates of the event. But this is software, so we should be suspicious of anything simple!

$ adb shell getevent -l
add device 1: /dev/input/event5
  name:     "msm8974-taiko-mtp-snd-card Headset Jack"
add device 2: /dev/input/event4
  name:     "msm8974-taiko-mtp-snd-card Button Jack"
add device 3: /dev/input/event3
  name:     "hs_detect"
add device 4: /dev/input/event1
  name:     "touch_dev"
add device 5: /dev/input/event0
  name:     "qpnp_pon"
add device 6: /dev/input/event2
  name:     "gpio-keys"
/dev/input/event1: EV_ABS       ABS_MT_TRACKING_ID   00000056
/dev/input/event1: EV_ABS       ABS_MT_POSITION_X    000001af
/dev/input/event1: EV_ABS       ABS_MT_POSITION_Y    000003a0
/dev/input/event1: EV_ABS       ABS_MT_PRESSURE      00000035
/dev/input/event1: EV_ABS       ABS_MT_TOUCH_MAJOR   00000006
/dev/input/event1: EV_SYN       SYN_REPORT           00000000
/dev/input/event1: EV_ABS       ABS_MT_TRACKING_ID   ffffffff
/dev/input/event1: EV_SYN       SYN_REPORT           00000000
/dev/input/event1: EV_ABS       ABS_MT_TRACKING_ID   00000057
/dev/input/event1: EV_ABS       ABS_MT_POSITION_X    0000018d
/dev/input/event1: EV_ABS       ABS_MT_POSITION_Y    0000046d
/dev/input/event1: EV_ABS       ABS_MT_PRESSURE      00000036
/dev/input/event1: EV_SYN       SYN_REPORT           00000000
/dev/input/event1: EV_ABS       ABS_MT_TRACKING_ID   ffffffff
/dev/input/event1: EV_SYN       SYN_REPORT           00000000

Annoyingly the coordinates are in hex, though that’s trivial to convert. However, these are the wrong coordinates. Converting them to decimal and sending a tap will trigger a tap in a entirely different location! adb must be a politician or a UI developer as its position is relative.

getevent assumes that the device is always in portrait mode and assigns 0/0 appropriately:

On the other hand, input tap works with the current position (in this case, landscape):

This difference is not documented anywhere that I could find (you read it here first, folks!). Once the tapping was set up, we can automagically enter in the best solution (‘best’ as in ‘deploys the most cards’, with no regard for order or overall strategy).

Strategy

Our AI places all of its units in the top lane. As it turns out, Calculords isn’t calibrated to deal with someone deploying ALL of their troops every time. Ninja Crime made the fatal mistake of assuming their fans weren’t that dementedly obsessed with Calculords. Our overwhelming firepower absolves the need for strategy. We’ll deploy ~6 troops every turn (some power-up cards are in the deck, other cards deploy multiple units). Every unit deployed moves the column ahead one square. The standard pace is 4 squares/turn, so putting everyone in one lane speeds up our victory by 2.5x.

Later enemies have abilities that can restrict what lane you place troops into. I solved this by crying a lot and dropping down to manual control. A more clever solution is left as an excercise for the reader.

Disaster strikes

With neck intact and all of my x’s dotted and y’s crossed, I thought I was in the clear. Then a terrible, awful thing happened: I leveled up.

Remember just how mind-boggling huge the number of calculations we were doing was with only eight integers? Turns out there’s some ominous foreshadowing in the corner:

After a string of major victories on the field of battle, I was awarded a ninth and final integer to bring with me into the trenches. This drove the running time of the solver algorithm from an upper bound of 90 seconds to an average time of Out of Memory. V8-driven JS isn’t very memory-efficient.

🎵 Hello darkness my old friend
I’ve come to crash with you again
with the garbage softly creeping
across the stack that I was sweeping🎵
— Randall Koutnik (@rkoutnik) June 4, 2016

I had been looking for an excuse to try Rust out (Slogan: “We’re on HN often, so we must be good!”). Rust is the complete opposite of JavaScript - it’s incredibly strict about who has access to what value when. It’s a systems level language, which means it doesn’t compile. A lesser-known secret of the Rust community is that the compiler just picks a random compile-time error and throws it. No one has ever successfully compiled Rust code.

There have been plenty of articles discussing Rust, so I’ll just stick to one particular problem I encountered. In the previous episode, we used dynamic programming (a single var containing all of the paths we’ve been to) in order to cut down on the overall number of calculations. This was accomplished in JavaScript by having a variable in the parent function’s scope keep track, while a child function recursed:

function parent() {
  let placesWeHaveBeen = {};
  function child() {
    // check placesWeHaveBeen
    child();
  }
}

This let us build out our wide tree of recursion while still keeping the number of calculations relatively low. Rust, on the other hand was stubborn. Rust allows nested functions, but the coder must make a choice between accessing variables in the parent scope (via a closure) XOR recursing.

I’m sure steveklabnik will appear in the HN comments with some wizardy trick to fix this but it was quite a problem for mortal me. I ended up creating a CalcEnv struct and passing that along to my recursing function (hurrah pointing):

struct CalcEnv {
  cards: Vec<i32>,
  solutions: HashMap<Vec<i32>, Vec<String>>,
  paths: HashSet<Vec<i32>>
}

fn explore (stack: &Vec<String>, ints: &Vec<i32>, mut env: &mut CalcEnv) {
  // Various code-type things
  explore(&new_stack, &new_ints, &mut env);
}

This allowed me to have a global dictionary of visited paths, albeit a slightly strange one. This may be standard practice in the general Rust community– I’m just a newcomer. One advantage of Rust is that converting this code to use multiple threads was fairly simple (though I still needed a global mutex, which meant that multithreading didn’t help much).

Enough whining; here are the numbers (run on a MBP, using time command). Sometimes I lucked out and JS didn’t choke on a n=9 solution:

`n`	JS	Rust
8	10.537s	5.883s
9	3m 13s	1m 32.30s

Phew - not only are we not dying on n=9 but it’s running ~2x faster! Memory consumption also drops by a massive amount, with Rust using about 12MB where JS chewed up over a gigabyte.

Now what?

When we started, we had a neat algorithm. Now there’s a solid UI around it, programmatic interfacing with the device, and significant speed boosts from a lower-level language.

On the other hand, I still have to type in the numbers.

Next up is the thrilling conclusion wherein we’ll build a neural network to recognize digits to save us from all that tedious typing.

I wish I were kidding….

Read Part 3 here

You can check out Calculords for yourself here.

Randall Koutnik

Passing the generic tech interview

Here because they were told to

Here to show off how smart they are

Here to ask The Specific Question

The Culture Fit Interview

The Corporate Culture Gap

The Corporate Culture Gap

Small Gaps

Large Gaps

An Example Gap

Conclusions

Exploring JavaScript's types

What’s a ‘type’?

null vs undefined

Where’d array and function go?

Assigning types in TypeScript

The special any type

Creating your own types

Type Inference

Finally

Why is TypeScript so great?

Stateful Filters in RxJS

Incentivize Teams, not People

Hacking Calculords part 3: A math-free intro to neural networks

Networking

Network #1 (right side)

Input layer

Middle layer

Output layer

Getting an actual answer

Network #2 (Left side)

Everything else

Back to Calculords

Advice on recruiting emails

The git's guide to git: Commits & their messages

When to commit

Commit messages

Context is king

The three questions

A better commit

Hacking Calculords part 2: Who needs fingers?

adb

Screenshots

Input!

The Problem

Strategy

Disaster strikes

Now what?

`null` vs `undefined`

Where’d `array` and `function` go?