Before I share my resources and how to get a gentle start on this handbook, let me warn you that you would need to allocate a minimum of 6 months to get really good and confident with some of the LeetCode questions. Do not neglect the behavioral questions too! I am not going to repeat some of the things that are mentioned in this handbook but rather help everyone with some useful shortcuts of mine to navigate this resource to ease your preparations.

Crafting your resume​

In most companies, the resume stage is the most important as it is the first stage that you will need to clear! For undergraduates, most hiring managers would only look at resumes that are within one page. The moment the second page is seen, they will not tend to consider. Hence, here are some tips that can help you to prepare your resume in under an hour to reduce your agony.

1. Use a career hiring tool like Kinobi. Kinobi saves you time in having to fix alignments unlike word as this career tool formats everything for you. Furthermore, they help you to score your resume so that you know where you stand when applying for a job.

2. As far as possible, attend career talks by your favorite companies because hiring managers are there and you can get some feedback about your resume. It is indeed helpful because you know what to look out for when applying.

3. Keep your sentences short and sweet, else you are out of the game.

   • Good example: "Developed a full-stack website that garnered positive responses from faculty and administration about course visualization." You need not provide tech stacks and let alone, links here. The sentence here is short and sweet and all in past tense.
   • Bad example: "Was a project manager for two projects- AI_ducation as well as the lift project for ALEF. Helped day-to-day operations by communicating with clients in Mandarin to map business requirements to technical requirements.". Over here, the sentence is long and things can be separated out into points. Furthermore, it does not describe the outcome of the project enough to say "Why should you be hired?".

4. To save time, while building your projects, apply good practices and also think of various optimizations in terms of algorithmic design, not forgetting system design. You can also show this off and this saved me a lot of time especially when it comes to grinding LeetCode.

5. Your LinkedIn stands out the most and less of your personal website unless it's design related or frontend related. Write more things that are still succinct on your LinkedIn. Show your work there and let recruiters interact with your work.

6. ATS-friendly resumes are the most important ones as recruiters screen high volumes of candidates everyday so they have less than even 5 seconds to look at your resume. Some companies use ATS to scan for good keywords.

How to use the Tech Interview Handbook easily​

I am about to recommend relevant sections to go in sequentially and how to systematically use them to your advantage especially in being real productive. This stage is normally faced when the resume stage has passed. Even then, months of prior preparation has to be done. However if you only have one month to prepare, I suggest the following tips:

1. Know your interview process. Ask your recruiter about the interview process.

2. Go to your Glassdoor page and pick out some of the past relevant interview questions that your company has done to get a gauge of what to expect. If you are unable to do those past questions, I suggest revising a good amount about the common topics. One common topic is array and hash table design. You can refer to the coding interview rubrics section get to know your interview rubrics. It helps and you know what to do.

3. Know and try various techniques for each LeetCode question. It's not purely about variety but more about if you were to even come back to the same question, will you be able to give a more optimal solution? If you don't know where to get started especially when solving problems in general refer to this coding interview techniques section.

   • Start with a whiteboard or pen and paper. Show your thought process.
   • In most companies, if you were to show your thought process while doing, interviewers tend to favour candidates who do this. If you are not confident, start thinking that you are explaining and teaching a 12 year old child about how to solve this question.
   • Code it out and write your own test cases. Get used to the HackerRank or LeetCode IDEs.
   • Now with virtual interviews, some companies tend to use HackerRank live to conduct whiteboard interviews. Prepare a pen and paper beside you as you work along. Prepare to remote desktop protocol (RDP) into your computer to show step-by-step workings.
   • Do not blurt out the solution straightaway as interviewers can tell that you memorize.

4. Last but not least for algorithms heavy interviews, you might really want to save your time looking at Grind 75. It's a useful curated source of questions to note how much you can prepare for your interview.

5. Always be prepared for even system design questions! You will never know what comes your way and this is where your projects come in and how much of good practices you apply in them and what do you learn. The System Design Primer is a good start.

Do not neglect behavioral interview questions​

Most candidates at least from what I know, tend to neglect this section. As a result, they pass up good opportunities because of this section.

I suggest reading Cracking the Coding Interview, which explains this section very well in detail. Here are some preparations that you can do before the interview.

1. Draw up a table in this format. This is so that you know what to say when a question about your projects come up.

   	Project 1	Project 2
   Strength 1
   Strength 2
   Weakness 1
   Weakness 2
   Improvement 1
   Improvement 2

2. For those with portfolio websites, do be prepared to answer "What do you think can be done better to improve your website?" I highly suggest inspecting your console and using UI/UX principles to state the improvements. It would be also good for front end engineering roles to state how you can better engineer your website.

3. When preparing, do not focus your answers heavily on your team. Instead, the interviewers want to see how you have grown as an individual and the difficulties that you encounter. Be also prepared to stand strong on your answers and do not give an "I think" vibes to the interviewer. They will tend to have a bad impression.

4. Certain companies go by rubrics for this and they do not disclose this! However, always be humble and thank the interviewers for helping even if you are unable to justify.

Interview day​

As always, have a goodnight sleep before and adjust your sleep cycle at least 3 days prior. If you do not know where to start form, start from a brute force solution and manipulate the data structure to your advantage.

Most interviewers like optimized solutions but they like how you can design a simple solution to the problem!

Conclusion​

All the best in your preparations! Hope my shortcuts help for those of you who are extremely busy!

Most technical interviews are over-indexing on coding​

Over the past two years, I have interviewed with over 10 different tech companies ranging from hot startups like Coinbase, Stripe, and Instacart to FAANG companies like Amazon and Meta, for Software Engineer positions of various levels.

The technical interview processes I have had all consisted of at least two rounds of coding interviews, where I either had to solve an algorithmic, LeetCode-type question or build a practical app/feature. During those coding interviews, I always started with an empty slate: if it was an algorithm-heavy interview question, there would be a literally empty file in the editor for me to start writing code; if it was a practical app building exercise, there might be some boilerplate code or some utilities/helper functions available but still I was expected to build the app/feature from scratch.

I do think they did a good job at assessing my coding ability. But the issue I see here is that the standard interview process in our industry has over-indexed on coding ability along. As a software engineer, apart from meetings and writing design docs, I’d say at least half of my programming work isn’t just coding – the other half largely involves searching through a codebase and reading existing code or code-adjacent artifacts like error messages, tests, and logs. And oftentimes, coding isn’t the hardest part.

What is programming exactly​

Programming is a complex task so it makes sense to dissect it so we can study the different phases, dimensions and components of it individually.

I have been reading The Programmer's Brain by Felienne Hermans. It is a book about the cognitive process involved in programming. Felienne divides programming into five more concrete activities: searching, comprehension, transcribing, incrementation, and exploration.

Searching is the activity where a programmer is looking for a specific piece of information in a codebase, such as the precise location of a bug you need to fix in the code.

Comprehension is reading the code to understand its functionality and the way it is intended to work. It also involves executing the code and observing the results.

Transcribing is about converting your thoughts or solutions to executable code. This is what we usually refer to as "coding" and is what the current standard coding interview process only focuses on.

Incrementation is about incrementing (iterating) on an existing codebase, such as adding a new feature. It is a mix of the previous activities, where a programmer has to search, comprehend and transcribe their thoughts to code.

Exploration is sketching and prototyping with code. Try things and use code as a means of thought. It is also a mix of the previous activities.

With this newfound knowledge, it is not hard to tell what exactly the current standard interview process lacks. Activities such as searching and comprehension are completely left out and you have no way to prove your competencies needed for a big part of a software engineer job.

It begs the question of what we can do to complement the interview process to cover all these activities. And the answer is to add a debugging interview in the process.

Debugging is all-encompassing​

When one is debugging, they engage in all five activities. It entails a sequence of searching, comprehension, exploration and writing code. And it is incredibly revealing to watch one debug:

1. Are they debugging with a plan, iteratively bisecting the code or just randomly tweaking the code?
2. How are they navigating their way through an unfamiliar codebase, forming different hypotheses about the bug?
3. Do they try to write a test that reliably reproduces the issue?
4. Are they able to find where things are diverging and trace to the root cause?
5. Are they familiar with the IDE or editor they are using and know how to use tools like breakpoints and watches to step through the code?
6. Do they understand how to read error messages and leverage stack traces?
7. Are they able to implement a fix at the end?
8. ...the list goes on and on

On top of its comprehensiveness, debugging is what software engineers do on a regular basis. It is relevant to the actual work.

Out of all the companies I have interviewed for, only Stripe conducted a debugging interview. They call it Bug Squash, where you’d dive into a large, well-written library codebase to fix real-world open-source bugs. I had a blast going through that interview which I can’t say about boring LeetCode questions.

Granted, preparing such a debugging interview involves more work for the company than just throwing a LeetCode question at the candidate. Still, having that in the process gives you more signals for selecting capable, experienced engineers. I hope more companies start to embrace that in their hiring process.

Further reading that can make you better at debugging​

• Debugging: The 9 Indispensable Rules for Finding Even the Most Elusive Software and Hardware Problems by Dave Agans
• Debugging Software by Mark Erikson
• How I got better at debugging by Julia Evans

Imagine you were a university student looking to land an entry-level software engineer job and you were having this technical coding interview. The interview question starts with a table showing amount of units of a product sold at the shop and the corresponding price per unit. The idea here is that there is an incentive for customers to buy in bulk – the more we can sell the lower the price:

purchase quantity                                  price per unit
    1-5                                              5 dollars
    6-10                                             4 dollars
    11-20                                            3 dollars
    20+                                              2.5 dollars

The task the interviewer asks you to do is to write out a function that takes the amount of the times being purchased as the input and output the price per unit according the table. So if the input is 5, the function returns 5, and if the input is 6, the function returns 4... you get the idea.

That's it. That is the whole question. "This is even simpler than Fizz Buzz," you think to yourself, "but it might lead to more difficult follow-up questions, like it might get tweaked into a binary search problem or something". So you start to write the following simple solution, expecting more in-depth follow-up questions to come.

function getPrice(amount) {
  if (amount >= 1 && amount <= 5) return '5';
  if (amount >= 6 && amount <= 10) return '4';
  if (amount >= 11 && amount <= 20) return '3';
  if (amount > 21) return '2.5';
  return 'unknown price';
}

However, to your surprise, after you came up with this solution, the interviewer just stops there, moves on to the next question or discusss something completely unrelated.

The next day, you get a rejection letter from the company.

The Tweet​

This is based off of a true story. It was a real interview question and the solution I wrote above was considered unacceptable by the interviewer, i.e. the tweet author.

#微代码 最近面试校招生的一个感想：有非常多的同学会写出解法1的代码，这让我很难理解。以至于只要看到有解法2的样子，印象上就会先加分了。 pic.twitter.com/g38d2A5Bjj

— toobug (@TooooooBug) September 13, 2021

A while ago this tweet went viral in the Chinese programming circle. The tweet author used this exact question to screen new grads for an entry-level software engineer position. The tweet and the question were written in Chinese so I translated this question into English.

In the tweet, he complained that he was having a hard time understanding (很难理解) why many students came up with the solution that we came up with above. Instead of a straightforward solution with a bunch of if statements, he said he was expecting an answer like this:

Compared to the first solution with a bunch of if statements, this solution, in his opinion, is more modular, extensible, and maintainable. That was the answer he had in mind and failing to arrive at this solution means you are weeded out in the interview process.

I am not sure how you feel about this, but in my opinion, this is a pretty pointless interview question to ask new grads. The first solution is totally fine. Under the right circumstances, the second solution is closer to what you would want in production code, even though it is still not quite the table-driven development you'd want.

There are so many things I want to unpack, so here is the tl;dr:

1. Different types/styles of interviews call for different answers and that should be clearly communicated during the interview. The first solution is totally fine as the answer to an algorithmic question.
2. Take control of your interview so you don't have to guess what the interviewer has in mind. You do this by asking clarifying questions. Keep asking until everything the interviewer is looking for is clear to you.
3. The table-driven method (what the second solution tries to achieve) optimizes for changes and that's why the interviewer (the tweet author) failed students who didn't come up with that answer.

The overarching theme in this post is that you should take control of your coding interview so you don't have to guess the answer your interviewer is thinking of.

Different styles of interviews calls for different answers​

Generally, there are two types of coding interviews:

1. Interviews that focus on algorithms & data structures
2. Interviews that focus on practical app/feature-building and test your hands-on engineering chops

Normally it should be easy to distinguish between these two types of interviews by merely looking at the question: Inverting a Binary Tree is a typical algorithmic question, while designing and implementing an auto-complete search feature is more about practical app-building. Although sometimes the two types of interview questions would blend. For example, you might be asked to (partially) implement a trie when you are talking about the design of an auto-complete search feature/service/component. But these two different types of interviews are meant to test different competences.

In a pure algorithmic, LeetCode-type of interviews, your main goal is to leverage the right data structures and come up with an efficient algorithm to solve the problem with the right set of memory/runtime complexity trade-offs as fast as you can. How readable, maintainable and extensible your code is, or whether it conforms to the current best practice in the the community/industry are not that important, or at least secondary to the main goal. You can go ahead and name your variables i, n, p, q and mutate that input array in-place without being judged as long as your solution passes the test cases under the time and memory limits.

As Joel Spolsky wrote in his blog post: with the algorithmic interview questions, he wants to see if the candidate is smart enough to "rip through a recursive algorithm in seconds, or implement linked-list manipulation functions using pointers as fast as you can write on the whiteboard".

For more experienced engineers/developers, the coding interview tends to lean into the practical app-building category, where readable, maintainable code and extensible program structure are what they look for, and all aspects of the full software development life cycle, even including error handling, are fair game to be asked, as they are important in real-world software building.

Here I don't make any value judgment about which type of interviews are good or better. I just pointed out that they exist and interviewers look for different things by conducting different types of interviews.

Take control over the interview​

As an interviewee, you want to make sure you understand which category the question falls into because the underlying core criteria on which you are assessed are different – you don't want to overload the capacity of the working memory of your brain with tasks that are secondary before you reach the main goal. You want to take control over the interview so you are not left in the dark.

One way to take control over the interview is to narrate your thoughts as you go and articulate any assumptions you have to make sure you get confirmation from your interviewer on your way forward or they should help you correct course.

If I were the candidate receiving this exact question, I would ask this upfront: "should I write production-grade code with good engineering practices or you are more interested in how I'd tackle the algorithm & data structure part?". That is probably one of the highest ROI questions we can ask during an interview. The interviewer would either tell me to write a workable solution under the constraints of the runtime or space characteristics or treat this as a real-world engineering problem with real-world tradeoffs.

With all that being said, it is a bad question to ask new grads​

The question itself doesn't test any of the core competencies that distinguish between brilliant programmers and mediocre ones. What's really being tested here, based on the (ideal) answer the interviewer (the author of the tweet) had in mind, is the whether the candidate – new CS grads without any significant experience working in the software industry – knows how to use the table-driven method to implement such a function.

I don't believe that any smart college student who can breeze through a graph traversal problem in an interview can't understand and pick up patterns like the table-driven method in just a couple of hours. On the other hand, any mediocre programmers who happened to read Code Complete can write a table-driven solution and pass the interview. Not to say that knowing good engineering practices is not a good thing; it is just that using that as the only hiring criteria to hire new grads is pointless and it doesn't help you find the smart kids.

Anyway, the moral of the story is don't be afraid to ask clarifying questions so you don't have to guess what the interviewer looks for and cares about if they are not being explicit about their expectations.

You can stop here if you don't care about technical discussions about this simple interview question.

Table-driven development​

Solution 2 resembles a form of table-driven development described in a classic programming book called Code Complete. But even if you have never read the book, you probably know this pattern from your experience working as a software developer/engineer.

At its core, it tries to separate data from logic: instead of having all the information about pricing strategy (the data) hardcoded in the function (the logic) as literal values, it separates them.

The pricing strategy is a business rule, and business rules tend to be the source of frequent changes. By encoding that in an external data structure (i.e. the array priceMap in this case), we make our program easier to accommodate future changes. Whenever the pricing strategy changes, we can just modify the entries in the array without touching the logic of the function. In other words, we isolate the unstable part, so the effect of a change will be limited.

However, I said it only resembles table-driven development that you'd use in production code but it is not quite there yet:

1. The pricing data is not fully separated from the logic as the array priceMap is still defined within the function
2. Magic numbers are still there

Depending on where the pricing data comes from, one possible variation of the table-driven method for this particular question is as follows:

// config.js
export const priceByRanges = [
  { min: 1, max: 5, price: '5' },
  { min: 6, max: 10, price: '4' },
  { min: 11, max: 20, price: '3' },
  { min: 21, max: Number.MAX_SAFE_INTEGER, price: '2.5' },
];

// app.js
import { priceByRanges } from './config.js';

function getPrice(amount) {
  // error handling for amount outside the range
  return priceByRanges.find(
    (priceByRange) => amount >= priceByRange.min && amount <= priceByRange.max,
  ).price;
}

Now the pricing data is stored in config.js seperately and priceByRanges is resolved at load time.

Further optimization​

If the array priceByRanges is always sorted in terms of the price ranges, we can further optimize Solution 2 by leveraging binary search.

const priceByRanges = [
  { min: 1, max: 5, price: '5' },
  { min: 6, max: 10, price: '4' },
  { min: 11, max: 20, price: '3' },
  { min: 21, max: Number.MAX_SAFE_INTEGER, price: '2.5' },
];

function getPrice(amount) {
  if (amount < priceByRanges[0].min) {
    return 'unknown price';
  }

  let start = 0,
    end = priceByRanges.length - 1;

  while (start <= end) {
    const mid = (start + end) >>> 1;
    if (priceByRanges[mid].max < amount) {
      start = mid + 1;
    } else {
      end = mid - 1;
    }
  }

  return priceByRanges[start].price;
}

Notes on performance and Big O​

It might feel that the first clumsy solution with a bunch of if blocks is better in terms of the performance than the second table-driven approach that loops through the array.

Actually for the Big O analysis, both approaches have the same constant time complexity, as the number of operations (i.e. comparision between amount and the price range), doesn't grow no matter how big the input is (i.e. amount).

What's more interesting, in my opinion, is the performance implications between using a loop vs. "unrolling" the loop. By unrolling I mean discretely writing line-by-line of the loop body. A quick google search suggests that popular JavaScript engines such as V8 heavily optimize loops. But getting any accurate results from such a micro-benchmarking is really hard as the performance varies a lot depending on different factors like the engine and the code in the loop body.

Context​

As I mentioned in my post on coding interviews frameworks, 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 the 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 components's props or manage complex state in a React app.

A lot times having one type of system design interviews means you can over simplify 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 needs absolutely to be combated.
• power structure persists for a very long time and that's partially why most of VP Eng and CTOs out there are back end/infra developers.

Economic reasoning​

I had this realization that 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 let me 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 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 don'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

Disclaimer: Opinions are my own and do not represent the views of my employer (Meta)

Products​

Meta is a huge company and has teams working on all sorts of products. For big tech companies, common products include ads networks, chat, enterprise offerings, video watching, payments, hardware products, industry-leading AI tools, internal tools, etc. the other big tech companies Microsoft, Amazon, Apple and ByteDance have products in some of these areas as well. For many big companies, they are large enough that they build their our own infra and internal tools for most technologies they use because most existing technologies on the market can't meet their scale. Hence, not only will you get the chance to work on consumer products, you might also get to work on some of the lower level infrastructure work that is used by your fellow software engineers - our internal database systems, our internal Docker, our open source projects like React, React Native, GraphQL, Jest, PyTorch, Docusaurus, etc.

The impact is huge - every line of code you write has the potential to impact millions (sometimes even billions) of users due to the widespread nature of Meta's products. There was an intern who on their second day of work, changed the placeholder text of facebook.com's search bar by accident to "Hi I'm a Search Bar!" as part of a ramp up task and it was shipped to public for a brief moment before the change got reverted. With great power comes great responsibility!

Teams in Meta Singapore​

Let's talk about some of the teams in Meta Singapore since I currently work in Singapore and many of the readers are based in Singapore. Note that this section will go out of date as priorities shift. Last update: 2022/05/12.

In Meta SG we have two teams belonging to two organizations - Commerce Engineering and Ads & Business Platform. Both organizations, like most organizations in Meta, have global impact where the number of users is in the order of millions or more.

Commerce Engineering (hardware sales) is Meta's next up and coming revenue stream and is also the organization which I work in. Commerce Engineering primarily deals with bringing Meta's hardware products to market - from building immersive digital storefronts and highly optimized checkout flows to delivering great post-sales experiences to platforms that manage the demand, production, testing and shipping of Meta hardware products across the entire supply chain. If you have heard of the Quest headset device, which is Meta's flagship VR device, my team spent the entire of 2021 building the Meta Store website to sell them (https://store.facebook.com/quest/ and https://store.facebook.com/portal/). I led the organization's migration from our existing separate Meta Quest and Portal websites to the unified Meta Store website, by building the web infrastructure, the React components for the web version of the Meta Store Design System, and developed migration guides + new APIs to help teams quickly migrate their products onto the Meta Store website. In April 2022, Meta announced the Meta Store in Burlingame, California and the Meta Store website, which is one of the most visible products from the Singapore engineering office. It's definitely one of the highlights of my career to be building a product that contributed to Meta's 2nd highest revenue stream (and still growing)! We have even bigger plans for the Meta Store website. Stay tuned.

Some stories from engineers in Commerce Engineering:

• Help 10 People—or Billions? Engineering Impact on a Global Scale, Nishita A., Software Engineering Manager, Commerce Engineering
• Embracing Change to Evolve Her Engineering Journey, Michelle T., Software Engineer, Commerce Engineering

On the Ads and Business organization, there are these teams:

• Business Integrity: They work on building tools to catch bad advertisers (advertisers who create ads which violate our policies). They want to maximize Business Integrity outcomes by building a human review system for ads & commerce on Meta, driving end-to-end improvements in the workflows, and providing best-in-class tools to IP rights holders, etc.
  • Software Engineering in APAC: Building for Rapid Growth
  • Curiosity and Passion: Software Engineering at Facebook, Henry B., Software Engineer, Business Integrity
• Business Support Platform: They redefine the support experience across all Meta business products, making it available, effective and effortless for all businesses. They make sure businesses can identify the help resources available to them when they need assistance in accomplishing their goals across Meta's suite of business tools. Their tools will also effortlessly help marketers diagnose their issues and connect them to the best solution to solve their problem. They have also some investment into the machine learning space.
• Business Messaging Commerce: They build products that enable the Business Messaging ecosystem across Messenger, Instagram, and WhatsApp.

Enterprise Engineering has a sizable presence in Singapore as well:

• Enterprise Engineering in APAC: Building Products That Scale
• Opportunity and Trust: Growing an Engineering Career at Meta, Shuhong W., Enterprise Engineering Manager

Career progression/compensation​

