See discussions on Reddit

In JavaScript, objects are handy. They allow us to easily group multiple pieces of data together. After ES6, we got a new addition to the language - Map. In a lot of aspects, it seems like a more capable Object with a somewhat clumsy interface. However, most people still reach for objects when they need a hash map and only switch to using Map when they realize the keys can't just be strings for their use cases. As a result, Map remains underused in today's JavaScript community.

In this post, I will break down all the reasons when you should consider using Map more and its performance characteristics with benchmarks.

In JavaScript, Object is a pretty broad term. Almost everything can be an object, except for two bottom types - null and undefined. In this blog post, Object only refers to plain old objects, delimited by a left brace { and a right brace }.

TL;DR:​

• Use Object for records where you have a fixed and finite number of properties/fields known at author time, such as a config object. And anything that is for one-time use in general.
• Use Map for dictionaries or hash maps where you have a variable number of entries, with frequent updates, whose keys might not be known at author time, such as an event emitter.
• According to my benchmarks, unless the keys are strings of small integers, Map is indeed more performant than Object on insertion, deletion and iteration speed, and it consumes less memory than an object of the same size.

Why Object falls short of a hash map use case​

Probably the most obvious downside of using objects for hash maps is that objects only allow keys that are strings and symbols. Any other types will be implicitly cast to string via the toString method.

const foo = [];
const bar = {};
const obj = { [foo]: 'foo', [bar]: 'bar' };

console.log(obj); // {"": 'foo', [object Object]: 'bar'}

More importantly, using objects for hash maps can cause confusion and security hazards.

Unwanted inheritance​

Before ES6, the only way to get a hash map is by creating an empty object.

const hashMap = {};

However, upon creation, this object is no longer empty. Although hashMap is made with an empty object literal, it automatically inherits from Object.prototype. That's why we can invoke methods like hasOwnProperty, toString, constructor on hashMap even though we never explicitly defined those methods on the object.

Because of prototypal inheritance, we now have two types of properties conflated: properties that live within the object itself, i.e. its own properties, and properties that live in the prototype chain, i.e. inherited properties. As a result, we need an additional check (e.g. hasOwnProperty) to make sure a given property is indeed user-provided, as opposed to inherited from the prototype.

On top of that, because of how the property resolution mechanism works in JavaScript, any change to Object.prototype at runtime will cause a ripple effect in all objects. This opens the door for prototype pollution attacks, which can be a serious security issue for large JavaScript applications.

Fortunately, we can work around this by using Object.create(null), which makes an object that inherits nothing from Object.prototype.

Name collisions​

When an object's own properties have name collisions with ones on its prototype, it breaks expectations and thus crashes your program.

For example, we have a function foo which accepts an object:

function foo(obj) {
  //...
  for (const key in obj) {
    if (obj.hasOwnProperty(key)) {
    }
  }
}

There is a reliability hazard in obj.hasOwnProperty(key): given how property resolution mechanism works in JavaScript, if obj contains a user-provided property with the same name hasOwnProperty, that shadows Object.prototype.hasOwnProperty. As a result, we don't know which method is going to get called exactly during runtime.

Some defensive programming can be done to prevent this. For example we can "borrow" the "real" hasOwnProperty from Object.prototype instead:

function foo(obj) {
  //...
  for (const key in obj) {
    if (Object.prototype.hasOwnProperty.call(obj, key)) {
      // ...
    }
  }
}

A shorter way might be invoking the method on an object literal as in {}.hasOwnProperty.call(key) however it is still pretty cumbersome. That's why there is a newly-added static method Object.hasOwn.

Sub-optimal ergonomics​

Object doesn't provide adequate ergonomics to be used as a hash map. Many common tasks can't be intuitively performed.

size​

Object doesn't come with a handy API to get the size, i.e. the number of properties. And there are nuances to what constitutes the size of an object:

• if you only care about string, enumerable keys, then you can convert the keys to an array with Object.keys() and get its length.
• if you want to account for non-enumerable string keys, then you have to use Object.getOwnPropertyNames to get a list of the keys and get its length.
• if you are interested in symbol keys, you can use getOwnPropertySymbols to reveal the symbol keys. Or you can use Reflect.ownKeys to get both string keys and symbol keys all at once, regardless if it is enumerable or not.

All the above options take a runtime complexity of O(n) since we have to construct an array of keys first before we can get its length.

iterate​

Looping through objects suffers from similar complexity.

We can use the good old for ... in loop. But it reveals inherited enumerable properties:

Object.prototype.foo = 'bar';

const obj = { id: 1 };

for (const key in obj) {
  console.log(key); // 'id', 'foo'
}

We can't use for ... of with an object since by default it is not an iterable, unless we explicitly define the Symbol.iterator method on it.

We can use Object.keys, Object.values and Object.entries to get a list of enumerable, string keys (or/and values) and iterate through that instead, which introduces an extra step with overhead.

Finally, the insertion order is infamously not fully respected. In most browsers, integer keys are sorted in ascending order and take precedence over string keys even if the string keys were inserted before the integer keys.

const obj = {};

obj.foo = 'first';
obj[2] = 'second';
obj[1] = 'last';

console.log(obj); // {1: 'last', 2: 'second', foo: 'first'}

clear​

There is no easy way to remove all properties from an object, you have to delete each property one by one with the delete operator, which has been historically known to be slow. However, my benchmarks show that its performance is actually not an order-of-magnitude slower than Map.prototype.delete. More on that later.

check property existence​

Finally, we can't rely on the dot/bracket notation to check for the existence of a property because the value itself could be set as undefined. Instead we have to use Object.prototype.hasOwnProperty or Object.hasOwn.

const obj = { a: undefined };

Object.hasOwn(obj, 'a'); // true

Map for Hash Map​

ES6 brings us Map. It is much more suited for a hash map use case.

First of all, unlike Object, which only allows keys that are strings and symbols, Map supports keys of any data type.

However if you are using Map to store meta-data for objects, then you should use WeakMap instead to avoid memory leak.

But more importantly, Map provides a clean separation between user-defined and built-in program data, at the expense of an additional Map.prototype.get to retrieve entries.

Map also provides better ergonomics: A Map is an iterable by default. That means you can iterate a map easily with for ... of, and do things like using nested destructuring to pull out the first entry from a map.

const [[firstKey, firstValue]] = map;

In contrast to Object, Map provides dedicated APIs for various common tasks:

• Map.prototype.has checks for the existence of a given entry, less awkward compared to having to Object.prototype.hasOwnProperty / Object.hasOwn on objects.
• Map.prototype.get returns the value associated to the provided key. One might feel this is clunkier than the dot notation or the bracket notation on objects. Nevertheless it provides a clean separation between user data and built-in method.
• Map.prototype.size returns the number of entries in a Map and it is a clear winner over the maneuvers you have to perform to get an object's size. Besides, it is much faster.
• Map.prototype.clear removes all the entries in a Map and it is much faster than the delete operator.

Performance extravaganza​

There seems to be a common belief among the JavaScript community that Map is faster than Object, for the most part. There are people who claimed to see noticeable performance gains by switching from Object to Map.

My experience of grinding LeetCode seems to confirm this belief: LeetCode feeds a huge amount of data as the test cases to your solution and it times out if your solution is taking too long. Questions like this only time out if you use Object, but not Map.

However, I believe just saying "Map is faster than Object" is reductive. There must be some nuance that I wanted to find out myself. Therefore, I built a little app to run some benchmarks.

Benchmarking implementation details​

The app has a table that shows the insertion, iteration, and deletion speed measured on Object and Map.

The performances of insertion and iteration are measured in operations per second. I wrote a utility function measureFor that runs the target function repeatedly until the specified minimal amount of time threshold (i.e. the duration input field on the UI) has been reached. It returns the average number of times such a function is executed per second.

function measureFor(f, duration) {
  let iterations = 0;
  const now = performance.now();
  let elapsed = 0;
  while (elapsed < duration) {
    f();
    elapsed = performance.now() - now;
    iterations++;
  }

  return ((iterations / elapsed) * 1000).toFixed(4);
}

As for deletion, I am simply going to measure the time taken for using the delete operator to remove all properties from an object and compare it with the time with Map.prototype.delete for a Map of the same size. I could use Map.prototype.clear but it defeats the purpose of the benchmarks as I know for sure it is going to be vastly faster.

In these three operations, I pay more attention to insertion since it tends to be the most common operation I perform in my day-to-day work. For iteration performance, it is hard to come up with an all-encompassing benchmark as there are many different variants of iteration we can perform on a given object. Here I am only measuring the for ... in loop.

I used three types of keys here:

1. strings, e.g. yekwl7caqejth7aawelo4.
2. integer strings, e.g. 123.
3. numeric strings generated by Math.random().toString(), e.g. 0.4024025689756525.

All keys are randomly generated so we don't hit the inline-cache implemented by V8. I also explicitly convert integer and numeric keys to strings using toString before adding them to objects to avoid the overhead of implicitly casting.

Lastly, before the benchmark begins, there is also a warmup phase for at least 100ms where we repeatedly create new objects and maps that are discarded right away.

I put the code on CodeSandbox if you want to play with it.

