On interviewing

by Jason on April 3, 2015

We’ve all heard horror stories about terrible tech interviews. What makes them bad?

I’ve recently interviewed at a few places just because I was bored. It’s been 4 years since I’ve done this so I was curious how interviews were conducted today. It was never super serious nor am I unhappy at my current position.

One notable terrible tech interview process has been Uber. It went something like this:

Day 1: Introductory email from recruiter
Day 2: Phone call with mostly clueless recruiter who couldn’t answer any tech questions I had.
Day 2 (continued): Phone call with tech lead. No discussion about my background just discussion about general Uber tech. Ok..
Day 3: Given a week to complete a programming assignment. Took me 5 days while working full-time.
Day 8: Send code to recruiter. Wait… wait some more.
Day 9: Email recruiter to ask if there is any feedback
Day 15: Receive “feedback” that they liked my code and wanted to move forward
Day 17: Simple frontend remote pair programming exercise with frontend engineering lead from SF.
Day 20: Recruiter wants to schedule me to fly to SF to interview in person. Travel is to be paid for by me then refunded at some point.
Day 21: Email recruiter to ask if I can be interviewed in NYC instead… the position is in NYC after all and would rather not fly 8 hours to interview for 1/2 a day.
Day 22: Recruiter agrees, sets up interview in NYC.
Day 25: My schedule changes so I email recruiter to see if they can switch my interview time. Response from recruiter included: “but I wish you would have told us about your time constraint beforehand.”
Day 25 (continued): Told them to cancel interview

I don’t mean to single out Uber. But I think their terrible interview process highlights some fairly common mishaps in tech interviews.

Have a plan

It was clear that Uber didn’t have a solid game plan for the interview from the beginning. Why have someone spend 5 days on a relatively involved take home test only to follow up by quizzing them on fairly basic front-end techniques?  Even though I enjoyed speaking to all of the individuals in tech it still doesn’t make any sense.

It would have made more sense for Uber to start with a simple remote pair programming exercise to ensure that I’m competent and then follow through with a take home test.

Don’t waste peoples time. Have a game plan and know how and, more importantly, why you’re choosing to interview the way you are.

Take home tests, for example: they are controversial because they take a lot of time for someone to complete but they offer a great discussion in subsequent interviews. You can discuss the code, how you might optimize it, issues you faced/overcame, etc. In Uber’s case there was no mention of any follow up so it seems their take home tests are just a barrier to entry.

Just pay for the travel

You want the right people working for your company but they’re not always going to live within commuting distance of your main headquarters. Interviewing is hard to schedule as it is. Just pay for the damn travel – this is a no-brainer. You’re supposed to make it easy for the people you’re interviewing.

Uber: YOU’RE A TRANSPORTATION COMPANY. If you wanted me to interview in SF I am willing to bet you could have made that happen without putting the burden on me to schedule and pay for it. Kudos for adjusting so I could be interviewed in NYC instead but as you’ll see below that wasn’t really enough..

Skip the recruiter nonsense

The first step in so many interviews is speaking with a recruiter of some sort. Why? My opinion on this might sound callous (it probably is) but why am I talking to you?

Typically this phone call only answers one question: “Does this person have basic communication skills?”.

Good technical recruiters would also answer a second question with this phone call: “Is it worth investing another engineers time to speak with this person after me?”.

This first phone call, just like any work meeting, should have a purpose and a clear outcome. The vast majority of these first phone calls I’ve been a part of have served no purpose. The recruiters aren’t able to answer technical questions I have and don’t know enough about my background to decide on their own whether I am savvy enough to be interviewed.

So why do it?  Just stop.

I’m interviewing you too

Anyone who thinks interviews are one-sided are out of their minds. I absolutely love my job and I am in no rush to leave. I do what I love and I’m quite good at it.

So if I’m talking to you you aren’t just interviewing me. I’m also interviewing you to see if I want to give up my great job in exchange for the one we’re talking about.

So when I see a completely disorganized interview process, pointless phone calls with clueless recruiters, and attitude-laden statements like “but I wish you would have told us about your time constraint beforehand” I think I know what my decision is.

Dragon Warrior 4 in HTML5

by Jason on March 9, 2015

My latest endeavor has been to learn a bit of HTML5 game programming. After speaking with a few colleagues with significant experience in these things and also watching a few good YouTube videos I’ve decided to develop a game without using any game engines.

The goal is primarily to learn and to have fun and so far I’ve done a lot of both!

The game I have decided to build is a remake of Dragon Warrior 4 (NES) in HTML5.

Since I am totally new to game development I thought it would be interesting to document my progress via YouTube videos.

So if you’re interested then subscribe to my channel or have a look at the code as it’s developed.

Or, just play the game!

A case against the module design pattern

by Jason on November 28, 2013

The module design pattern is a particularly popular design pattern used in JavaScript these days.

The main reasons for its use are:

  1. “Private” variables via closure
  2. Global imports

A simple example of a module design pattern implementation looks like this:

var MODULE = (function(args) {
var _private_variable = null;
var _private_method = function() {};

this.public_variable = null;
this.public_method = function() {};

This is a very common pattern among JS devs but it is quite problematic.

The main issue is that it’s impossible to test any of the non-public methods. A common argument to this is that private methods shouldn’t be tested.

My argument against the module design pattern is this:

1. Your code is visible by anyone at any time. You’re not protecting anything. If you’re using JS to store sensitive information (encryption keys, for instance) then you’re out of your mind.
2. You limit the testability of your code
3. If you don’t follow a solid coding guideline then it could be difficult for new engineers to parse your code.

The module design pattern can be useful if private methods/variables are used sparingly and for the right reasons.

Image Preloading Optimization

by Jason on October 11, 2012

If you find yourself needing to load many images for your web application there are some things you must consider in order to achieve maximum performance.

WTF am I doing?!

Can you avoid so many images all together? Consider using CSS sprites.

Some other obvious considerations:

  • Compress the images
  • Use a CDN such as Amazon Cloudfront for hosting
  • Ensure proper caching is in place. Browser and server-side.


Ok, so you’ve exhausted the obvious, and yet you still have a ton of images to preload. How can we optimize this?

The first thing that you should realize is there is a limit to the number of concurrent downloads a browser can perform per host.
For most modern browsers this number is 6, but occasionally it can be higher or lower (FYI this is not well documented).

You’ll notice that big sites like Google, Flickr, etc tend to utilize 2-5 CDN hostnames to host their assets. This is the number you should strive for if possible.

The downside to additional hostnames is the extra latency involved in performing DNS lookups, so adding extra hosts will not always result in faster downloads. You must test.

Once you get extra hosts in place, think about using this library to help properly optimize the download queues.

JavaScript Image Preloader

JavaScript Event Factory

by Jason on August 5, 2012

I have started a new project this weekend on Github that I’m calling the JavaScript Event Factory.

I am mostly doing this so I can understand how to build messaging systems in JavaScript and it’s also my attempt to understand the convoluted Event-based architectures.

Currently this project is very much experimental, but as it grows the idea is that it will encapsulate the most common messaging patterns under a single namespace and follow the proper design patterns.

JavaScript Event Factory currently supports:

I may expand this in the future to add more patterns, but currently these appear to be the most widely used.

The thing I like most about my solution, so far, is that it does not rely at all on any DOM Events. Perhaps it’s naivety, but I saw no real need to utilize DOM Events, except for the useful Event.stopPropogation and Event.preventDefault. However, I have implemented my own version of this for when it’s necessary.

This approach allows me to create a DOM-independent messaging system. So this would allow simple objects to communicate with other objects without having to be tied to a particular node.

As always, your feedback would be highly appreciated.

Github Link

JavaScript Patterns Textmate Bundle

by Jason on June 25, 2012

Last night I started a new project that I’ll be adding to over time.

It’s a Textmate Bundle that will create skeleton code for various popular JavaScript patterns such as Module, Singleton, and Sandbox.
More will be added soon and I hope others will contribute!

JavaScript Patterns Textmate Bundle


by Jason on June 10, 2012

Today I started a new project named PackageStore which I expect to be iterating on over the next few weeks.

The main purpose of this library is to provide an interface exactly like localStorage for setting/getting variables, but behind the scenes storing the data in a single localStorage key. Also, it should provide very simple hooks to encrypt/decrypt this data.

So, why do this?

Modern applications are beginning to move to JavaScript. With the advent of Backbone and various other systems there has been a movement to move the majority of application code to the browser instead of the server. Managing application state now becomes an instant concern for any competent JavaScript developer.

Given that JavaScript applications are inherently manipulatable (read: insecure) you have to think of ways to make JavaScript hackers job difficult. So you do some common things such as compiling JavaScript, minifying JavaScript, using the Module design pattern so “private” variables are not easily manipulated, etc.

Another obfuscation tool is to store all state management variables within a single key, and encrypt the contents.

I welcome your feedback on everything!
Github Source

Konami Code in JavaScript

by Jason on June 9, 2012

Others have already done this many times, but I thought it would be an interesting challenge this morning to implement the Konami code in such a way that you can attach a callback which will be fired only after the code is successfully entered.

This generic approach is nice because it allows developers to do whatever they want when the code is entered.

Check it out

HTML Compressor, Closure Compiler, and Ant.

by Jason on June 6, 2012

The other day a friend of mine posted on Facebook that she was 10,000 days old.

About an hour later, I had created the Days Since Birth utility.

Still wanting to code more, I decided to make this project a bit more mature.

So, using Ant I was able to setup a simple target that compresses the HTML and runs the JavaScript through Google’s Closure Compiler.

I am considering other options, such as Linter’s (even though the code is already JSLint compatible), but would love other’s thoughts on it.


Python Function Timer Decorator

by Jason on March 26, 2012

I find myself often timing how long code blocks take to execute so I’m able to discover bottlenecks and compare performance between iterations.

A quick & simple way to do this is with a handy Python decorator.

import time
import logging as log

def log_timing():
    '''Decorator generator that logs the time it takes a function to execute'''
    #Decorator generator
    def decorator(func_to_decorate):
        def wrapper(*args, **kwargs):
            start = time.time()
            result = func_to_decorate(*args, **kwargs)
            elapsed = (time.time() - start)
            log.debug("[TIMING]:%s - %s" % (func_to_decorate.__name__, elapsed))
            return result
        wrapper.__doc__ = func_to_decorate.__doc__
        wrapper.__name__ = func_to_decorate.__name__
        return wrapper
    return decorator