Meta is one of the best companies for ambitious people who want to grow their careers quickly. At Meta, promotions come sooner and we encourage employees to be at their top form. At Meta, our terminal level (level at which there is no pressure to promote) is E5 and most people get from E3 to E4 within 1-1.5 years and from E4 to E5 within 2-2.5 years (this is a conservative estimate - I've seen top performers go from E3 to E5 in under 2 years). As an E5 in Meta SG your annual compensation will be at least 300k annually, which is on par, if not higher than most director-level roles in non-tech industries in SG. Imagine getting to that level of pay within 5 years of your career!

For comparison, Google, which is a similar company to Meta in many ways, has a slower promotion cycle - the average engineer at Google takes more than 2 years to get from L3 to L4, more than 3 years to get from L4 to L5 and more than 4 years to get from L5 to L6. At Google the terminal level is L4 so there's no pressure to promote. None of my peers are L6 at Google but a few are already E6 at Meta and it is quite achievable.

Faster promotions also lead to better pay, so in most cases, Meta pays more than most other companies. Meta is one of the top companies in terms of reputation and prestige especially for engineers.

Company prospects​

Meta is a tech giant and their products have over 3 billion active monthly users. The company relies on ads as their primary source of revenue. Whether you like it or not, Meta products are around to stay for the next couple of years. Even if they are going to die off, it won't be that soon. Stock growth has been relatively strong over the past few years (doubled since I joined in Nov 2017), especially since 2020.

Mark Zuckerberg is also betting on the Metaverse, which is obvious from the decision to change the company name from Facebook to Meta. Personally I'm undecided on whether the Metaverse is the future.

Culture​

There's so much to say about a company's culture, but hopefully you can infer some things about the company culture from the stuff I wrote above. Since I am an engineer, I will speak more about the engineering aspects of Meta's culture.

• Done is better than perfect - At Meta we have a quote "Done is better than perfect". Shipping something into the hands of users is more important than having perfect engineering. Teams get to decide how they want to build their products, whether to focus on getting MVPs out first and then iterating and improving the engineering later on, however they want.
• Bootcamp - Many engineers at Meta aren't assigned a team before they start at the company. They have to go through this program called Bootcamp, which is a crash course to teach them the useful tools and practices and also match them to their future team. Bootcampers work on Bootcamp tasks, which are small tasks created by various teams across Meta to get acquainted with the tech stack, development flow, and also the various products Meta has to offer. Few weeks into the Bootcamp program, bootcampers start chatting with managers of teams and can choose to work with teams which interest them. Bootcamp ends with the bootcamper decides on a team to join. Bootcamp is a great way for new employees to find teams which interest them the most and lowers the risk of them joining a team that aren't a good fit for them.
• Development efficiency - There are tens of thousands of Software Engineers at Meta, hence we have teams specializing in making the developer experience extremely efficient for us. The default IDE for us is a customized version of VS Code with a ton of useful internal plugins. Engineers can each get a remote server to do development on, which contains the latest code and development environment set up - we can start coding right away without having to figure out how to update dependencies and set up the necessary environment.
• Bottom-up culture - Engineers at Meta get a lot of say regarding the roadmap and wear multiple hats - project roadmapping, project management, data analysis, prototyping, etc on top of the core coding expectations. I'm personally heavily involved in the roadmapping process for my team as my team has a heavier focus on engineering - we build tools for the other product teams within Commerce Engineering to use.
• Hackathons - Hackathons have been an integral part of Meta's culture since it started and many successful products were born out of hackathons. Hackathons are a great way to encourage innovation and promote collaboration between engineers, designers, product managers, etc. In the past, the most successful hackathon projects get shipped - Like button, Facebook timeline, comments tagging. These days, due to the maturity and scale of the company, shipping hackathon projects to the public is rarer but our hackathon culture is still going strong. In a recent hackathon, me and two others built a Kudoboard replacement to solve a problem faced by managers where they had to resort to external services in order to sign group cards to send well wishes to coworkers (farewell/celebrating work anniversaries). We took a weekend to build an initial version of a tool we uncreatively call "Boards", spent the next week or so integrating with internal features like commenting, reactions, GIFs and announced about it in a company-wide group. The response was very encouraging - it has gained significant traction within the company - over 2000 boards and 20000 messages have been written since it was launched in Aug 2021! As a bonus, we'll be getting credit for it in our performance review :)
• Building cool internal tools - At Meta scale, it sometimes make sense for us to build our own internal tooling that has tight integration with our internal ecosystem as opposed to using an external service which might incur significant expenses and also pose security risks. We have teams building and maintaining our own tasks tool, code browsing and reviewing tool, a Q&A tool similar to Stack Overflow, a customized version of VS Code, an interview question bank, interview feedback tool, data visualization and querying tool, and a workflow automation tool similar to IFTTT/Zapier! Someone built a Pokedex app where you can catch a random Pokemon every time you close a task (I'm at 807/899 now!). I also have to mention that we have an internal meme maker which we can use to add customized internal memes to use in our comments in diff reviews and group posts
• Code wins arguments - It's not gender, race or your background that wins debates, it's the work that you produce. Instead of spending time arguing over technical decisions, it is more convincing to write some code to demonstrate the point.
• Beyond coding - We are also expected to contribute to the company beyond our coding, as in our perf evaluation we have a People axis, which measures how much you help and grow the people around you. People give talks, organize events, summits, do interviews, to score in this axis.
• Fun social groups - Workplace is Meta's enterprise offering, it's essentially Facebook for companies. We have various interest groups where we can find colleagues to play board games, share cat photos, memes when we want to procrastinate on writing performance reviews, interesting puns, investing tips, and more!

Mentorship and growth​

Mentorship is readily available at Meta all the way from interns to senior executives. One thing that stood out to me when I first joined Meta was the focus on mentorship. When I first joined the company and was in the Bootcamp program, I had a Bootcamp mentor. After joining a team, I was assigned a senior engineer as my mentor who was also my tech lead. Employees will have weekly 1:1s with their mentor and manager. For interns, each intern at Meta is assigned an intern manager, who will act as their mentor and is usually the person who came up with their internship project. The intern manager will be the main person evaluating the intern's work and they ultimately determine the intern's performance and if they receive a return offer at the end of their internship.

These days, as a tech lead myself, I have around 4 1:1s weekly with mentees and 2 with managers. I'm able to chat with my mentees and mentors about anything - it doesn't have to be about work. I often give my mentees feedback on how they are doing, advice and ideas on how they can be more successful, talk about the things I'm working on and why I made certain decisions.

There are also specialized mentorship programs for those who need it, technical mentorship, career growth mentorship, managerial role transition mentorship, etc.

Work-life balance​

At Meta, you get to choose how fast you want to accelerate your career. Some people choose to take up more responsibilities, work more and ship more impact, usually resulting in faster professional growth, higher ratings and pay, while others work at their own comfortable pace; it's really up to the individual. The top performer on my team now is nearly getting to E5 with just around 2 years of working experience. They don't work beyond working hours, they're doing well because they're working smart and working on the most impactful and challenging problems.

Every Meta employee has 21 days of leave/paid time off every year and this year the company gave everyone three company-wide paid holidays on Friday in the summer and also two Meta choice days - effectively more paid time off but they cannot be accrued.

Transfers and mobility​

It is extremely easy to move around in Meta because Meta understands that mobility is important to the happiness and welfare of employees. People move around quite often and people are eligible to consider team changes from their second year at the company onwards. Meta is a large company comprising of many organizations and each organization has their own unique culture. It can be refreshing to move to another part of the company, working on different domains, different products, experiencing a slightly different engineering culture, yet still be productive because you are using the same engineering tools as before. When engineers move around the company, positive things can happen - they bring the good practices from their previous organizations to the new organizations, networks are strengthened and new connections are formed. Because Meta has offices around the globe, it is also possible to transfer to different countries as long as there are no work authorization issues. Personally I relocated back to Meta Singapore office after working for 2 years in Meta Menlo Park and my manager has worked in 4 different offices (Menlo Park, London, New York, Singapore) throughout her 9 years at Meta!

For engineers, there are also temporary transfers which we call Hackamonths. Hackamonths are month-long projects proposed by teams where they welcome someone outside their team to work on. At the end of the hackamonth, the participating engineer could return back to their original team or stay on the new team. This provides engineers with the opportunity to try out work and the culture of their new teams before committing to a permanent move.

What I dislike about Meta​

• Imposter syndrome - The company is full of the smartest people in the world. There are many days I feel that the people around me are smarter than me and that I might not belong here.
• Launch processes - With the company undergoing tons of scrutiny these days, we have to be even more careful around how we use our users' data and what we are tracking. Every public launch now has to undergo a review process with legal and security.
• Cross-timezone collaboration - My team frequently works with product managers, designers and other roles who are based in California. Meetings with these folks tend to be in the morning (their evening) and it can be hard to get up in the morning sometimes...
• Fewer low hanging fruits - In a mature company especially if you are working on mature products, sometimes the low hanging fruits have been snapped up and you mostly are left with really tough problems to solve. On the bright side, Meta engineers should be smart and should be able to live up to those challenges.
• Legacy code - Unless you're working on a new product, you inevitably will have to be deal with code others have written. The older the product you work on, the more legacy code you have to deal with and the code quality varies.

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 if their focus is 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 question 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!

Here's the initial version of Teik Jun's resume I received from him.

On first glance, it looks like a solid resume, and it is. However, I've known Teik Jun for a few years now since the Major League Hacking (MLH) Fellowship program where he contributed a ton of features to Docusaurus v2, and know that he has done even greater things in the past. This version of his resume doesn't do his skills justice. Let's see how we can improve it by applying the points learnt in the previous section.

Resume critique​

Good​

• Demonstrates diverse and full stack experience - Has experience in front end, building web applications, JavaScript tooling, payments infrastructure and blockchain
• Diverse interests and abilities - Open Source, AI and Machine Learning, Front End, Algorithms TA, Hackathons
• Clean formatting which is easily readable
• Reverse chronological order
• Straightforward, bullet point format

Points of improvement​

• Irrelevant experience - It's honestly super cool to be "Best Shot" of Sniper Course and to get other impressive accolades as an NSF, but it's hardly relevant to a SWE job. If I were running out of space I'd remove it.
• Not sufficiently conveying the impressiveness of his experience - Teik Jun's work on the MLH program was for a popular Facebook Open Source project, Docusaurus (the same project that powers this website) and he did very very good work as part of the program. I know because I reviewed his Pull Requests and he did a damn good job. Docusaurus is an important project to Facebook and widely used by popular Facebook projects like React Native, Jest, and Relay.
• Not explaining what the project is about - In most cases, recruiters are the ones reading a resume and they would not know what a project is about, especially when most of them aren't technical. Hence resumes also have to explain the complexity and impact of a project. I know what Docusaurus and TEAMMATES are, but that's because I worked on Docusaurus and I am aware of NUS' projects. Most recruiters would not, so we have to explain what they are. TEAMMATES was also a Google Summer of Code project, so mentioning that would be nice.
• Trivial details - Under TEAMMATES, there was a point "Added a progress indicator component for expensive operations". This sounds quite small and can be removed if there's a lack of space.
• Obscure projects - The "Mentorship Management Web Application" doesn't sufficiently relay the complexity. The details are also obvious and doesn't sound impressive. I'd remove this project because it doesn't add much value.
• Contributions to Open Source projects - Any project can be made open source and contributing to your own open source homework doesn't mean much. What makes open source contributions impressive would be the complexity of the project and the contributions made. The latter might be hard to fit into a resume, so we should do the former at the very least.

Bonus​

I know that Teik Jun will be interning with ByteDance in the fall, so it could be added as a signal of Teik Jun's abilities, telling recruiters that he's good enough to work at ByteDance.

Improved version​

Here's an improved version of Teik Jun's resume which I feel which better highlights Teik Jun's abilities. Main changes made were:

• Added more important keywords - ByteDance (future internship), Facebook (MLH collaboration), Google (TEAMMATES was a Google Summer of Code project for a few years).
• Removed redundant and unimportant details.
• Added links to certain projects to make it more convenient for recruiters who want to gain more context of the projects listed.

In my opinion, this improved resume is sure to capture the eyes of any recruiter in the world!

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 an 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 end he/she is currently working at? In particular, what do you think about an Front End engineer that knows BE (i.e. a full-stack developer), or an Front End engineer that 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 am not a recruiter and I might have answered some of the recruiting or internship-related questions wrongly, so take them with a grain of salt. Opinions expressed are my own and do not represent the views of my employer.

Glossary​

• APAC - Asia Pacific Region
• CVWO - Computing for Voluntary Welfare Organizations
• DSA - Data Structures and Algorithms
• EE - Enterprise Engineer/ing
• FRL - Facebook Reality Labs
• FTE - Full-time Employee
• IANACP - I am not a career portal
• IANAR - I am not a recruiter
• IANAL - I am not a lawyer
• IINW - If I'm not wrong
• RA - Residential Assistant
• SWE - Software Engineer/ing
• TPM - Technical Program Manager

Caveats​

• These replies are tailored towards the Facebook interview process for interns and fresh grads. They may or may not apply to other companies, especially smaller ones.
• Most of these answers apply across the board for every engineer role but there are exceptions for certain specialized engineering roles like Security Engineering or Front End Engineering.

Application/Referral​

What's the application process like (for internships)?​

Apply on https://www.facebook.com/careers. Recruiters will reach out to you if there's interest and chat with you over the phone. If it goes well, there will be two rounds of coding interviews.

What are some qualities/experiences that Facebook looks for in a resume?​

IANAR and I don't filter any resumes, so I don't exactly know. But from experience, write stuff that makes you stand out from the rest. Have good grades? Add it in. Scholarships/awards, write them down. Have extensive internship experience? Include them in an organized format. Built cool hacks/side projects? Add the GitHub links and demos. Won hackathons/competitions? Put them in. One thing is for sure - few companies would want to hire candidates who only have academic credentials and no industry experience.

Does GPA affect a lot on the resume screening?​

GPA/CAP/grades is just one of the signals that can be extracted from the resume. As mentioned above, there are many other qualities and achievements a candidate can possess. Personally if I had my own company, I would rather hire a candidate with a high second upper and fantastic open source portfolio with multiple internship experiences at big companies over a student with CAP 5.00 but has nothing else to show for. Not that one candidate is stronger than the other, but the former would probably be a safer choice.

In general, how's the barrier of entry for big tech companies like FB in terms of grades, would a second lower (3.5-3.9) even get pass the resume screening stage?​

Grades matter less the longer someone has left school. For students, because there's a lack of working experience, grades might play a larger part in the resume screening, but it's by no means the only thing that matters.

Is the resume screening done by AI / human recruiter? What is being looked out for on the resume? As someone who isn't strong academically, will I be able to compete purely based on experience on my resume?​

IANAR. Usually people suck at their studies because instead of studying they spent their time elsewhere. If it was spent on related stuff like hacking on side projects and internships, that probably makes up for the subpar academic grades. But if you suck at studies and spent your time clubbing instead, then I'm sorry you probably won't get past the screening. Note that CS is such a hot course now that only the best students can get in these days. A fair amount of students have both good grades AND non-academic achievements. Competition is tough!

Are there any languages/frameworks that are helpful to know before applying?​

For Software Engineering (SWE) positions, Facebook doesn't require you to have experience in specific languages/frameworks before joining. Likewise, there aren't any of such restrictions for SWE interviews. You can do your interviews in your programming language of choice. One exception to this is if you're applying for a Front End Engineer or Mobile Engineer position, then you will be asked domain-specific questions and by extension, required to use JavaScript/Java/Kotlin/Objective-C/Swift to answer the questions.

Are intern applications (and hence, the spots) based on first-come-first-served?​

IANAR. But as with all jobs, there are definitely limited spots and once they're filled up there isn't a need to hire anymore. Applying in 2022 for the internship which application opens in September, is almost definitely too late. You can apply later (October) if you want more time to prepare, but there might be fewer slots left. Moral of the story - prepare early.

How's the referral process about/like?​

Facebook will send you a form (initiated by me) where you can fill up your name, email, upload your resume, and select the roles you would like to apply. From there on, from an applicant perspective it's not different from them applying themselves on the Facebook Careers Portal.

May I know until when your referral is valid? I was hoping to start my application a bit later so was hoping to reach out to you then for a referral. Is there any last date to "claim" this in any way?​

As long as I remain employed at Facebook, I'm happy to refer you if I feel that you stand a good chance passing the interviews. As mentioned earlier, if you apply when unprepared, you risk wasting the chance. Take too long and apply too late, then you risk the slots being all filled up. I don't know the last date to be referred but I recommend not later than end of September.

Any tips for a good resume to apply for FB?​

Answered above. I don't think most students need to worry about the resume screening stage. Worry about the interviews. Use a neat and standard template and you should be fine.

If you're applying for US positions, it'd be helpful to do the following:

• Mention expected year of graduation (month as well if you know)
• If you're applying to US roles, mention US work eligibility. This is straightforward for Singaporeans (mention eligibility for H-1B1 visa)
• Use GPA instead of CAP

If I build my projects must some of them be pushed to production before applying?​

Best if you can, but I'm not sure if recruiters actually click on your project links. Maybe just don't include the link if it's not really usable?

Do you have any tips in applying for a fresh grad SWE role in facebook?​

Make sure you know your algorithms at the back of your hand. Fresh grad SWE role interviews also have a behavioral round, so be prepared to talk about your past experiences. There's a section in this handbook which covers those.

Apart from preparing for DSA questions, are there other areas you would recommend preparing for (either for the interviews / a better chance to get shortlisted for them)?​

If you're going for a SWE intern/grad position, DSA is the most important. The bulk of the assessment is on DSA. Grind your LeetCode.

Would love to find out what the interviewers at Facebook usually look out for in candidates!​

DSA. DSA. DSA. Communication skills - You must be able to also communicate your thought process well throughout the interview.

Am I able to apply for both local and overseas (in the USA) roles for FB and be considered for both? Or would I only be considered for SG's openings since FB has an office here and I'm already located in SG?​

IANAR. Typically you will only be interviewed for one location. Candidates based in Singapore are free to apply to non-Singapore positions and intern there.

What is the application process like for the Software Engineer role? Is it any different from the Enterprise and Front End Engineer role?​

For SWE, I've answered above. I'm not sure about Enterprise Engineers, I suspect it wouldn't be too different. For Front End Engineers, the questions will be domain-specific, hence will require candidates to be familiar with HTML/CSS/JS/Vanilla JS DOM manipulation methods, and less emphasis on Data Structures and Algorithms. I would expect most students to not have enough domain expertise to pass a Front End Interview, so don't anyhow apply for it. Simple litmus test - can you build a TODO list app in pure vanilla JavaScript, without using React/jQuery?

Note that Facebook Singapore currently does not hire Front End Engineers and interns. If you're interested in a Front End Engineer internship/FTE position, you'd have to look overseas.

Is there anything I can do/prepare to improve my chances of getting through the recruiter screen?​

1. Get a referral
2. Have a solid neat resume that showcases your abilities

How much does a referral help in landing a interview?​

Referrals tend to have a higher visibility than someone who applies on the Careers Portal directly, but that's about it.

Are there any related full time openings at FB, and if so how can I help you decide if I'm a good candidate to refer?​

I look through your transcript and resume and look for stuff that suggests you'd make a good employee. What things I look out for - excellent grades in the relevant modules, notable internships, interesting side projects, ICPC/IOI awards. Bonus: Open Source experience. I'm a huge fan of Open Source and if you have built something really cool that's Open Source, I'd refer you even if your grades are terrible.

Do I stand a good chance if I'm from a Info Systems background but gotten good grades for programming modules? Currently taking some CS modules now too.​

There are many IS folks who are good engineers. As long as you can demonstrate that you have mastery of programming and DSA, it shouldn't be an issue.

Would you know whether Facebook's hiring process has a preference for single-page resumes?​

As an interviewer for FB senior-ish candidates, I have seen some horrendously long resumes. So I would think single-page is not a hard rule, more of a recommendation. If you are exceeding a single page, then you are likely including too many things. My own resume is a 2-column one with small-ish font which I used in my last job hunt in 2017. It has got me replies from recruiters. This was before I started working at Facebook, so the Facebook branding isn't the main reason.

I'm an international student at SMU, does Facebook sponsor employment pass?​

IANAL. But we have had international students interning at Facebook before and are currently working at Facebook. Please check with the recruiter.

I'm from SUTD and my schedule is pretty weird! I'm graduating next year so should I apply for internship or a job?​

If you have any spare summers left, you can and should go for an internship. IMO passing an internship interview is easier than a full-time interview, and likely leads to a better conversion package also if you have performed well during the internship.

Am I eligible to work overseas in US/London/Canada?​

IANAR. If you're Singaporean, you'd have no problems working anywhere. If you're a foreign student, you could check with your seniors or just ask the recruiter when you get the chance.

I want to intern in SG and work in US. Is that possible?​

For interns, your return offer will be for the location you interned in. So you should also factor in where you want to work full-time and strive to intern at the same location.

How long do I have to wait if I get rejected?​

There's a 6-month to 1-year cooldown period for each role - E.g. if you've interviewed for SWE in the US and failed, you'd have to wait some amount of time before interviewing for the SWE position again in SG (or any location). This cooldown is per role, so you're free to apply again immediately and interview for another role, e.g Front End Engineer, assuming your resume gets picked up.

As of writing, internships in FB SG are run annually so if you fail this year you'd have to wait for the next.

Interviews​

What's the interview process like?​

For all roles, there should be an initial contact (e.g. phone call) with recruiters. For interns, it would be 2 rounds of online coding interviews where the focus is on DSA. For fresh graduates, it would be 2 rounds of online coding interviews and 1 behavioral round.

Based on your past experience, if a candidate does not get full marks for the online coding test, what are the chances of him or her getting a face to face interview? Just curious about the level of competition haha (This is because I'm not that worried about whiteboard interviews but afraid that I may not even get a chance to go through it)​

I don't even think there's an online coding test for Facebook. Can't answer this.

Would FB US hire SG citizens considering that there's an FB SG office already?​

Yes.

How I could improve my chances on landing an internship?​

Study your DSA, grind LeetCode, do mock interviews with your peers to get used to talking out loud/communicating your thoughts while coding.

I wanna learn as much as possible from you about topics that might benefit me​

Benefit you in terms of what, and when? For passing the interviews, DSA and LeetCode. For the actual internship, that'll be a much longer answer which I shan't go into because that's a problem for later, if you pass the interviews.

I heard FB doesn't ask dynamic programming questions, correct me if I'm wrong. Are there any topics I should be focusing more on?​

I can neither confirm nor deny this. General tip for coding interviews - focus on the most common data structures and algorithms. If a particular topic is really obscure, most likely you won't be asked on it because asking obscure stuff sometimes work against the interviewers as it'd be harder for them to extract the right signals out of it. Look at the recommended practice questions in the handbook.

How many rounds of interviews are there? Does FB ask system design on the live interviews?​

For internships, typically two coding. For fresh grads, typically two coding with one behavioral. No system design for internships and fresh grad interviews.

Would I be tested on specific tech stacks/real project experience, or is it purely algo based?​

If you're applying for a SWE position, you won't be tested on a specific tech stacks/languages. The algorithm questions asked can be implemented in most programming languages (but you probably want to avoid using wenyan). If you're applying for a specialized position, then you might be asked to use domain-specific languages, which the recruiter should (will?) let you know ahead of time.

Internship​

What are 3 qualities of a intern/new hire fellow FB engineers look out for?​

This is a long answer and there are more than 3 qualities. But to get a conversion offer, in summary, interns have to show productivity and complete their assigned projects within the internship duration, product high quality code/work, demonstrate fast learning speed, actively communicate and collaborate, and show initiative and independence. Pretty much common sense if you ask me.

What are the different types of internship roles that are opening in FB (both here in SG and overseas)!​

IANACP. FB SG is quite limited in the sense we primarily only hiring SWE, EE interns. But I think I have seen TPM interns before. For overseas, almost every role is available.

Are there machine learning/data science internship roles at Facebook SG? How about in other countries?​

Not that I know of. Yes there should be for overseas, but then you'll be competing with a global pool of candidates.

What does the SWE role entail? Tech stack and what to expect?​

Software engineering of course. To answer seriously, it really depends on the team and their work. Most (all?) SWEs write code to solve problems. FB is big enough such that there are teams using almost every language out there.

Here's an oversimplified overview:

• Web Products - JavaScript/React/CSS/GraphQL/Relay/Hack (typed version of PHP)
• Mobile - Objective-C/Java/React Native/Proprietary frameworks
• Back End Services - Java/C++/Python

What is the internship format in Facebook like? For example, are the interns inserted into a team to work on issues or are they handed a project to work on throughout their internship?​

Under normal circumstances, interns would be given one project that should take them the entire internship duration (10 weeks or so out of a 12-week internship) to complete. They will be assigned an Intern Manager that would serve as their mentor throughout the internship. The mentor is typically the one who came up with the project which is broken down into multiple milestones. Responsibilities of an intern manager include: onboarding the intern, giving the intern regular feedback on how they are doing, reviewing their code (typically together with other members of the team), evaluating whether the intern will get a return offer.

How's the mentorship like for FB interns? Do a mentor work together with intern on the same project? Are mentors randomly assigned within the company or do they volunteer for it?​

Intern managers may or may not work with the intern on the same project, but they definitely should have context over the intern's project and be able to review (or at the very least, find suitable people) the intern's work. Employees can sign up to be an intern manager for a specific internship season. It is not random. It would be a disastrous and unpleasant experience for both the intern and the intern manager if an employee got randomly assigned to be a manager.

What are some products that interns will get to work on in Facebook Singapore?​

Intern projects are typically self-contained and achievable within the internship duration. Some example of intern projects in FB SG - rebuilding Oculus Accounts Portal (https://secure.oculus.com) using a modern React design system, building a self-serve order return flow into Oculus Accounts Portal. Outside of FB SG - Building the settings page of facebook.com, building an internal debugging tool (something like Redux Devtools).

What kind of projects are interns usually given (like internal tooling or external products)​

Answered above. Can be both, depends on the team. In Singapore, we primarily have product teams, so the projects are likely about adding product features.

Will there be any chances of being transferred to an overseas office after being accepted as an intern?​

Yes I know of that happening to some ex-interns. However, that could be due to special COVID circumstances which might not necessarily apply in following years. You'd have to check with the recruiter.

How many interns is FB looking to onboard next summer? Not sure if this can revealed but thought I'll ask nonetheless​

Don't know and even if I knew, I can't say. We had 4 interns in 2019 and around 10 interns in 2020. FB Singapore office is growing quite rapidly.

I'm actually more interested in mobile dev, are there open internship roles for this in the SG office?​

There are some teams in FB SG which work on mobile. Prior to starting internship at FB, interns will get to indicate their preference of tech stack and they will be matched to teams/projects which match their preferences.

Do you get to try out different parts of engineering as an intern / junior swe in facebook? e.g. if I were doing back end but I would like to try front end later down the road​

Short answer: for interns, not so much. For FTEs, much more autonomy.

Longer answer: Interns are assigned a project which usually have a pre-defined tech stack. So the engineering work and stack that an intern will be doing is highly dependent on the assigned team and project. If the intern finishes the work early, it's possible to ask for more work from their manager and possibly try out other things. If the internship duration coincides with one of the internal hackathons, interns can participate in them and work on anything they want. For SWEs, there's a process called bootcamp after joining where employees find their own team to join. That gives them more flexibility in deciding what kind of work they want to do. Internal mobility is very good within FB as well. Personally I've done both front end and back end at Facebook.

FB Culture​

What's the difference between Software Engineer (SWE), Enterprise Engineer (EE), and Front End Engineer? This is because I heard from previous FB interns that they worked on the full stack.​

• SWE - Generalists, they are expected to be able to work on software-related problem given to them and should be able to work across the stack.
• EE - Taken from Facebook's Career Portal: "Facebook's Enterprise Products team is responsible for building integrated, scalable, and robust Enterprise Applications. As a member of Enterprise Products team, you will play a key role in re-imagining productivity by shipping transformative products that serve diverse aspects of the enterprise"
• Front End Engineers - SWE with front end specialization. The interview is in HTML/CSS/JavaScript and there's more focus on domain-specific questions. That doesn't mean Front End Engineers can only work on front end stuff, they can work on anything as long as it is what their team needs and they have alignment with their manager. In my experience, Front End Engineers at FB are highly skilled in front end but can do back end work too. Btw I'm a Front End Engineer 😉

What are the opportunities that are currently available for the FB SG office? And perhaps what kind of people do you typically look for? (e.g., in terms of technical skills or perhaps other metrics)​

There are two main orgs in FB SG - Commerce Engineering and Ads & Business Products. The Commerce Engineering teams in Singapore build e-commerce websites to sell Facebook's hardware devices (Quest, Portal) and also sees through the rest of the lifecycle of a purchase - support center, returns, warranties. I'm in the Commerce Engineering org and my team manages https://www.oculus.com and https://portal.facebook.com. I don't know too much about the Ads side of things.

Read an article about my manager, Nishita Agarwal, which mentions empathy as a key trait.

There's also an article about Software Engineering in APAC on the Facebook Careers blog.

How is Facebook Singapore different from that at Hacker Way in San Francisco?​

First and foremost, check out the following (old but still relevant) article.

Nit - Hacker Way is not in San Francisco, it is in Menlo Park. Perhaps you meant SF Bay Area. Anyway, FB SG and FB US differ is quite a lot of ways. There are too many to list but I'll list the most obvious ones.

• Career Progression - FB US, being the HQ and where the company started, has the most number of teams and you have all levels of seniority of folks there. In FB SG, there are fewer teams and due to the size of the office now, there isn't a need for extremely senior engineers yet. So if you're talking about long term career progression, SG definitely loses out here. But don't need to think so far la, FB SG is still big enough for you to get to senior engineer position and earn enough to live comfortably for the rest of your life.
• Projects - Primarily product teams and hires primarily SWEs and EEs, while FB US has a good mix of teams, including infrastructure teams and hires across all roles. So if you're interested in working on infra stuff like our internal logging framework, GraphQL, our internal ORM, you'd have to look at non-SG offices.
• Changing Teams - SG has fewer teams, so if you were looking to change teams but remain in Singapore, the choices are more limited.
• Company Culture - You don't get to attend the events held only at the HQ in-person, such as Zuck's Q&A or company town halls or the summer and holiday parties (but there are local versions of them).
• Food - Smaller selection of cafes in SG. The food is still pretty darn good though. There's nothing to complain about free food.
• Office - Smaller office in SG, but still one of the coolest in SG. Menlo Park Headquarters is amazing, there's an arcade, board games room, a barber, ice cream shop, a gadgets vending machine, and more. It looks like Universal Studios at night. I'll just leave this video here.
• $$$ - FB pay is top tier in both US and SG. However in SG, you have to pay less tax and cheaper living expenses. In SG, I earn less but save more due to the large difference in taxes.
• Taxes - SG tax is crazy low compared to US. US taxes you on every damn thing, including the capital gains from your stocks and bank interest earned (WTF), but SG doesn't.
• Engineering Culture - Similar-ish because quite a number of engineers in FB SG moved here from FB US, including myself. But being a smaller office, we don't have as many extremely senior engineers.
• Social Security - I thought Bay Area was relatively safer than the smaller US states, but these days driving on the highway also can get shot, so I don't know anymore. I think SG is definitely safer, at least you definitely won't receive any racist remarks or comments while walking on the streets.
• Personal Happiness - Obviously you'd have fewer friends and family if you're in the US. If that's important to you then life there might be hard. But you can make new angmoh friends or hang out with the steadily growing SG community over there.
• Dating Scene - If you're single, it might be hard to find a long-term partner there. The female Singaporean engineers there are mostly taken, those that are not, probably want to stay single. Dating there will be quite hard! I know of friends who got together with Americans/immigrants and then they get a green card and plan to stay there for good. You can consider that too.

I would describe myself as a small fish in a big pond when I was in FB US and am now a big fish in a smaller pond in FB SG. I enjoy my current work and team in FB SG and I see myself being in this role for a few more years at least.

Are Facebook internal hackathons only within branches? Eg. only within FB Singapore?​

They are kinda global in the sense that the timelines are global but each region has different people leading it for the regional offices. Participating teams will take part in the regional selection and winners of the regional ones come together to present to the global heads.

What is the difference between Software Engineer and Front end Engineer at Facebook, and considering that my experience lies mostly in Front End Engineering, should I only be applying to the FE role?​

Differences answered above. If you're solid in your Front End web fundamentals (HTML/CSS/JS), and suck horribly with DSA, I think you might stand a better chance going through the Front End interview loop. Unfortunately as of writing FB SG doesn't hire Front End Engineers so you'd have to look overseas for such a role.

In the past one year, I have been hearing quite a lot of things about FB Reality Labs, and I heard that quite a significant portion of FB engineers are working on it now (and I think you are as well?)... do you have any thoughts about how it feels to work there and perhaps the future prospects?​

I work on selling FRL hardware, not directly on FRL hardware/software itself. If you haven't heard of the metaverse, you should read up about it. I don't have too many opinions on the future of FRL but I can say that Quest 2 is the market leader in terms of VR headsets and Quest 2 was a major driver behind FB's $885 million 2020 Q4 non-ad revenue.

What engineers is Facebook looking for - especially for New Grads? At the moment, I have knowledge on a breadth of tools but when asked on under the hood stuff, I can only explain what the tool / framework is trying to extract instead of going in depth as to how stuff actually works. Is the firm looking for new grad engineers who are language / tool / framework agnostic and can work towards building the skillset within the firm - or people who already have a speciality?​

FB uses Flow (for JavaScript typechecking) and Hack (typed version of PHP) which most people outside of FB won't use. If we were to hire only people who have prior experience with them, then we'd have a really hard time filling our head count.

When tech companies hire SWEs, usually it's for a generalist position and they would expect the employees to pick up any new language or tool to get the job down. If you master your fundamentals, doing that shouldn't be too hard. So really most companies would want to hire people who can learn fast and adapt. The exception is if you're a super senior person (think principal level and above), then you'd be hired for your specialized skillsets probably because the company needs some subject-matter expert in that area. But most of you are still undergrads, that doesn't apply to you.

At the end of the day, many language and tools are similar-ish. New technologies learn from existing technologies and improve on them, learning new technologies isn't always that foreign.

However, to be a good SWE, I would recommend peeking beneath the abstraction layers and understanding what problem this technology is trying to solve, how it works under the hood, and what advantages/disadvantages it has compared to similar technologies. That's why I love Open Source, all the code is public - you can read the code, look at how the projects are structured, and even contribute to them. I also love reading articles comparing technologies so that I know what tradeoffs the projects are making and what's the right tool for the job. Don't be a mindless drone who uses technologies without knowing why you are using it instead of alternatives. That'll be an easy way to get phased out really soon, especially considering how fast technologies move.

In my conversations with most engineers from US tech companies, I often hear that one of the major shortcomings of working in the Singapore offices is that they are more auxiliary in their functions, and that opportunities for "core" engineering work are few and far between. Since you have worked in both the Menlo Park and SG offices, I'd love to hear your response to this within the context of Facebook.​

Answered above in the US vs SG comparison.

Personal Experience​

Can I know about the project you're involved with in FB?​

I'm currently working on a multi-year project which I can't reveal the details until we launch next year. Last year, I worked on Facebook's e-commerce websites - https://www.oculus.com and https://portal.facebook.com. I built design systems in React and a CMS framework to allow non-engineers to change the marketing content on oculus.com anytime they wish. One of the problems my team works on solving is to decouple marketing launches from engineering work, enabling the business teams to launch new products and campaigns on our e-commerce websites.

Why did you choose front end engineering, and separately, how do you think the workload at Facebook compares to that of other "top" companies such as Google?​

As a student I also liked to do design, so it was very cool for me to be able to implement my own designs on the web. That's why I chose to do client side engineering. As to why the web, I like the fast iteration and release cycle of building on web platforms. My first hardcore CS course was actually CS3217 (I only took CS1010E and CS1020E prior to that), so the first proper software I wrote was on iOS platform. Developing on mobile is too troublesome for my liking, because I often need a physical device, compiling the app takes so long, and you have to play by the platform's rules. They could take down your app anytime they want. On the other hand, the web is much more open and anyone can launch any website they want in a matter of hours. Being able to show people what I built by giving them a URL is an exciting experience that never gets old.

I haven't worked at Google so I can't comment on workload at Google. But Google is known as a good company to "rest and vest" whereas Facebook has faster promo cycles and rewards their top performing employees disproportionately.

Am I correct to interpret that you started at Grab after graduation? What internships did you do during your studies?​

Yes I worked at Grab for two years after graduation, you can check out my LinkedIn. Regarding university internships, Year 2 I did CVWO, Year 3 NOC in Silicon Valley for EasilyDo (now called Edison), Year 4 I was a Game Producer (non-programmer!) in SUTD Game Lab (previously MIT Gambit program). Back during my time, overseas internships weren't common. The number of Google and FB interns each year was fewer than 10.

I'm also curious about what you do in your role as a Front End engineer, and why you decided to work at Facebook?​

As a Front End Engineer at Facebook, I primarily write JavaScript and some Hack (PHP with types). Being at Facebook is fun because I get to do front end work which isn't product, such as building React-based design systems, front end tooling, lint rules, CSS frameworks (Infima), Static site generators (Docusaurus).

Facebook is the leader in terms of front end web technologies. If you develop on the web, you would more likely than not, be using some of Facebook's open source work, whether directly or not. There's React, Flux, Jest, GraphQL, React Native, Docusaurus, Draft.js, Relay, Flow, just to name a few. By working at Facebook, I also got the chance to work on Docusaurus and for two years, led the development of Docusaurus v2, which is one of the projects I am most proud of in my career. Today, Docusaurus is powering most of Facebook's open source websites. Many of the open source leaders I look up to were also at Facebook. I got to contribute to many high profile open source front end projects by Facebook and also work alongside the creator of React (Jordan Walke) on improving the front end of Facebook's Ads Interfaces. Not to mention that Facebook employees will be the first to dogfood React's new APIs and participate in design discussions and influence the future roadmap of React.

On the culture and working environment front, I have always vibed with Facebook's hacker culture and products more than Google's, so naturally I chose Facebook over Google even though their offers were comparable and I was given a chance to work on Google's search results page.

Facebook is the best place for a Front End Engineer to grow and learn from the very best. So it was the most obvious choice for me and I'm glad I made that decision. It's the best place I've worked at thus far (almost 4 years!) and also financially a great choice.

Could I ask about your personal experiences at FB in terms of learning opportunities and the work you do? :)​

The learning opportunities depend on many factors - individual preferences, team, projects, luck. Facebook is such a large company that covers virtually almost every domain of technology one can be interested in. With great internal mobility, it isn't hard to find a project that one will be passionate about. The benefits (and also downsides) of working at such a large company is that you often have to think about scalability in your work. How do you scale your work to the tens of thousands of engineers using your libraries or the billions of users using your product?

Facebook is also a company which takes the growth of employees very seriously. We have clear levels and expectations for engineers, supportive managers who really care about the growth of their team, mentorship programs available for anyone who wants to grow in a particular area. One of a manager's core responsibilities is to grow their team and employees, and they are being evaluated on that, so you can be sure that they treat it seriously. We have weekly 1:1s with managers and with our leads. Personally I'm mentoring around 3-4 junior engineers and helping them to grow into senior engineers in both their technical and organizational skills.

I've answered about my work above.

What made you and the team came up with the idea of NUSMods and NUSWhispers? I think its really great to code for good and fulfilling stuff rather than coding for corporate means​

I didn't come up with NUSMods. Beng did. I helped to build features (my favorite being theming and dark mode), recruit members into the team, and also started the v3 rewrite which is the one you are using now. Most of the credit would go to Yi Jiang, Li Kai and E-Liang for the current version. NUSMods code base isn't exactly that big, but it took us over a year of work to rewrite it on a modern stack.

Shout-out to Christopher Goh for taking the helm now! Joining NUSMods was one of the best decisions in my life, as impacted the lives of so many students (I daresay above 100k), learnt so much from working on it (it's a relatively complex web application), and it helped me grow my network of like-minded individuals. We need more people to contribute so that the project can live on. Notice that the NUSMods core team (and alumni) have pretty zai backgrounds? Correlation or causation? Maybe both.

I came up with the idea for NUSWhispers but I didn't write much code for it. I was tutor for a web development course (CP3101B) back in 2015 and I proposed that idea to some students. I'm glad they did a darn good job of it. Back then I wanted to create a platform that could connect and help students around the school and the idea of an anonymous platform/page sounded like fun.

I like building stuff that people use, and after graduation I try to open source my stuff. This website you're reading now is also one of my largest open source work (in terms of popularity).

I understand that you've been in FB for a couple of years, and worked in tech companies like Grab as well, given your prev/current experiences + what you've heard from fellow colleagues and peers, in your opinion what makes FB different from the other tech companies in terms of work done and how an entry engineer could expect to contribute?​

I have only worked at two companies, so I wouldn't say I have seen a lot. But a few things stand out to me about FB as compared to other smaller companies:

• Top of the market compensation. It's really crazy a lot. Maybe not as much as quant trading firms, but if you also factor in other stuff like interesting work, social impact, then to me FB still comes up on top.
• Bottom-up culture. In some companies, engineers are treated like mindless drones and expected to just execute. But not at FB. At FB, engineers are expected to do a fair bit of product and project management, propose ideas and lead the roadmap for their team, especially if their team's product is a highly technical one. We have lots of flexibility and autonomy to manage our own work and what we want to do with our time. As someone who has many ideas and likes to build them, it suits me well.
• Lots of responsibilities given. FB trusts you to do the right thing. You could technically bring down facebook.com on your first day of work if you were careless (or evil).

How do you run your team? This question is relating to the culture you foster within your own team.​

We have very few processes. My team is excellent so I trust them to do the right things and they don't disappoint. In my current multi-year project, I broke it down into smaller parts and pieces and assigned them to my teammates according to their interests and expertise. I set the guidelines and some general engineering principles, make sure my team is aware of them and we stick to them when developing. We set goals for the half and then we're pretty much running the project each on our own. On a day-to-day basis, I spent about half my time writing code and the other half reviewing code and attending meetings. I'm also mentoring a few engineers and I guide the newer engineers more and provide them with constant feedback on technical work and behavioral changes that could help them to grow.

How has Facebook impacted your career in terms of learning and growth and since you probably have many FANG companies to choose from, what is Facebook unique selling point to you personally?​

By working at Facebook, I got to see how large engineering teams operate at scale, how products are developed and launched to millions of users, and learn from the very best engineers in the world.

Front end and open source. I answered in more detail above.

Are most of the projects at Facebook internal tools for the company or more for the public/users? Or does this depend on the team you work at?​

There's a good mix. Yes it depends on location as well. Most infra teams and in the bigger engineering offices (US, London). Singapore is still new and growing rapidly.

Career​

I'd like to seek your advice on what I should be prioritizing in my next two years of school in order to gain relevant skills/experience to stand out to FB recruiters when I graduate.​

Work on being a good engineer who has mastery of the fundamentals. Good grades, impressive internship experiences, side projects, etc are important but only for getting the interview. At the end of the day it doesn't matter how much your CAP is if you can't answer the interview questions, which boils down to your mastery of the skills needed to being a SWE. Do things that you are interested in AND also benefits you.

Just wanted to hear your opinion on how much emphasis I should place on personal projects, grades, LeetCode, hackathons/coding challenges, job experiences, CCA involvement, etc.​

This is a hard question to answer because everyone is different. Some people are just born smart and don't have to study much and still get their grades. Some people are just not cut out for studying, but are great at building impactful side projects. Know your comparative advantage and leverage it. Personally, I could probably do back end work if I tried hard enough but I just don't enjoy doing it. I leverage my passion for design and attention to detail to build user interfaces and related tooling instead.

Strike a balance between breadth and depth. As undergrads, you can have a lot of room to explore and also relatively low stakes environment to fail. Take this chance to try out a lot of things, then choose what you really like and are good at. You can specialize after you have tried out enough things and know what you want and are good at. I've tried out back end, mobile, game development and prefer front end development the most.

By now you should know that not every investment reaps the same level of rewards. CCAs which aren't related to CS can be fun, widen your social circle and improve your soft skills. If that's important to you, by all means go ahead. But if you suck at programming, and spend all your spare time on random CCAs which doesn't help you in your craft, then you'll probably end up as a mediocre programmer. Back in school, I never really had an official CCA - I chose to do tutoring, work on open source stuff like NUSMods, and working as a boarding councillor at NUS High (sort of like RA but for NUS High Students), which gave me free accommodation near school). I liked the balance and diversity of the activities I had.

My CAP isn't that high - got first class but not near 5.00. I reckon I could get A+ for every module if I really spent all my time studying, but studying isn't exactly my favorite activity to do. I got my As usually from modules which were project-heavy. I value and enjoy the hands on experience more than the mugging experience.

I'm very lucky that Software Engineering exists so that there's something meaningful which I can spend my time on, I enjoy doing, and also pays the bills.

I want to learn as much as possible from you about topics that might benefit me as I'm graduating next year.​

DSA. No DSA mastery, no passing of interviews, no Facebook job offer.

I am not a recruiter and I might have answered some of the recruiting or internship-related questions wrongly, so take them with a grain of salt. Opinions expressed are my own and do not represent the views of my employer.

At Facebook where I work at, strong communication is crucial for a successful career. As engineers, sometimes we get too focused on execution and it's easy to forget about communicating our work broadly. Perhaps some of us are new to a large engineering organization and previously did not have the tools to foster communication nor was it emphasized by the company.

I love to code. Personally, I would love to shut off all communication channels and focus entirely on coding if I could. However, doing that will probably have disastrous effects. Communication is super important and I learnt that the hard way when I first started at Facebook. In my first year at Facebook, I made a few painful mistakes related to communication. I changed the project plans and timeline without informing my tech lead, resulting in my teammate having to cover me at the last minute and do the work I reprioritized without telling anyone. In another instance, I didn't communicate that I was going to do some work that my teammate had planned to do, resulting in wasted efforts. From then on, I made a mental note to myself to communicate broadly and early wherever possible and seek alignment. I'd err on the side of over-communicating rather than under-communicating (though sometimes I still forget).

Why is communication important?​

Most engineers in organizations don't work alone. When you work with people, you have to communicate with them — to set expectations, seek feedback, align on decisions, what not. However, given that remote working is the norm for most of us now, we rarely see each other face to face (I haven't met anyone on the team in person since remote work started). In product teams like the ones we have in Commerce Engineering Singapore, we work with a myriad of XFN partners across the globe in different timezones. These factors make it challenging to be in regular touch and makes it even more important to communicate widely. We have to explicitly communicate through stand ups, weekly syncs, retros, Work Chat messages, Workplace posts, etc.

Communicating well frequently and broadly helps you to:

Broaden your impact​

If you have built something that's useful for yourself/your team, chances are, they will be useful for others as well, so tell more people about it! My first project at Facebook was to build Sentinel, an internal code attribution tool for the humongous Ads code base with nearing a decade's history. The tool solved the problem of people/bots changing a set of files which they were unfamiliar with and not knowing who the best reviewers for those changes were. Nothing about the tool was specific to Ads. After building an MVP (Minimum Viable Product) version of the tool, we reached out to various tools within Facebook which use their own bespoke code attribution approach and we eventually helped to replace them with Sentinel attribution. We also integrated it with popular tools like our IDE (a FB-specific VS Code), our internal component library, and our internal in-browser code explorer. At the end of that half (2018 H1), Sentinel was used by 2% of all diffs at Facebook, which was a pretty significant number. As of writing, over half a million diffs at Facebook have used Sentinel and I would say a huge part of its success was due to the network effects generated by word-of-mouth advertising by our early adopters, our push to integrate it into popular tools, and links within these tools that Sentinel was powering the attribution.

Takeaway — Make a noise! A good product that many people use has more impact than an excellent product that few people use. Sentinel wasn't perfect at the time of launch but it worked well enough. One of the easiest ways to get people to use your product is to tell people about it! It can't get any easier. Getting some people to use your product early also gives you the chance to iterate on feedback and make it better before you launch it to a wider audience.

Improve your career performance and progression​

Communication has a huge impact on one's performance. If you aren't able to effectively update your manager on what you are doing, it is hard for them to help you stay on track to ensure you meet expectations for the half. At Facebook, Communication is explicitly stated as an evaluation axis of our performance review, but realistically, every axis involves communication. We saw how effective communication helps expand one's project impact in the Sentinel example above. Better engineering practices should be communicated to folks who work on the same code base so as to efficiently deliver products of excellent implementation quality. Strong communication also leads to successful conflict resolution, mentorship and recruiting.

Here's a scenario on how communication impacts calibrations - Alice's manager put her up for promotion to Staff Engineer after successfully delivering on an impactful project. However, due to lack of communication and visibility about her project, it's the first time other managers in the room heard about this project and many raised questions regarding it due to their unfamiliarity with it. This made the calibration process much harder than it should have been had Alice communicated about her project broadly earlier on.

Influence​

Influence is a core skill you need to develop as you grow your career, and communication is at the core of it. Senior folks are leaders and influential and are effective communicators. This is true regardless of IC (individual contributor) track or management track. Senior Engineers are expected to be able to influence the engineering culture in the broader team and possess strong communication skills to be able to explain technical information effectively. Recently I attended a meeting with a very senior Software Engineer and was blown away by how he managed to explain the concept of cookies in such simple terms to the non-technical folks in the meeting and how effective communication helps you to get things done. For those who are interested in embarking on the manager track in future, please also know that most of an engineering manager's job involves communication.

Foster alignment and save effort down the road​

At large companies of similar scale as Facebook, it's not uncommon for two teams at Facebook to face the same problem. I'll use Sentinel as an example again. By communicating about the project broadly and early, we reduced the possibility of teams working in silos to solve the same problem and leading to duplicated efforts. By knowing which teams faced similar problems and understanding their unique circumstances, we were able to collaborate on the problem and accounted for the different needs of the various teams, achieving a 1 + 1 = 3 effect.

Facilitate project planning and ensure timelines are met​

Imagine this extreme (but still plausible) scenario - Bob and his team have spent a few months working on a huge project which was slated to launch next week. However, the project is only half-completed due to unforeseen technical difficulties and lack of manpower. If Bob had communicated about the difficulties and progress earlier, his manager could have allocated more manpower earlier to help out, and the team would probably be in a better position to meet their deadlines. This scenario is unrealistic at Facebook in the sense that such issues would probably be caught earlier because of weekly syncs and progress update posts. However, it is still possible for smaller projects where there aren't any/many syncs.

Ways to communicate effectively​

Hopefully by now you agree with me that communicating effectively broadly and frequently is important! Here are some tips on how to go about doing that:

Leverage Communication Channels​

Each company has its own communication channel - Slack, Discord, Google Suite, etc. At Facebook, we use Workplace, which is similar to the core Facebook app, but for your company and every co-worker is a friend. Workplace is literally a communication tool and it is also the easiest way to get the word out about something. Draft a Workplace post/note and post it in the relevant groups. Attach screenshots/videos to better illustrate the point and catch peoples' attention. Add tl;drs at the top of your posts. Structure your posts according to sections for better organization. If you are unsure about what content should go in your post, seek a review from your manager/tech lead, most likely they'll be happy to help.

Write Wikis​

Write wikis for posterity and so that your work appears in intern search results. Add links to your new wiki in existing relevant wikis. Doing all these improves the discoverability of your work.

Shamelessly reach out to folks​

If you know of someone/another team that would benefit from your work or the information, reach out to them and let them know! Even if they don't have an immediate need for your work, they might in future, or can inform others about it. The relationships you build along the way might surprise you.

Thanks to my manager Nishita Agarwal and my teammate, Yao Yang Leow for proofreading and giving feedback on earlier drafts.

I assume that you're familiar with Python and the concept of binary trees. If you're not, you can read this article to get started.

The Problem​

Given a binary tree whose nodes contain values 0-9, we have to find the sum of all numbers formed by root-to-leaf paths. A leaf is a node that doesn't have any child nodes. In a binary tree, a root-to-leaf path is always unique. Here below is the expected behavior of the solution required:

In the tree on the left, the output is 25. 25 is the sum of 12 and 13, which are the two numbers formed when starting from 1 and visiting every leaf. In the tree on the right, the output is 1026 as it is the sum of the three numbers 495, 491 and 40.

The Observations and Insights​

1. To construct a number, we traverse the tree from the root to the leaf, appending digits where the most significant digit is at the root, and the least significant digit is at the leaf. We visit some leaves before other nodes that are closer to the root. This suggests that a depth-first search will be useful.

2. The construction of numbers is incremental and similar of sorts: the only difference between 495 and 491 (from the tree on the right) is the last digit. If we remove the 5 and insert a 1 in its place, we have the next required number. A number essentially comprises of the leaf's digit appended to all the digits in ancestor nodes. Thus, numbers within the same subtree have common digits.

3. Finally, notice that this problem involves a tree, so a recursive solution is helpful.

The Solution​

We can do a pre-order traversal of the tree where we incrementally construct a number and exploit the fact that numbers formed by nodes in the same sub-tree have common digits. When we're done forming numbers in a sub-tree, we can backtrack and go to another sub-tree.

Let's create a Solution class to encompass our solution.

class Solution:
  def sum_numbers(self, root: TreeNode) -> int:

The method signature given to us in the problem has one argument: root, which is of the type TreeNode . A TreeNode class is as follows (from LeetCode):

class TreeNode:
  def __init__(self, val=0, left=None, right=None):
    self.val = val
    self.left = left
    self.right = right

From observation #2, notice that appending a node's digit to its ancestors can be achieved by moving all the digits of the number formed by ancestors to the right by 1 place and adding the current node's digit. The digits can be moved by multiplying the number formed by ancestors by 10 (since we're in base-10). For example:

495 = 49 x 10 + 5

Thus, we can keep track of the current digits in an integer. This is important because we won't incur extra storage space for higher input sizes. We can pass around this value in the function parameter itself. Since the method signature given can only have one parameter, let's create a sum_root_to_leaf_helper method.

We can think of the sum_root_to_leaf_helper method recursively and process each node differently based on whether or not it is a leaf.

• If the node is a leaf, we want to add its digit to our current digits by moving all the other digits to the right. We also want to return this value (since we'll backtrack from here).

• If it is not a leaf, we want to add the digit to our current digits by moving all the other digits to the right. We also want to continue constructing the number by traversing down this node's left and right subtrees.

If the current node is a None, we can simply return 0 because it doesn't count.

Thus, our sum_root_to_leaf_helper method will be as follows:

def sum_root_to_leaf_helper(node, partial_sum=0):
  if not node:
    return 0
  partial_sum = partial_sum * 10 + node.val
  # Leaf
  if not node.left and not node.right:
    return partial_sum
  # Non Leaf
  return (sum_root_to_leaf_helper(node.left, partial_sum) + \
    sum_root_to_leaf_helper(node.right, partial_sum))

We use a default value for the partial sum to be 0.

In our main method, we want to include the sum_root_to_leaf_helper method as a nested method and simply pass on the node parameter. Finally, this is how our solution looks:

class Solution:
  def sumNumbers(self, root: TreeNode) -> int:
    def sum_root_to_leaf_helper(node, partial_sum=0):
      if not node:
        return 0
      partial_sum = partial_sum * 10 + node.val
      # Leaf
      if not node.left and not node.right:
        return partial_sum
      # Non Leaf
      return (sum_root_to_leaf_helper(node.left, partial_sum) + \
        sum_root_to_leaf_helper(node.right, partial_sum))

    return sum_root_to_leaf_helper(root)

The Algorithmic Complexity​

When we come up with a solution, it is important to analyze its algorithmic complexity not only to estimate its performance but also to identify areas for improvement and reflect on our problem-solving skills. We should always ask the question: can we do better than X? Where X is the current complexity of our solution.

Time:

Our solution is a modification of the depth-first-search pre-order traversal where we visit all nodes exactly once and perform a trivial computation (moving digits by integer multiplication). Thus, our runtime is simply O(N) where N represents the number of nodes in the given tree. A solution better than O(N) doesn't seem possible because to construct a number from digits, we need to know all the digits (and thus visit all nodes).

Space:

In terms of storage, we incur a high cost in the recursion call stack that builds up as our sum_root_to_leaf_helper calls itself. These calls build-up as one waits for another to finish.

The maximum call stack is dependent upon the height of the binary tree (since we start backtracking after we visit a leaf), giving a complexity of O(H) where H is the height of the binary tree. In the worst case, the binary tree is skewed in either direction and thus H = N. Therefore, the worst-case space complexity is O(N).

You can read this article to know more about recursion call stacks.

It is possible to do better than O(N) by using a Morris Preorder Traversal. The basic idea is to link a node and its predecessor temporarily. You can read more about it here.

The Conclusion​

I hope this post helped! Please do let me know if you have any feedback, comments or suggestions by responding to this post.

Acknowledgements​

Advay, Kevin, Louie for reviewing this post and Yangshun for the idea of adding it as a blog post.

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 wondered the same question to myself 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 a 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 most fast-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 screens) 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 exists many use cases where the desktop still excels at. 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 development 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 their 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? Great Front End developers (or Software Engineers really) go beneath the abstractions 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 Intepreters). 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.