I started with Object and Map with a size of 100 properties/entries, all the way to 5000000, and had each type of operations keep running for 10000ms to see how they performed against each other. Here are my findings...

string keys​

Generally speaking, when keys are (non-numeric) strings, Map outperforms Object on all operations.

But the nuance is that when the number of entries is not really huge (under 100000), Map is twice as fast as Object on insertion speed, but as the size grows over 100000, the performance gap starts to shrink.

I made some graphs to better illustrate my findings.

The above graph shows how insertion rate drops (y-axis) as the number of entries increased (x-axis). However because the x-axis expands too wide (from 100 to 1000000), it is hard to tell the gap between these two lines.

I then used logarithmic scale to process the data and made the graph below.

You can clearly tell the two lines are converging.

I made another graph plotting how much faster Map is in relation to Object on insertion speed. You can see Map starts out being about 2 times faster than Object. Then over time the performance gap starts to shrink. Eventually Map is only 30% faster as the size grows to 5000000.

Most of us will never have more than 1 million entries in an object or map though. With a size of a few hundreds or thousands of entries, Map is at least twice as performant as Object. Therefore, should we leave it at that and head over to start refactoring our codebase by going all in on Map?

Absolutely not... or at least not with an expectation that our app becomes 2 times faster. Remember we haven't explored other types of keys. Let's take a look at integer keys.

integer keys​

The reason I specifically want to run benchmarks on objects with integer keys is that V8 internally optimizes integer-indexed properties and store them in a separate array that can be accessed linearly and consecutively. I can't find any resources confirming it employs the same kind of optimization for Maps though.

Let's first try integer keys in the range of [0, 1000].

As I expected, Object outperforms Map this time. They are 65% faster than maps for insertion speed and 16% faster to iterate.

Let's widen the range so that the maximum integer in the keys is 1200.

It seems like now Map s are starting to get a little faster than objects for insertion and 5 times faster for iteration.

Note that we only increased the integer keys' range, not the actual size of Object and Map. Let's bump up the size to see how that affects the performances.

With a size of 1000 properties, Object ends up being 70% faster than Map for insertion and 2 times slower for iteration.

I played with a bunch of different combinations of Object/Map sizes and integer key ranges and failed to come up with a clear pattern. But the general trend I am seeing is that, for as the size grows, with some relatively small integer being the keys, objects can be more performant than Maps in terms of insertion, always roughly the same for deletion and 4 or 5 times slower to iterate. The threshold of max integer keys at which objects start to be slower for insertion grows with the size of the objects. For example, when the object only has 100 entries, the threshold is 1200; when it has 10000 entries, the threshold seems to be around 24000.

numeric keys​

Lastly, let's take a look at the last type of keys - numeric keys.

Technically, the previously mentioned integer keys are also numeric. Here numeric keys specifically refer to the numeric strings generated by Math.random().toString().

The results are similar to those string-key cases: Maps start off as much faster than objects (2 times faster for insertion and deletion, 4-5 times faster for iteration), but the delta is getting smaller as we increase the size.

Memory usage​

Another important facet of benchmarking is memory utilization.

Since I don't have control over the garbage collector in a browser environment, I decided to run benchmarks in Node.

I created a little script to measure their respective memory usage with manually triggered full garbage collection in each measurement. Run it with node --expose-gc and I got the following results:

{
  object: {
    'string-key': {
      '10000': 3.390625,
      '50000': 19.765625,
      '100000': 16.265625,
      '500000': 71.265625,
      '1000000': 142.015625
    },
    'numeric-key': {
      '10000': 1.65625,
      '50000': 8.265625,
      '100000': 16.765625,
      '500000': 72.265625,
      '1000000': 143.515625
    },
    'integer-key': {
      '10000': 0.25,
      '50000': 2.828125,
      '100000': 4.90625,
      '500000': 25.734375,
      '1000000': 59.203125
    }
  },
  map: {
    'string-key': {
      '10000': 1.703125,
      '50000': 6.765625,
      '100000': 14.015625,
      '500000': 61.765625,
      '1000000': 122.015625
    },
    'numeric-key': {
      '10000': 0.703125,
      '50000': 3.765625,
      '100000': 7.265625,
      '500000': 33.265625,
      '1000000': 67.015625
    },
    'integer-key': {
      '10000': 0.484375,
      '50000': 1.890625,
      '100000': 3.765625,
      '500000': 22.515625,
      '1000000': 43.515625
    }
  }
}

It is pretty clear that Map consumes less memory than Object by anywhere from 20% to 50%, which is no surprise since Map doesn't store property descriptors such as writable/enumerable/configurable like Object does.

Conclusion​

So what do we take away from all this?

• Map is faster than Object unless you have small integer, array-indexed keys, and it is more memory-efficient.
• Use Map if you need a hash map with frequent updates; use Object if you want a fixed key-value collection (i.e. record), and watch out for pitfalls that come with prototypal inheritance.

If you know the details of exactly how V8 optimizes Map or simply want to call out the flaws in my benchmarks, ping me. I'll be happy to update this post based on your information!

Notes on browser compatibility​

Map is an ES6 feature. By now most of us shouldn't be worried about its compatibility unless you are targeting a user base with some niche, old browser. By "old" I mean older than IE 11 because even IE 11 supports Map and at this point IE 11 is dead. We shouldn't be mindlessly transpiling and adding polyfills to target ES5 by default, because not only does it bloat your bundle size, it is also slower to run compared to modern JavaScript. Most importantly, it penalizes 99.999% of your users who use a modern browser.

Plus, we don't have to drop support for legacy browsers - serve legacy code via nomodule by serving fallback bundles so that we can avoid degrading the experience of visitors with modern browsers. Refer to Transitioning to modern JavaScript if you need more convincing.

The JavaScript language is evolving and the platform keeps getting better at optimizing modern JavaScript. We shouldn't use browser compatibility as an excuse to ignore all the improvements that have been made.

Follow me on Twitter

Context​

I have been interviewing a lot for the past year - not conducting interviews, I was the candidate being interviewed. Most of the interview processes I had with big tech companies consisted of 1-2 system design rounds depending on the level of the role. Unlike traditional back end-focused system design questions, for which you can find lots of prep resources online such as the famous Grokking System Design Interview or System Design Primer, I didn't know what to expect for a front end-focused system design interview as there are very few resources out there talking about this type of interviews.

Now that I have done a fair amount of system design interviews of both types, I want to give you a summary of what to expect, especially for the front end ones since I have been mostly working on the front end side.

Similarities​

Both front end-focused and back end-focused system design interviews share a lot of similarities in terms of the methodology you can adopt to solve the design questions:

• Starting with gathering system requirements
• Laying out a clear plan and identifying major distinguishable components of the system
• Proceeding to end-to-end API design
• Talking about optimization

Other kinds of similarities include:

• The interviewer is relying on you to drive the presentation. You can't rely on the interviewer to have your back.
• While the topics can be either micro or macro, you probably won't need to actually write code - it is rare to jam some portion of coding in the middle of a system design interview
• Unlike scantron school exams, both types will consist of mainly open ended questions. There probably isn't a checklist of things for you to cover one by one. Nor are you expected to drill deep into all of those. When you realize your interviewer is biased toward a particular part of the system, which they usually do, pivot your focus to that area. Other times you focus on your strengths and lead the conversation.

Differences​

During the back end-focused system design interviews, you would spend most of the time talking about things like:

• Back end/server side architecture, hand waving various back end services/components
• Discussing which type of database to use and how to aggregate data across different shards
• Designing SQL table schema
• Choosing the right cross-region strategy if your service has a global user base
• Any other kinds of system characteristics like latency, availability, fault tolerance, etc

For front end-focused system design interviews, you would spend most of the time talking about stuff like:

• Front end/client side architecture, such as the appropriate rendering pattern to choose - client side rendering, or server side rendering or static generation or something in between?
• What kind of data fetching mechanism to use - REST vs. GraphQL vs. gRPC and what should the APIs look like?
• Specifics about UI components
  • A news feed which has an infinite scroll behavior with all the images lazily loaded while ensuring the client side has the aspect ratio of the images upfront to prevent layout shift.
  • An autocomplete UI component which fetches search result data incrementally in batches while receiving images from server pushes in parallel.
  • A gallery page which pulls images and displays them in the correct order despite the asynchrony that comes with the network requests that might cause them to arrive out of order.
• How do you leverage different layers of cache to decrease latency or support offline mode.
• If they want to get framework-specific, which is totally possible, they might even ask you to define a particular React component's props or manage complex state in a React app.

A lot of the time, having one type of system design interview means you can oversimplify the opposite side:

• In a back end system design interview, the client-side/front end is reduced to an API layer - you don't need to consider all the intricacies of the browser or the pesky rerenders your real-time updates would cause.
• In a front end system design interview, you can treat the back end as a black box and you don't need to worry about how things like how to scale a database, or how your choice of using web sockets might affect the load balancers because of the need for sticky sessions support.

But again, this is a summary of my experience and depending on who your interviewers are (are they front end, back end and/or fullstack developers), the scope of the role and which team it is (are you going to be on a front end team or are you expected to work across the stack and stretch into the back end?) your front end system design interview might be a bit of a hybrid where some aspects of back end system design interviews might come up.

