I’ve used Angular 1 at my last couple of day jobs, and have gradually grown to be grumpy about it. At the time when it was released (2010), the framework had some really cool ideas baked in: automatic Model → View syncing (unlike Backbone), automatic View → Model syncing (like Knockout), observing arbitrary expressions, a built-in dependency injector, a neat filter syntax. All of this was pretty revolutionary; the framework took some time to learn, but once you did, you were suddenly really, really productive.
In the seven years since, Angular’s Big Ideas have been battle tested by thousands of engineering teams. Through this testing gauntlet, a lot of problems with its Big Ideas emerged and Angular 1 has since been supplanted by Angular 2. So as sort of a post mortem, I wanted to put my thoughts about where Angular 1 failed down on paper, to inform my own framework designs as well as others’ designs.
If you wrote in Scala or Haskell before you tried TypeScript, you may have found yourself wondering: Where are the Options at?
For those not familiar, here is an excellent introduction to Scala’s
Option type. At a high level,
Option is an abstraction over
null that gives useful semantics around running functions over possibly-null values. It implements a monad, a functor, and some other structures, but that’s not important for this post.
So, based on my experiences on both sides of the interview table, here goes. These are a sampling of questions I’ve asked and been asked when hiring frontend engineers. Keep in mind that some places (like Google) focus more on designing efficient algorithms, so if you want to work there you should practice past CodeJam problems in addition to the stuff below. If you have a question that belongs in one of these lists (or I’ve made a mistake somewhere), shoot me an email.
Flashback to your job interview for your first software engineering job: let’s write a Fibonacci function. We define the base cases of
1, then recurse to generate the rest:
Base64 encoding has been around for years, and when applied to images (among other data) in the form of Data URI’s, is a crucial tool in the performance geek’s arsenal.
While base64 encoding increases the byte size of encoded content by around 1/3, it has the potential to dramatically cut down on HTTP requests and latency per resource. Since many browsers allow only a few connections per host (iOS allows 4-6, IE8/9 allows 6, and IE6/7 allows just 2, as per the HTTP 1.1 Spec), inline images are often a good alternative to many small external images, which would be forced to be fetched in sequence rather than pipelined. For relatively small media inlined in CSS, another benefit comes in the form of no more flash of unstyled content: inline images will load at the same time as the containing CSS file.