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 engineers. 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: