• Passing the generic tech interview

    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.
  • The Corporate Culture Gap

    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.
  • Exploring JavaScript's types

    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.
  • Why is TypeScript so great?

    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.
  • Stateful Filters in RxJS

    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.
  • Incentivize Teams, not People

    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:
  • Hacking Calculords part 3: A math-free intro to neural networks

    So far in the calculords series we’ve accomplished:
  • Advice on recruiting emails

    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:
  • The git's guide to git: Commits & their messages

    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.
  • Hacking Calculords part 2: Who needs fingers?

    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.
  • Bypassing two-factor auth in Protractor

    Two-Factor authentication is practically mandatory in today’s world. The attack surface presented to malicious actors means that a short string is no longer sufficient to prove our identity. We can double down on effective authentication by centralizing it via OAuth. This decreases the attack surface, putting our precious identities in the hands of a few highly-skilled engineers instead of a swath of WordPress installers.
  • The Origin of Wheatley

    The alarm bells rang as the call went out: “Prod is down!” Our site had been felled by the Red Dragon of 500’s. I lept into action, logging in to see the foul beast face to face:
  • Wanted: Ninja Rockstar Code Monkey Hacker Unicorn

    We’re looking for the best of the best - but as you can already tell from the title, we have no idea what that looks like. We want someone experienced enough to implement our ridiculous ideas but paradoxically lacking the experience to realize what a raw deal we’re offering. Work long hours to implement vague ideas with no autonomy for vague promises of getting rich one day. After all, money’s the only thing that motivates anyone, right? Coding isn’t a creative field, it’s just telling the computer what to do.
  • Implementers, Solvers, and Finders

    I was talking to a former student when he brought up an article written by a well-seasoned programmer regretting his choice of career. This fellow had rejected the management path in order to stay in the coding trenches and as a result, ended up in some absolutely crummy situations. He writes about management antipattern after antipattern that left him sitting with the bill.
  • Hacking Calculords

    My wife was shopping. And not the typical hunter/killer cruise missile 24-pack-of-toilet-paper-ice-cream-and-that’s-it. Ok, full disclosure, I was indulging in the same shopping but the used book section of our local thrift store is smaller than the clothing department.
  • Questions to ask your interviewer

    Last time, we talked about how to design a technical interview as a filter, starting primarily with determining what sort of person is “good”. This time, I’m turning the tables to look at the other side of things. Let’s talk about some questions you can use to determine if a company is where you want to work.The tech world is a seller’s market for talent. It’s difficult to get a good read on a company from the information you have pre-interview. Companies of all shapes and sizes want to throw you through their gauntlet. Some interviewers will say whatever it takes to get you to sign, others look at their company with rose-tinted glasses. Neither will help you find a job you’ll love. Most questions are easily dodged (“What’s the worst part of this job?”, “There’s too much to do but you’ll fix that!”).
  • How I Interview

    Technical interviews are terrible because we don’t know what we’re filtering for.
  • git's guide to git: Stash

    Last time we checked in with our favorite unicorn management company, we learned about git bisect, a rarely-used tool that can absolutely save your bacon when the time comes. In this episode, let’s learn about git stash, something I use almost daily.Remember the last time you were elbows-deep in some code change and some PM came rushing over with a P0 bug that they’d just discovered (we reported it two weeks ago). Bob does. He finally got time to work in the big refactor we’ve all needed for months and this stupid bug crops up. Welp, someone has to fix it but Bob has a pile of unsaved changes. How should Bob proceed? He weighs his options:
  • The git's guide to git: Bisect

    Debugging is hard. Often you’ll be presented with a bug that was introduced “some time ago” without any further information. Before I learned about git bisect, my primary strategy was to flail around blindly, hoping my fingers would strike the keyboard just right to reveal the bug. The loud typing showed I was a hard worker and eventually I was promoted to senior architect. Once I joined the inner circle of the cabal, I was taught the secrets of git. I was eventually kicked out for my insistence that Wedge Antilles was a better pilot than Luke Skywalker (he is dangit!) and so as revenge, I bring you The Git’s Guide to git - a series on using git to its fullest.Here at Kittenitech, we’ve got a multi-billion-dollar SaaS product: UnicornTopia. It allows UnicornOps folks to easily manage large herds of distributed unicorns. Problem is, sometime in the last week, we introduced a really nasty bug. Paula over in Marketing tells us they’re receiving quite a few reports that setting the header color to blue causes unicorn riots. Fortunately, this is timeboxed - Paula helpfully says complaints started coming in less than a week ago, so we know the problem was introduced recently.
  • Building data warehouses for fun and profit

    A data warehouse is a way of structuring a database so that it is easy to answer business questions about your data. In a traditional database model, it would be difficult to construct a query that determines how much profit came from credit card sales. In a dimensional data warehouse, it’s a relatively simple JOIN.Unlike a typical database where data objects are modeled based on their relationships, a dimensional data warehouse schema has two table types: Dimension and Fact. Dimension tables are the nouns of the data warehouse world - think users and products. They are largely denormalized. Fact tables are verbs - they represent events happening, and are mostly comprised of foreign keys to the dimension. Think of them as a subject (dimension) and a predicate (fact). If you’re overwhelmed, don’t worry. We’ll get to some practical examples in just a second.
  • The Myth of Equity as Motivation

    Virtually every startup job offers a percentage ownership of the hiring company as part of an employee’s compensation package. According to AngelList, most startup software engineers in San Francisco can expect to receive 0.1%-4% of the company they work for.
  • Flat is weird

    Specifically, companies with a flat structure (no managers at all) are weird. Decades of management tradition tell us that Someone must be in charge and make sure everyone’s doing their work. Otherwise, everyone will goof off, right?And yet, somehow these companies manage to work out. I’m not even talking about the big ones that hog all the attention (looking at you, GitHub). Big, flat companies are wonderful case studies on their own but, much like quantum physics, it’s when things reach the tiny startup scale that they start to get weird. A team of five won’t have a full-time manager (unless something goes drastically wrong). How do things get done? Who decides what to do next? What happens when (gasp) people disagree?
  • Valley Talent

    “Knowledge is knowing a tomato is a fruit. Wisdom is not putting it in a fruit salad” -Anonymous
  • Don't start a hosting company

    I talk to a lot of people who are just starting their first startup. A large percentage of them want to know what it’ll take to start a webhosting company. This isn’t surprising, as web hosting companies like GoDaddy are very visible. The first step to any project is some sort of hosting. The technical challenges don’t seem overwhelming to the beginner - chances are, they’ve played with some sort of server already. Most importantly, hosting services seem to make a lot of money. To the uninitiated, this seems like a great area to enter. In this essay, I hope to explain why you shouldn’t start a hosting service, while also explaining more general pitfalls beginners encounter.

subscribe via RSS