Outside of the differences with the technical topics I needed to dig deep into during the interviews, I found there are two other interesting differences that stand out between the two types:

• For front end system design interviews I was often encouraged to treat the interviewer as the product manager and we spent some time just fleshing out the brief solution for each user story. For the back end system design interviews, we didn't really get to talk about any user interaction (I am aware that the definition of users of your system might vary, depending on whether it is customer-facing vs. developer-facing)
• These two types of system design interviews also differ a lot in terms of estimating certain system's needs based on the potential scale of the system. The system needs can be storage needs or throughput needs or any other types of requirements.
  • It is common and expected to do these estimation during back end system design interviews since your design decision is only feasible when all of the system needs can realistically be met.
  • But for the front end system design interview, I rarely needed to do any quantitative estimation - for example, when I was designing some live feed during a front end system design interview, I didn't need to do estimations like "So let's say each message was roughly 140 characters long and it is utf8 so that's 140 bytes and an average user gets 10000 messages over a certain period of time so we ended up allocating 1.4mb memory on user devices". Again, I am not saying that this would never come up during a front end system design interview. In my experience, it is just much, much more rare compared to back end ones.

Career ceiling​

I am going to talk about something that is a little tangential. I don't think this is going to be a hot take but if you just want to pass the upcoming interviews, then you are welcome to skip this part.

I have done interviews for both front end focused roles and general software engineer roles. As I went through the preparation process for the system designs interviews, it just occurred to me that there is indeed a career ceiling for a pure front end focused software engineer role.

Ok so let's first get this out of the way - you can be extremely successful as either a front end developer or a back end developer.

Also it is hard to discuss any topic intelligently when we cannot agree on definitions. By saying front end developers I meant developers/engineers who solely work on the UI of a software system. And by saying career ceiling I meant the potential terminal title and the highest level such a developer/engineer can achieve in the technical individual contributor track.

This is an unspoken thing and a very impolite conversation. And there are exceptions to this but just statistically speaking there seems to be a career ceiling for front end-only developers.

Fighting the inertia​

Part of the ceiling comes from some traditional baggage:

• modern front end development is fairly new compared to the back end counterpart. I have seen some bias in the industry that front end is not real engineering compared to the back end and that absolutely needs to be combated.
• Power structures persist for a very long time and that's partially why most VPs of Eng and CTOs out there are back end/infra developers.

Economic reasoning​

I had this realization when I was going through the back end system design interviews vs. the front end system design interviews — the technical topics those interviews tend to cover led me to think about some economic reasoning leading to the perception of a "Front end ceiling" as well. Your value to the company really depends on how many machines/compute/storage run through you. As a developer/engineer, that means how much money you control and front end-only developers just don't take as much. Of course front end is just as hard and as important especially for consumer facing products but at the end of the day your compute is being run on someone else's machine or device and the company just doesn't value that as much as the compute that they themselves need to pay for and to scale.

Short-lived vs. long-running​

On top of that, normally the front end/web apps are short-lived on the client side - the user opens the browser tab that loads your app and after 20 minutes they might just close the tab, and all the memory allocated by your app is on their devices from that point onward. On the other hand, the back end servers/services behind probably keep running for months or even years. One implication resulting from this difference is that you can generally get away with bad code that leads to performance problems down the road in front end apps because they are short-lived and the scale of the data they are dealing with is probably small, but you cannot ignore that in a long-running back end service.

Good luck with your interviews.

Follow me on Twitter

Interview Process​

Applying for front end engineer roles is very similar to software engineer roles, but the interviews can be quite different. In my experience, for each company, there tend to be between 3 to 4 sessions. Most of them will be testing on JavaScript and discussion around web development technologies, and the rest on algorithms or behavioral.

One aspect that I have found interesting is that the younger the company, the more questions will lean towards JavaScript. This could be because hiring specifically for front end engineers is relatively new. Older companies used to only hire software engineers without regard to whether their focus was on the back end or front end.

JavaScript Rounds​

JavaScript is the main focus among all the companies I have interviewed with. It makes sense as front end work nowadays is very JavaScript-heavy. HTML and CSS knowledge is no longer a necessity thanks to component libraries and the likes.

JavaScript Minutiae​

To qualify for some companies, you might need to brush up on the minutiae of JavaScript. Topics like variable hoisting, holey arrays, non-strict mode, and switch case fall through came up. While I do not feel that knowing such things determine who is a better engineer, it is what it is. Here is my JavaScript cheat sheet.

JavaScript Topics​

After the first assessment, live interviews tend to test on more advanced JavaScript concepts such as the event loop, promises, async/await, scope and closures.

If you have been writing JavaScript applications for some time and have come across a variety of situations, this should not be too hard.

The most frequently asked question I have ever gotten is to implement debounce and throttle:

function debounce(fn, duration) {
  let id;
  return function (...args) {
    if (id) {
      // reset timeout and prevent it from triggering
      // if debounced function is called within duration
      clearTimeout(id);
    }
    id = setTimeout(() => {
      fn(...args);
    }, duration);
  };
}

function throttle(fn, duration) {
  let id;
  return function (...args) {
    if (id) {
      // if throttled function is called within duration,
      // do nothing
      return;
    }

    fn(...args);

    id = setTimeout(() => {
      id = null; // release "lock"
    }, duration);
  };
}

// usage example
const helloWorld = () => {
  console.log('hello world');
};
const debouncedHelloWorld = debounce(helloWorld, 1000);
const throttledHelloWorld = throttle(helloWorld, 1000);

The second most frequently asked question is to implement a sequential Promise.all of sorts:

function sequential(data, fetcher) {
  const helper = (index, results) => {
    if (index === data.length) {
      return results;
    }
    return fetcher(data[index]).then((datum) => {
      results.push(datum);
      return helper(index + 1, results);
    });
  };

  return helper(0, []);
}

// usage example
const fetcher = (i) => {
  return new Promise((resolve) => {
    setTimeout(() => resolve(i), 1000);
  });
};
sequential([1, 2, 3], fetcher);

Discussion Rounds​

Web development tools​

Regardless of how we wish to deny it, web development tools are an increasingly complex and diverse ecosystem.

Smaller companies, especially start-ups, require engineers who have a good understanding of these tools. Larger companies will be able to abstract tooling complexity away from engineers unless the role demands it.

As such, web development tools like Webpack and Babel have become a common discussion topic.

A good understanding of tools like Webpack would be to be able to explain the following concepts:

• what is bundling
• what is tree-shaking
• what is lazy-loading and why does it matter
• how loaders work

React or web framework of choice​

If the role states that React knowledge is required, you may be expected to answer or code out React components. If you do not have React experience, using other frameworks would be possible, provided that you can explain well what is happening.

This may range from implementing a feature live or simply answering or explaining some React concepts such as useEffect's dependencies array or shouldComponentUpdate.

Work experience​

Aside from the two topics mentioned earlier, interviewers might dive into one or two things that they found interesting in your resume and ask you to elaborate.

As I had some experience in writing Babel plugins and jscodeshift code mods, I walked them through how I utilized those tools to help make the company codebase better.

Implementation Rounds​

In all of my interviews, I have only been asked to implement a feature twice. It is not a common question, but it may come up.

This would come down to how well-versed you are with your basics such as HTML and CSS, as well as tools and frameworks. As an example, one of the questions I have gotten was to implement an autocomplete search bar like Google's. If you have built something like that before, it is doable within an hour.

Implementation rounds feel very similar to algorithms, as you need to actively find the best solution while thinking out loud and explaining your decisions.

Algorithm Rounds​

As software engineers, we are not unfamiliar with algorithm questions. Leetcode and Hackerrank are common resources used for practicing such questions.

As I knew this was my weakness, this was where I spent the most time. It may be a little ironic that I chose Python over JavaScript as my language of choice for tackling algorithms. JavaScript's lack of a native minheap and binary search implementation made it a slightly worse choice.

For those who are just starting to learn Python or getting back into it, here's my Python cheat sheet.

Conclusion​

Front end software engineer roles are not very different from general software engineer roles, but they do tend to be more specialized and in some ways, require even more effort.

If you are passionate about this field and interested in what you do, this would not be too high of a hurdle. I hope my experience and tips were useful to you, and good luck in your search!

My manager told me that currently it's a bit hard to define requirements & expectations for higher tier / higher Individual Contributor (IC) level for Front End engineers in the organization. Since you are working at Facebook, I am wondering what are some requirements & expectations for higher IC level there for Front End engineers (maybe around IC4, IC5 and above if that's kinda the level you use there)?​

For smaller companies that might be true, but it's still possible if you don't limit yourself to front end work. Going up the levels is all about scope and complexity. IC3s (Junior Engineer) work on tasks, IC4s (Software Engineer) work on features, IC5s (Senior Software Engineer) work on projects, IC6s (Staff Software Engineer) work on huge projects spanning across teams, IC7s (Senior Staff Software Engineer) work on projects spanning across the org, IC8+s (Principal Software Engineer) work on projects spanning across the company or even influencing the industry. If you're able to show that you can handle scope of that magnitude, there shouldn't be a reason not to be compensated at that level. That said, the rough guide I proposed here is for a company the size of Facebook where we have 10s of thousands of Engineers. Doing work that impacts an entire company of 10 people likely won't be IC8 level work. For reference, React core team is mostly made up of IC5s/IC6s and one IC7. Flow has a number of IC5s and IC6s as it's technically complex and affects how the entire company writes JavaScript. GraphQL has many senior engineers and the creator of GraphQL is currently a director (IC8 equivalent).

Are you still doing a lot of Front End-related development work now? Be it in the company or personally? If yes, I am just curious what are the things you often do, and what do you like in particular about Front End development?​

I'm still doing a lot of Front End development for work. Less in a personal capacity ever since I stopped working on Docusaurus as a side project. You can check out my GitHub to see what stuff I've done. At work I'm in-charge of oculus.com and built the infra for it. I built a design system of React components for the content developers to develop the marketing pages.

I really like all aspects of Front End development, maybe except optimizing performance. At FB we build a lot of Front End-related tooling (e.g. Jest, GraphQL, Flow) and libraries (our internal CSS-in-JS solution, Docusaurus, React, Flux, etc) which is personally very exciting to me. Even within front end development, there are various layers - very user-facing stuff (HTML/CSS/visual related code) and back end (JavaScript stuff, network layer, storage), tooling (ESLint, Babel, TypeScript, webpack). I call myself a full front end stack developer as I'm decent across the entire front end stack. I'm especially excited about tooling work as the problems there are interesting and challenging. Typically only large companies face such problems because they only occur at scale, hence I really like being at FB because FB is one of such companies.

Personally, do you have any tips on how best to grow as a Front End engineer? Are there any particular areas that you'd recommend?​

Learn your fundamentals well. There are many UI and CSS libraries out there, but a good Front End developer still needs to know how to build a website without them. Peek beneath the abstraction layers and understand the problems these libraries are trying to solve, do not use them blindly. Keep building stuff - try to build a simple version of the libraries you frequently use, build interesting user interfaces and products, etc.

What do you think about developing breadth-wise vs depth-wise? For example, do you think it's important for a software engineer to know more about other fields besides the one they are currently working on? In particular, what do you think about a Front End engineer who knows BE (i.e. a full-stack developer), or a Front End engineer who knows mobile development (with the advent of React Native or Flutter)?​

I somewhat answered this in another blog post. Lemme know if your question isn't answered after reading it.

I'm honestly quite into front end development — web technologies, UI/UX, web design and stuff. But with there being more and more accessible to new developers (create-react-app, parcel and such), I just can't help but wonder if these skills are sufficient to survive in the tech industry today. Not that it's a bad thing! Lowering the barrier to entry for programmers is always good. However, for those like myself who would like to pursue front end development as a career, I'm just wondering if having these skills are enough.

Interesting question. I've asked myself the same question before but convinced myself that I'm probably fine just dabbling in Front End development for now. 😌

Front End is complex and getting increasingly so​

Most people would have used websites like facebook.com, youtube.com and gmail.com. These applications have hundreds of engineers working on them (thousands if you include the back end) due to the demanding nature of the application - it has to load fast, it has to be secure, it has to look pretty. These days, front end development is no longer just about building websites rendering static HTML. Many websites these days are in fact web applications and a lot of thought has to be put into the application architecture, and that requires good software engineering capabilities.

That's why you see many Front End tools these days like React, Redux, Relay, CSS modules, webpack, etc. These tools exist because of the ever-increasing requirements of building rich and performant user experiences on the web. Being a good Front End developer is very hard, there are many aspects to know about - HTML, CSS, JavaScript, Browser APIs, Security, Performance, Animation, SEO, Networking, the list is non-exhaustive and growing. There are always new problems to solve and new things to learn. JavaScript fatigue was a term pretty common a few years back due to the explosion of tools in the Front End ecosystem. Things have gotten more stable but the JavaScript community is currently still one of the fastest-moving communities.

Does the rise of mobile threaten the existence of web developers?​

Many products now have a native mobile app version and that might make people think that the existence of Front End (web) developers could be threatened. I think that is only true to a small extent. Certain applications like Uber and Lyft make sense to be mobile-first, but there are also many complex professional applications where web (or any interface with a larger screen) will always prevail, such as office productivity and design software. Viewing things at a more macro scale, both mobile apps and web apps fall under the category of client-side applications. Many core skills important for being a good web developer are also important for mobile app development - they are transferable across platforms.

Tools like React Native and Flutter have also been created to help engineers build products across platforms by only writing the code "once" (in quotes because that dream is still in development). This approach is not a silver bullet solution and has yet to prove itself adequately, but for prototyping small apps or even just certain parts of your mobile app, it works pretty well. In React Native, you write your application in JavaScript using React Native primitives, and the React Native runtime runs the code on the JavaScript engine in the platform to construct native app UI views and handle application logic. It's pretty similar to writing typical web front end code. Facebook's Ads Manager App and the Marketplace tab are built using React Native. There are numerous technologies that enable you to build native apps on mobile platforms by knowing web front end development.

Even though mobile usage is on the rise, there still exist many use cases at which the desktop excels. Google Suite, Microsoft Office, Design tools are still more efficiently operated on desktops. In fact, many desktop applications these days are built on HTML5 technologies instead of native desktop code using tools like Electron to package web application code into an executable shipped to users. You might already be using some of them without knowing - Slack, Discord, WhatsApp Desktop, VS Code, Atom Editor, just to name a few. I think developers who are only familiar with native desktop platform engineering skills have more reasons to worry than Front End developers.

The web is incredibly cross-platform!

Jack of all trades, master of one​

However, I think that being a Front End developer in many regards, is considered a specialized position. That's why it's important to be "T-shaped". I first got introduced to this term through my ex-manager at Grab, Tim Goh. He advised me to have a specialization (front end), yet still know a bit about everything. In other words, you are strong in your core fundamentals, but you also specialize in a particular area.

This is good advice and it's not new advice. In most university courses, students are expected to study the fundamental courses before choosing their area of specialization. In the context of a School of Computing in National University of Singapore, students start out in school by taking basic classes in Algorithms, Data Structures, Software Engineering, Operating Systems, Computer Networks, before choosing their specialization in deeper areas like Compilers, Computer Graphics, AI and Machine Learning, Media, Networking and more.

Having a strong foundation enables someone to make switching domains a possibility. There will definitely be a ramp-up process, but it can be made smoother with solid foundations, and with the skill of learning how to learn fast. In the extreme case where the web becomes irrelevant, and no companies want to hire front end developers anymore, front end developers with strong fundamentals can always slightly switch tracks by doing mobile or back end engineering, or even the hottest UI platform (AR/VR?) out there.

Having good tools to use (like Create React App, Parcel) doesn't eradicate the need for Front End developers to possess good software engineering skills. What will happen if you are the person tasked to build the tools? Good Front End developers (or Software Engineers really) go beneath the abstraction layer, understand how their tools work, and what problems the tool set out to solve. They also constantly seek to challenge and improve the status quo by building better technologies to cater to the ever-increasing demands.

At Facebook, the Front End Engineers are Software Engineers first, domain experts second. Many of the Front End engineers I know at Facebook have a deep understanding of the technical stack and don't just work on stuff related to the browser. At Facebook scale, front end work also involves building a lot of infrastructure to make our front end code base scale well with the growing technical and people needs. That means writing codemods to do large-scale refactoring, inventing new UI paradigms, performant testing frameworks, creating type-checkers for untyped languages, changing the ways we fetch data from our servers and managing it on clients. These tools wouldn't exist if the Front End engineers at Facebook didn't possess strong software engineering skills.

Pick up new, relevant skills​

It can be hard to pick up new skills at work in an unrelated domain if there are no opportunities to do so. Thankfully (or not), due to the explosion of tools in the Front End ecosystem, I've found an area which I have gained a new-found interest in - Programming Languages Theory (Static Analysis, Compilers, and Interpreters). Static analysis is incredibly important in tools that I use on a daily basis - it's being used by the module bundlers for bundling JavaScript files together, generating CSS from more user-friendly CSS syntaxes, compiling modern JavaScript into older versions of JavaScript that more common browsers can run, and even this blog post written in Markdown uses static analysis to be converted into HTML.

I've been toying with writing my own interpreter after learning this awesome book called Crafting Interpreters and will be further exploring this domain in my spare time, possibly building Front End-related tooling in future that leverages static analysis and compilation.

Adding new skills to my arsenal in a related but different domain helps me to stay relevant in the event that the industry no longer needs Front End developers 😱

In summary, although Front End development is considered quite specialized, there's enough demand and complexity for it to stay relevant in the years to come. What would threaten the web would be an entire shift of the way users interact with apps, perhaps to a non-visual paradigm like a brain-controlled interface. However, paradigm shifts don't happen overnight and there will be sufficient time to react (pun intended) in the case that ever happens. Being strong in your Software Engineering fundamentals and knowing how to learn new skills fast will help you in switching domains (and also careers).

Opinions are my own and do not represent the views of my employer.