Job market today

Employers are inundated with fake applications, and job seekers get no responses. No one can find each other. Job requirements and expectations are rising at the same pace as AI stocks. Junior roles have all but disappeared, and staff+ roles are plenty but the desired skillsets often look more like a wishlist than a candidate profile. Both hiring managers and company leadership are a bit delusional. I’d say even candidates are a bit too — most recruiter calls start with setting salary expectations that they don’t pay like Anthropic and ending with “please don’t cheat, good luck”.

The traditional full-stack, frontend, or backend specific role is disappearing and replaced by all-encompassing product engineering roles. Instead of a team with a senior/staff team lead, 2+ frontend/backend engineers that cover the full stack, a designer, and a PM, the new team structure is just a single staff product engineer that does everything with AI. Where there are knowledge gaps and needs for specific skillsets in the org, dedicated staff+ roles are then created for things like frontend build systems, agentic workflows, distributed systems, and other niche skillsets that product generalists may not have deep knowledge in. If I have any advice here, it’s to broaden your scope of knowledge so that you cover a full product development cycle for the product engineering roles.

The forward deployed engineer role is another avenue for full-stack engineers with team lead and product experience. The same people skills to talk to internal stakeholders, gather requirements, scope, and execute can be applied to client-facing work for this role. In the age of AI, humans are now a valuable differentiator when large enterprises are paying millions for software, implementation, and support. Many AI companies are struggling to fill these roles and the requirements differ quite a bit company to company. It seems to be around 40% software engineer, 20% product manager, 20% systems/solutions architect, 10% technical sales, and 10% enterprise customer support, certainly a lot of hats for a single role.

A good summary of what’s in-demand today from a Stripe recruiter: “all-around generalists who are spiky in specific areas”.

Trends and Observations

Remote jobs are extremely competitive these days. There are often 5+ rounds with the final onsite at one of their HQ offices and a reference check at the end. Because the full process is remote, these companies are even more rigorous about hiring and sniffing out cheaters and culture fit. Be open to relocation to the bay if you’re not here already, or at least Seattle and New York to expand the job opportunities. Companies like Reddit and Airbnb that are fully remote have their top pick from the candidate pool because of that flexibility. New York seems to have a much higher bar for candidates while paying less than the bay.

Chaotic recruiting processes are norm. It seems like recruiting teams have been cut heavily and recruiters are expected to run with fewer coordinators that were responsible for scheduling and follow-ups. Newer tools like Ashby aren’t fully replacing human coordinators because people are ignoring scheduling requests or forgetting to block out their calendar for vacation. I’ve gotten ghosted by recruiters and companies halfway through the process more than a few times. Recruiters simply don’t have time to make sure all the candidates for each of their open roles get courtesy treatment, a stark contrast to 5–10 years ago. Be prepared to drive the recruiting process.

The worst part is the online applications with endless online assessments and take-home projects. The online assessments sometimes arrive right after application submission to filter down the number of candidates and get a rough sense of skill. Some have take-home projects that are hours long and more freeform, but still graded by AI based on a few narrow criteria. It’s a shame that most companies run a depressing robotic pipeline turning a career journey into a factory.

Most interview processes now look something like this:

1. Online application
2. Automated code screen
3. Recruiter chat
4. Take-home project or tech screen
5. Tech screen 2
6. Onsite — systems design, coding, behavioral, and another technical round
7. Leadership (bar-raiser or behavioral)

Application Strategy

The best route is to get referrals. It’s best to get someone who personally knows you. A random referral might get your resume reviewed by a human, but a good referral can vouch for you when the review panel is on the edge about your performance, or advocate for you when you get down-leveled. Find someone who worked with you in the past and has positive things to say about the scope of work, technical abilities, and working well with others.

If you do go the online application route, make sure your resume is tuned for both human and machine reading. Make sure the relevant keywords are included in the tech stack you work with as well as any related tools. Include well-known or top-tier companies, even if the experience is decades old or internships. Make sure your school and degree are easily parsed as well so they’re not empty fields in the ATS. Then make sure each job experience has action verbs and metrics so that the hiring manager understands the scope of your work at the senior or staff level when they read the resumes.

Also take into consideration that many recruiters now vibe code their own resume parsers instead of doing manual reviews. In one recruiter screen, we got sidetracked on personal projects and talked about how the recruiter vibe coded a resume tool that filters based on top schools, previous companies, skills, and estimated seniority. Honestly pretty cool for a recruiter, but terrible for candidates.

In short, the resume needs to survive ATS parsing, human review by hiring managers, and perhaps some basic AI filtering algorithms made by recruiters. ChatGPT and Claude are pretty good at this if you prompt them to optimize for all three criteria here.

Also take into consideration where companies source their candidates and what culture and profile they look for. Reddit and Airbnb, for example, mostly hires from FAANG. Netflix rarely hires L6 externally, and L7+ openings are almost exclusively promoted from internally. Many OpenAI people come from Meta, and Anthropic people from Stripe. Tesla and Amazon feed SpaceX. You’re climbing an uphill battle if your current or past companies don’t exhibit the same cultural values and technical standards so prioritize the relevant companies first.

The old advice of applying to the less desirable companies first for practice is no longer feasible. I found that top companies like Google, Stripe, OpenAI were able to process their applications much more quickly if I matched what they were looking for. I almost never heard back from startups I applied to, and when I did, it would be in weeks or months and I had totally forgotten about them. Many startups now do paid work trials for referrals so the interview experience isn’t even good practice.

Automated Online Tech Screen

I only have bad things to say about HackerRank and Coderpad. It’s an unfamiliar place to write and test my code, in a new environment while working under severe time constraints. I’d get fired if I worked like I was speed-running through tasks on the job. Why try to qualify candidates this way? In hindsight, it speaks a lot about the company culture, engineering leadership, and the type of engineers you’d work with.

If it’s a single problem, get through it quickly and make sure it scores 100%. If it’s a multipart problem, try to get through each step quickly and forget about code quality. Some parts or steps might be worth more points than others, so it may be better to complete step 4 instead of step 3 depending on the point distribution, level of effort, and time remaining. A machine is grading it and it just needs to pass the test cases. Even returning the exact output to pass 1 test case is better than nothing.

How to prep? Be resourceful. Familiarize yourself with Coderpad and HackerRank, they often have an open practice question to try the IDE. Use all your resources such as Reddit, Glassdoor, Blind, and 1Point3Acres to find past interview experiences and leaked question banks. Practice the leaked questions thoroughly before attempting the actual run. If you don’t utilize these question banks, someone else will. (Nvidia, Uber, Ramp, and Capital One are notorious for this type of assessment)

Recruiter Screens

Do some research on the recruiter before the call. If they are a junior recruiter or candidate sourcer, they likely pass the information to the hiring manager for review. If they are an experienced recruiter, they have the power to move you to the next round.

Sourcers are usually provided with a set of questions by the hiring manager to ask the candidates, and the meeting recording is summarized and passed back to the hiring manager for review. Sourcers are often new to tech or recruiting and don’t really know how to talk tech. Your best bet is to try and include some tech stack keywords and convey experience level through the answers during the call. It’s also a sign that the company is looking beyond traditional channels, perhaps to expand their candidate pipeline. Your chances aren’t very good with a technical sourcer simply because they’re sent to find the diamonds in the rough.

Experienced recruiters usually lead the call and can comfortably navigate topics or ask follow-up questions. Sometimes there are curveballs like the Anthropic AI safety questions, but otherwise be prepared to talk about your impact and contributions. It’s mainly to get to know you and build up rapport on both sides for the next steps. Unless there are red flags, you’re likely moving forward.

AI Assisted Coding Rounds

This is a very new type of interview that only started this year. To be frank, I don’t think interviewers and companies know exactly what to look for and there isn’t a solid rubric because “best practices” change every month with every new model and agent. It’s mainly split into solving a reasonable problem better than you can manually code by hand, or solving an extremely difficult problem you would otherwise not finish by hand. Your goal is to not get eliminated by their list of negative actions to watch out for.

Stripe and Anthropic are in the reasonable difficulty camp. You could copy and paste the prompt in, and Claude may even confirm some assumptions before 1-shotting a reasonable answer. DO NOT DO THIS! A very good programmer could probably finish a solution by hand in the given amount of time. What they want to see is that you understand the problem, can break it down in a reasonable manner, and have AI work on it while remaining in control of the final outcome and quality. You should fully understand the architecture as well as most of the files generated. Prompt using your own words, describe the actual implementation like creating task tracking tickets with pseudocode, and start the project in planning mode, then have the agent step through while you verify each step’s outcome.

Mercor and OpenAI and a few other AI labs are in the complete opposite direction where there is absolutely no way you can finish a directed graph with topological sort and validation problem in the hour allocated while simultaneously reading through a 5 page requirements document. They’ve also tested their prompts against all models to make sure you cannot 1-shot the solution. It’s best to fully grasp the problem mentally, summarize and give the algorithm and problem approach to Claude, have it code using parallel agents, and use adversarial reviewers to make sure each portion is done correctly. Then use the agent again to navigate the code repo and spot check the core implementation. Watch out for automated submission scripts too. Some of them will upload your agent chat logs to their server to grade your approach. You’ll be asked to bring your own computer so make sure you have a Claude Max subscription so you don’t run out of tokens half way, and switch between Fable for planning or reasoning complex tasks and Sonnet for coding speed to finish on-time.

Sometimes, these AI coding rounds are in the form of take-home projects and your goal is to do the same, but make it presentable and clearly explain your approach in a README or screen recording. Most of these AI take homes also upload your agent chat logs.

I have also noticed a pattern where traditional companies get offended when I say I do almost all code with AI. At the same time, it’s also a red flag for AI companies if I say I prefer to do even a small amount of coding by hand. I never expected this topic to be so polarizing that I’ve settled on the answer “I delegate most form UIs and well defined tasks to Claude and take extra care when creating core utilities or business logic. Sometimes I write code by hand so I fully understand the logic and the potential upstream and downstream effects.” It seems like a terrible way to judge candidates’ competency but I also see the need to filter out vibecoders and workflow laggards alike.

Hello Interview has a pretty good section on how to approach AI assisted coding rounds, what interviewers assess for, and things to watch out for as a candidate. It’s the most up to date and comprehensive guide I’ve seen on all the prep sites. They also have some practice problems, although in my opinion the problems are a bit too easy.

Technical Screens

Leetcode is no longer the focus. This round at the senior or staff level makes sure you can write code by hand, fully understand the problem, the implications of each line, and what optimizations can be made. The assumption here is that you will likely use an agent to write code on the job but you should be able to debug and fix things if anything goes wrong. I still think Leetcode is good practice to go through their top 50 easy and medium questions while talking through the implementation.

Data structures and algorithms are still important nonetheless. I’ve gotten some optimization questions verbally that required more advanced memoization or greedy algorithms.

There are many LeetCode videos online and I found the pattern of writing some comments to confirm requirements a good place to start, then get right into coding because half the battle is finishing within the allocated interview time.

Debugging Interview

I’ve been through a select few rounds where the goal is to debug a couple things that are broken in an existing codebase. It’s pretty popular with Stripe, OpenAI, and quite a few Bay Area startups for phone screens. These are usually split between frontend or backend, and you’ll be given a choice during the recruiter chat.

• Frontend is typically an asynchronous fetching or state update issue, some common but tricky CSS layout bugs, and a rendering or other performance issue to fix.
• The backend seems to center around bugs in data parsing, race conditions in parallel execution, and sometimes an unoptimized N+1 SQL query.

If you regularly code and debug, this round shouldn’t be too difficult. A good place to start is to pick an open source project, find some issues marked ready for new contributors, and attempt to solve it without AI. The skillset here is navigating a large codebase by hand, finding potential leads to the problems, and then fixing them.

Systems Design

This is the bread and butter of senior and staff interviews and is worth dedicating the majority of your time preparing. The goal here is to be extremely articulate about tradeoffs upfront and identify performance and scaling constraints unprompted. The last time I’ve interviewed was in 2022 and I can say that the bar for current senior is the old staff, and the current staff is everything under the sun. A good interviewer will probe for your area of expertise and allow you to demonstrate your area of expertise, but most interviewers are bad and will just sit and watch you talk while following up to nitpick topics in their own area of expertise.

Practice system design using Excalidraw as your chart diagram tool. Use all the keyboard shortcuts so drawing becomes second nature. Many companies now use Coderpad for interviews and their drawing tool is an embedded version of Excalidraw.

Designing Data-Intensive Applications, 2nd Edition is a good place to start to learn about the systems as a whole and in more depth than most of the online prep guides. The 2nd edition has updated estimations of capacity limits of various systems as well as dedicated chapters for real-time applications regarding agentic and AI systems. Unfortunately, this book is also quite dense and requires at least 1–2 weeks to properly digest when studying 1–2 chapters a day.

Hello Interview is a great resource for quick refreshers before an interview and has really good 1-pagers for each topic like Kafka, Postgres, Cassandra, Temporal, and Redis. The “Numbers to Know” page is a gold mine for capacity estimation. Product engineers are now expected to know backend and distributed systems so a team of 1–2 people can cover everything a team of 5–8 used to on a traditional project.

I’ve noticed that recent interviews, especially for AI companies, tend to cluster around a combination of these topics:

• Build ChatGPT (or agent for XYZ product)
• Build a distributed web scraper (distributed task runner with queues)
• Build Uber or Stripe (workflow and transactions)
• Build Google Docs (real time multiuser editing)
• Durable execution
• Write heavy vs. read heavy databases
• Caching strategies
• Queuing, scheduling, event-driven processes
• Real-time streaming updates via SSE/Websockets/gRPC

To get to the real depth of knowledge that you may need for a more backend or systems-focused role, you can’t just recite an answer from Hello Interview. It’s good to reference Hack2Hire solutions which have more technical and in-depth knowledge as well as ShowOffer for a third opinion. You are ready for staff when you can identify the trade-offs between the 3 solutions and clearly articulate them in your own solution from start to finish unprompted.

Take the rideshare example between Hello Interview, Hack2Hire, and ShowOffer:

• For real-time updates for rider driver matching, Hello Interview prefers native mobile push notifications which seem like an easy way out of discussing real-time updates, and both APN and FCM lack delivery time guarantees and receipts. Hack2Hire and ShowOffer both use WebSocket which is bidirectional, but is stateless and lacks recovery mechanisms in case of connection drops. SSE is actually better because it sends missed events on connection recovery, and utilizes existing HTTP protocols so requests route through proxies and corporate firewalls without extra configuration. Since there’s only a cancel option when matching is in progress, bidirectional communication with WebSocket is unnecessary. Both SSE and push are needed for a full solution, SSE for UI updates when the app is open and more progress details can be shown, and APN/FCM for when the app is backgrounded.
• Rider/driver fanout is part of the Hack2Hire deep dive, an improvement to the “find nearest riders/drivers” black box algorithm in HelloInterview and ShowOffer.
• Hello Interview mentions Temporal and durable execution as part of their solution, whereas Hack2Hire and ShowOffer rely on distributed state stores in Redis and Postgres for state tracking. Interviewers who ask this question often expect durable execution as an up-to-date answer to this problem, with the limitation that workflow engines need proper consistent sharding and clusters to handle burst and high throughput.
• Hello Interview’s ride service writes to the DB, then adds rides to a queue, which then pushes the rides to Temporal. This pattern risks orphan rides in the DB if the server crashes after a write, before adding to the queue. An improvement would be to use Kafka Connect CDC to stream changes from the database and watch for rides added to the table. In practice, a user would just cancel that ride when stuck waiting for a while and try again. While this pattern isn’t expected as a first attempt or even part of the final solution, it regularly comes up as “what if?” and complexity trade-offs discussion during deep dives for FAANG and MANGOS interviews. The design Stripe problem from the three prep sources has many mitigation techniques that are worth a study.

I hope this is a good example of the direction and depth to study for since there aren’t many examples or videos online of what a 4 or strong hire looks like at the staff level. The comments section of Hello Interview is an extremely valuable resource as well. You can see the many different takes on why or why not XYZ for every part of the system. I’d imagine as a distributed systems engineer, the bar is even higher for staff.

For product engineering at AI companies, they will likely expect some knowledge of AI systems. That means understanding at a high level of how an agentic system operates, what pre-training and post-training entails, how RAG retrievals add context and reduce hallucinations, what an inference scheduler does, why KV caches exist, etc. The expectation for an applied AI engineer isn’t to build that system, but to know how to use such system while working with its strengths and limitations.

In terms of delivery and presentation, Hello Interview’s system design video walkthrough by Evan King are a good example of what to strive for as a senior candidate in terms of technical ability, and senior or staff candidate in terms of communication style. In my experience with staff level interviews, the trade-off discussions go much deeper than Evan’s videos and most YouTube examples, often into the core of the technology itself such as how exactly Cassandra manages high write throughput and durability, and how LSM trees and SSTables work under the hood to power Cassandra and ScyllaDB. Similarly, durable execution often dives into Temporal Activities, Signals, replay, and rollback scenarios for 99.99% SLA. Often times, the interviewer might suggest an alternative pattern and ask for your opinion. There are also curveballs thrown where irrelevant systems and information are added, or you’re asked to double-check certain answers and assumptions even though they are correct.

Ask ChatGPT or Claude to poke holes in any given final design from these prep sites and see if you can defend or suggest changes. Interviewers often ask at the end of the interview what if the system is designed this other way and what impact it might have on performance, reliability, or maintainability. Having good insights and answers, along with anecdotes from personal experience, seems to make the difference for a strong hire on the systems design.

The system design is also my worst round judging from what little feedback I’ve received from recruiters and my personal feelings. I actually paid for 2 systems mocks with L6/7 engineers after failing a bunch of interviews just to get a sense of my own weaknesses. Aside from some missing technical depth in distributed systems, the mocks revealed that I didn’t deliver with enough confidence, sometimes rambled and used filler words, and my delivery felt too structured and prepped. I was also told I spoke too technically when asked to expand on topics and it is a staff engineer’s job to explain tech to leadership in a way that a non-technical person can understand the system. This was a mind-blowing revelation to me because I thought this interview round was for a technical audience only. It’s hard to get this level of feedback doing mocks with friends and I’m glad I paid for them.

Product Thinking

Quite a few companies now have some form of product thinking assessment for product engineers as well, especially the startups. It’s sometimes embedded in a second system design round, in one of the coding rounds, or in a behavioral round. It feels very similar to a product manager interview, a role I studied and interviewed for very early in my career.

I know PMs use Decode and Conquer as one of the main prep books for the PM role. I recommend skimming through examples with the CIRCLES and DIGS framework to understand the expected output, tell it in a story format, and insert your own snippets of knowledge from your experience. As a technical person, many of the book’s practice scenarios and technical examples are outright ridiculous so take it with a grain of salt.

Decomposition (Forward Deployed)

I was kind of stumped my first time doing a Palantir-style decomposition interview. It was framed as a “product discovery and behavioral chat” with leadership where I was given a very vague business goal and the interviewer role-played a non-technical customer stakeholder. It is similar to defining high-level business goals and KPIs, then working through new products and existing system improvements around that goal, but for an external customer where you don’t know what systems might exist. Someone operating at the staff level should be somewhat familiar with this already for quarterly business planning and other high level meetings.

This interview is almost guaranteed to be a round for forward deployed engineers, but I have also been asked by some AI startups for a “0 to 1 product engineer” role. I’m not an expert at this by any means so this is more of a heads-up that this special type of interview exists. You can find some prep materials online if you search for decomposition and Claude or ChatGPT can do a decent job roleplaying it too.

Behavioral and Leadership

Most interview prep guides have a pretty comprehensive list of questions that you might expect — disagreement with a coworker, dealing with ambiguity, demonstrating ownership, etc. It’s really important to prepare these ahead of time so your story flows well and gets the point across. Try to have many stories prepared for multiple projects so that you’re not telling the same story over and over. Many guides will tell you to use the STAR method, but in practice it may sound a bit too structured and unnatural if all 5 behavioral stories are explained the same way.

In my mocks, I’ve been given feedback that at the staff level, the stories should explain the situation (project) in a non-technical way so that a PM or executive at the company can understand. Keep the STAR method in mind, but try to tell it in a way where each story has variance and doesn’t feel scripted. Staff engineers are also expected to communicate much better than senior engineers.

I really struggled with the “Why us?” question that every company seems to ask nowadays. For some companies, it felt quite natural to talk about my passions and how they align with the company’s products. For others, it felt disingenuous to LARP being mission-driven for the companies that are trying to win at all costs. I didn’t pass the Anthropic behavioral round likely because I didn’t truly believe Anthropic prioritized AI safety above growth. It was also hard to interview for SpaceX and answer questions about the mission and leadership when Elon, for all his sharp business acumen and work ethic, had racist tendencies. Perhaps that’s the intent, to filter out candidates that don’t quite align. Most prep guides have a template or example on how to answer, but they don’t really work for every company. I’ve settled on a very neutral statement about working with smart colleagues, an interesting mission, and a great place to grow a career if I can’t find anything genuinely nice to say, along with some ChatGPT suggestions on how it relates to my past experiences and interests.

Project Deep-Dive and “Bar-Raiser”

This round seems to be popular with some companies that purportedly hire “top performers” including SpaceX and some startups with ex-Amazon leadership. The interview is designed to gauge your contributions in your past roles on your resume. I’ve never interviewed for Amazon so I can’t speak about the original bar-raiser. In my experience, it’s a deep dive into a recent project, what my contributions are, challenges and learnings, and any improvements to the system if I had unlimited resources. It’s extremely helpful to have a systems diagram handy so you’re not drawing while explaining during the interview, and the process of creating that diagram beforehand is also a great way to prep for discussion topics ahead.

This round is a mix of behavioral, leadership, and systems design about a past project with an extra diagram prepared, but don’t take this round lightly as it seems to weigh heavily in terms of leveling.

Company Specific Rounds

Some companies have special rounds dedicated to finding culture fit. I won’t go into specifics but make sure to do some research and prepare for these

• Netflix culture — radical candor, top of the market pay, B-performers get severance packages
• Anthropic safety behavioral — how to build AI systems safely, biggest risk of AI in society
• Shopify life story — bring your own diverse background to the company and team

Work Trial

Instead of going through a full panel of interviews, some early-stage startups may just do a week-long paid work trial as a holistic way to measure a candidate’s performance. Often, candidates come from direct referrals and are offered a trial after a quick phone screen with one of the cofounders. I didn’t personally go this route because the companies at this stage are a bit too small and early.

Prep Resources

High Priority:

Designing Data Intensive Applications, 2nd Edition — $60 for the printed edition, free e-book with O’Reilly subscription. good book for breath and figuring out what more to study about distributed systems.

Hello Interview — $80/year, this is a really good 1-stop-shop for all interview prep, the free content for system design is enough for junior roles, senior and staff candidates will benefit from the paid advanced topics and video examples.

Inference Engineering — Free e-book from baseten, great overview for non-AI background seeking AI related product roles

In-Depth or Topic Specific:

Hack2Hire & ShowOffer — some free and paid systems designs to supplement your understanding and trade-offs from Hello Interview

Software Architecture: the Hard Parts — builds on DDIA for more in-depth distributed systems knowledge, its a very dense read and assumes you already have some knowledge.

PrepFully, interviewing.io, IGotAnOffer, MeetAPro — paid mock interviews with L6/7+ big tech hiring managers and interviewers to get personalized feedback on your own performance. keep track of the interviewer ID so you don’t book the same person twice.

Other interesting reads:

Post-mortems — learn about how systems fail at scale, Dan Luu has a great list on GitHub. They’re really good resources for learning about the root cause of failures 3 levels deep at scale and mitigation steps for the future.

Engineering blogs — companies usually create posts when they solved a novel problem in a unique way and wants to share their learnings with the community. Figma and Notion both have some great posts around real time editing and conflict resolution. Chrome has interesting updates on web technologies in general. Many interview questions and prep guides source their systems knowledge from these blogs.

Newsletters — ByteByteGo, React Status, Javascript Weekly, Benedict Evans, and Stratechery are all great for keeping up with changes in tech. These won’t directly help you in an interview, but keeping up-to-date in trends is an important part of working in tech

There’s also a bunch of vibecoded question banks and interview prep sites that are complete garbage. If you search on Google or ask your agent for “[insert company name] interview questions”, these will certainly pop up as the top results. Don’t waste your time reading them. You’re better off asking the recruiter about coding exercise formats and systems design topics and preparing on your own.

Other interview logistics and reading between the lines

Most of my interviews for cold online applications came from newly posted roles that just opened. Some were also from LinkedIn where the job is recently “reposted”. I imagine the recruiters go through the pile periodically and stop when they have a decent shortlist to interview so the subsequent applications are just ignored. The best strategy is to apply immediately when the roles open.

There are application limits for most companies now, even if they’re not disclosed or enforced during submission. I’d say 3–5 applications per quarter is probably a safe upper bound, with no more than 2–3 per month per company. If you have an agentic application strategy, chances are, you’ll end up in the ATS spam bucket. It may be better to wait for a more relevant role than waste a shot on a distant fit.

Don’t be afraid to follow-up to remain in the recruiting pipeline and move onto the next step in the current state of interviews. It seems like results from phone screens and online assessments are quick and respond within 1–2 days of completion. The final round sometimes takes up to a week, with the debrief happening mostly on Thursdays or Fridays, even for a Monday interview. If you don’t hear back, don’t be afraid to follow up because chances are, the recruiter has 100 other candidates and your results are lost in the mix.

I’ve also been in a situation where I was definitely a backup candidate. A recruiter asked to schedule a second technical screen 2 weeks out and a week before the scheduled day I received a templated email saying the role has been filled. There were also instances where we moved suspiciously slowly, with each step taking upwards of 2 weeks to complete. I speculated that there was an entire cohort of candidates moving through each step at the same time and I was eventually rejected before the final on-site and 2 weeks after my second phone screen. I believe that in both cases, I wasn’t the top candidate and the lack of communication shows.

In the case where I might be the top candidate, the recruiters sometimes suddenly switched on and pop up right before the final round. They prep me for the interviews and give me additional details around what happens at each round and the type of problem to expect. After the round, they can see the feedback submitted immediately, even before the group debrief. If the scorecards are good, I would receive an email the next day to check in and ask how I felt about the company and the team. If the scores weren’t good, it’d be radio silence and an automated rejection email scheduled for Monday morning. At best, I’d get a chance to schedule 15 minutes with the recruiter to close out the interview process.

In many ways, recruiting is exactly like dating. Recruiters and hiring managers chase the top candidates with the shiniest resumes, bench the backups, ignore the rest of the inbox, all while claiming there aren’t enough qualified people to fill the openings.

Last Thoughts

The small difference that got me across the line was mainly referrals from people who worked with me personally along with tweaking behavioral answers, studying more systems design depth, and practicing better communication.

I definitely feel like I got lucky with the last few offers because the interview rounds hit my areas of expertise and preparation. The referrals vouched for me in a way that no amount of behavioral interviews could have. I’m very thankful for the friendships I’ve made in my last few jobs.

Am I a slightly better engineer after studying all this system design and going through interview rounds? Definitely. Could I have learned all this on the job or consulted ChatGPT when needed? Surely yes. It’s one thing performing the duties of a staff engineer and another to pass an L6 interview by showcasing experience, knowledge, and behavior in a short span of 4–6 hours.

I’m not affiliated with any of the books/sites/resources. You’ll see a few products mentioned because I genuinely believe they’re worth the time and money. I paid for everything out of pocket and nothing is sponsored.

If you believe technical interviews are a bunch of 💩, you are not alone. These interviews are like performances where engineers prepare for weeks or months to put on a handful of shows for companies looking to hire. I realized during my time preparing for interviews that there are so many different topics to prepare for and that the resources for those are scattered across so many different places, if they exist at all. Many people have asked me where to begin, how much time to spend on each topic, and what different companies value. I created this guide in hopes of helping you get the most of your preparation time and beat the technical frontend interviews by providing a list of specific commonly encountered topics and questions to prepare for.

Unfortunately for frontend engineers, algorithms and LeetCode aren’t the only things standing between us and our dream jobs. In an effort to diversify the range and practicality of questions, many companies started doing the so-called “frontend interview” where HTML, CSS, and JavaScript knowledge is also required. The companies that do not have frontend specific interviews will likely put candidates through their generalist interview. In order to do well in all interviews and maximize the number of competing offers across different companies, candidates have to prepare for both generic algorithm problems and frontend scenarios, increasing the amount of knowledge and preparation the candidates need.

The estimated 50 hours in this guide assumes you have frontend experience and a good understanding of data structures and algorithms. The time amounts to roughly 1–2 weeks of full time studying and applying for jobs or 4 weeks of part time prep after work or on the weekends.

Types of questions

I prioritized this list according to how much each topic potentially weighs on your overall interview performance and the amount of improvement you can gain by preparing for it.

The hours is a rough estimate of how you can split up your 50 hours of prep time.

1. Frontend working knowledge — (5 hours) This comes in many shapes and forms including take-home projects and recreate-this-design live interviews
2. Data structures and algorithms — (25 hours) Leetcode style problems
3. Async programming and JavaScript specifics — (5 hours) Managing callbacks and events along with functional programming paradigms
4. Data manipulation — (2 hours) Transform one shape of data into another
5. Systems design — (10 hours) Frontend and backend systems design
6. Behavioral — (2 hours) How do you react in certain scenarios? What qualities do you have?
7. Frontend trivia —(1 hours) This is like playing jeopardy with HTML, CSS, and JavaScript where you answer questions about esoteric knowledge
8. Company specifics — (0+ hours?) Netflix culture?

Frontend working knowledge

Prep 5 hours

I put this before data structures and algorithms because this portion is often done as a technical phone screen or take home project earlier in the interview process. This is the one topic that should be most similar to the work you have been doing but that doesn’t mean you can completely skip preparation. Many of the requirements, including using vanilla JavaScript with no frameworks, will be different than what you are used to at your current workplace. Startups and less technical companies tend to value this part of the interview a lot. Because this is very similar to actual work, poor performance here is detrimental to your candidacy and heavily impacts leveling potential for frontend specific roles during hiring committee review.

Recreate-this-design interview

During an on-site or phone screen, the interviewer may ask you to create something in code given a design or list of specifications. More often than not, this interview also serves as a frontend systems design interview as well.

• Log viewer (Squarespace 2018) — Create a scrollable view that renders log entries and details
• Poker cards (Airbnb 2019) — With a deck of cards, shuffle the cards, generate a poker hand, and display the cards
• Phone input (Stripe 2019) — Format an input such that numbers typed in are rendered like (123)456-7890

Tip #1: Ask questions to clarify the scope of the problem you solve for. The specifications you received is most likely incomplete. Is the list API paginated? How can users interact with the UI? Should it be designed for mobile? Your interviewer will likely have a more comprehensive rubric to grade you with.

Tip #2: Componentize wisely. Instead of writing one big chunk of code, break down the individual pieces and discuss how certain components could be reused.

Tip #3: Talk through performance. Consider how API loading impact your interface and how user experience can be improved with placeholders and loading indicators. Prioritize loading the most important part of the interface first if possible.

Tip #4: Consider accessibility. Does the interface support keyboard or touch navigation? Are the elements using the correct HTML tags with proper attributes?

Take-home project

A take-home project is sometimes used instead of a phone screen and consists of building a more complex app. It most likely comes with a blank slate or a very minimal skeleton to get started. There will also be a fairly lengthy set of instructions and specifications to follow. These take-home projects are not too common anymore because grading takes a similar amount of time as an interview and plagiarism is a common concern.

• Snake game (Squarespace 2018) — Create a snake game with HTML, CSS, and vanilla JS
• Hangman Solver (Hulu 2015) — Programmatically solve hangman by hitting an API endpoint with letter guesses
• Movie list (Vimeo 2016) — Given a movie list API, render the list of movies, make a popup for movie details, and animate it’s transition

Tip #1: Attribute code you have copied in the comments. If you found a function to generate a random string from StackOverflow, paste the link as comments in the code and briefly explain why. The grader will understand that you don’t want to spend 15 mins implementing UUID when the project is creating a todo list.

Tip #2: Do not borrow code in its entirety. If the company asked for a todo list, do not follow a tutorial for todo list in React. It is pretty obvious to the grader when the code is copied because others may have also copied from the same few tutorials with the same potential bugs.

Tip #3: Go a little above and beyond if there is no hard time limit. If you passed the suggested time limit and you barely finished, take some time to make the code and the user interface look good. I almost never hear of submissions being penalized for taking a little extra time. Often, I see feedback praising code cleanliness and good documentation even though these are pretty quick to fix and write. On the other hand, if you are way overtime, it is a sign that the role you applied for isn’t the right fit for your current skillset and that you need to prepare a lot more.

How to prepare

Practice using vanilla JavaScript as well as your most familiar library. After using React, Angular, or Vue, many engineers often forget the browser APIs such as addEventListener, getElementById, and fetch. While it is possible to look up documentation during your interviews sometimes, your problem solving speed will be impacted and you risk not finishing in time.

1. Create a formatted input such as a phone input — Use HTML and vanilla JavaScript to listen and handle changes to the input element.
2. Create an animated progress bar — Use only CSS to animate progress change. Make the animations smooth if updates are called before the previous animation finishes.
3. Create an infinite scroll feed with pagination — Think of this as building the Twitter or Facebook UI. The feed should detect when scroll is near the bottom of the list and call an API to fetch more data. Feel free to mock the backend paginated API.

Data structures and algorithms

Prep 25 hours

As an engineer, companies expect you to be able to code. While I personally disagree that frontend engineers need to know paradigms such as greedy algorithms, dynamic programming, and discrete math by heart, most companies have at least one data structures and algorithms interview in their frontend interview process.

Depending on the company, some committees may allow an otherwise strong frontend candidate to progress with a mediocre algorithm interview. Others will reject everyone who did not pass.

The trick to passing these interviews is being fluent in data structures as well as identifying potential algorithms quickly. Most problems are variations of the same few underlying algorithms so it’s better to aim for deeper understanding of a few major variations rather than sheer quantity of problems completed. Make sure you practice using JavaScript too.

Commonly used data structures

1. Arrays — These are mutable lists in JavaScript. Helpful methods include concat, slice, splice, indexOf
2. Maps — 1:1 mapping of unique key to value, can be built with Map() or plain JavaScript object {}. Helpful methods include Object.keys(), Object.entries(), Object.values(), for (let key in obj) { ... }, {}.hasOwnProperty(). If you use a plain JS object, note that there are built-in prototype methods such as constructor that may interfere with your keys.
3. Stack — Last in, first out ordered data store, use an Array with push() and pop().
4. Queue — First in, first out ordered data store, use an Array with unshift() and shift().
5. Set — Check for uniqueness, Set() has methods that include has() and add(). Use Array.from(set) to convert to an array. Alternatively, use Map().
6. Tree or graph — Use JavaScript objects as nodes, pointers don’t exist in JavaScript.
7. Trie — Tree where nodes have many children nodes that could correspond to characters in the alphabet. Very useful for finding words or patterns such as anagrams, palindromes, and word search puzzles.

Commonly used concepts

1. Greedy algorithms —Make optimal local decisions until a full solution is found, i.e. knapsack problem, task scheduling
2. Dynamic programming — Build on previous solutions to find new solution, i.e. Fibonacci sequence calculation, array subset
3. Search and graph traversal — Traversing through nodes or arrays, i.e. binary search, depth first search (DFS), breath first search (BFS), Dijikstra’s shortest path, and topological sort

Algorithm Complexity

The different data structures and algorithms have widely different ways to access data. To compare the speed of each algorithm, a commonly used measurement is called the Big O notation which measures how many times each element is accessed. Refresh your memory with the Big O Cheat Sheet.

How to prepare

Leetcode is probably the best known online resource for practice. I highly recommend the paid Leetcode subscription for their solutions and company specific problems ranked by frequency. If you need a quick refresher on programming concepts, Cracking the Coding Interview is a good book to review. If you never had a formal computer science education or never taken an algorithms class, I suggest taking a full algorithm course online. It will help you understand the general problem solving techniques instead of memorizing solutions to specific problems.

• Opinionated list of Leetcode questions to cram —This is the minimum you should spend time on. The 19 problems should take about an hour each on average to study and complete depending on difficulty. I have been asked by various companies every problem in the “Cram Level 1” section and a few in the rest as well. If you don’t have much time to prepare, work through these, read the different solutions, and make sure you can solve them on your own in JavaScript.
• Curated list of top 75 Leetcode problems — This is a more expanded set that covers a bigger breath of topics. Even if you don’t have time to work through these problems, it’s helpful to read the prompt, think about how to solve it, and understand the approaches to different solutions.
• Leetcode Premium company specific questions — If you have more time to practice, go into the lists of questions for each company you are interviewing for and sort the list by frequency and work from the top down. All 5 of the problems listed under Square were asked during my interview in 2019, 3 of which were hard level problems that I could have better prepared for had I known about it. The Google and Facebook problems are pretty accurate too. The subscription pays for itself if you land a higher paying job.

Generally, most companies will ask 2 easy or 1 medium difficulty questions per interview. Hard questions are rare. You should aim to finish Leetcode medium problems in 20 mins and hard in 40 mins during your practice.

Tip #1: Be honest and let the interviewer know if you might have seen the problem before. It is very obvious to an experienced interviewer anyway. You should still go through the same steps as you would normally in explaining and solving the problem.

Tip #2: Always talk through the problem solving strategy first before coding. Start with the brute force case, then optimized solutions. Talk though the complexity in O(N) for all of them. Sometimes the interviewer is looking for a specific solution.

Tip #3: If you have no idea how to get to an optimal solution, quickly code the brute force solution and work on optimizing that. Be receptive to the interviewer’s hints.

Tip #4: If you don’t think you can finish the most optimized solution in the allocated interview time, mention this to your interviewer. They might ask you to code the most important part of the optimized solution first or complete a less optimized approach from start to finish.

Tip #5: When you are truly stuck during an interview, think out loud and list all the different data structures and algorithms you know. Sometimes the interviewer will drop hints when you list each one.

Async Programming and JavaScript Specifics

Prep 5 hours

Asynchronous programming is at the heart of JavaScript and code execution in the browser so a lot of companies now test for understanding of this fundamental concept. Many companies use an async problem in place of an extra algorithm based problem for frontend candidates as well. While good performance here can help your candidacy, a bad one will impact leveling potential. Most hiring managers think of async programming as something that can be learned, although it would take a strong algorithm performance to offset a weak interview here.

If you are struggling, Eloquent JavaScript has a great section about async.

How to prepare

Implement these in vanilla JavaScript:

1. Promise (WeWork 2019, Flatiron Health 2019)— Implement a Promise that accepts callbacks and executes them in the order they are chained with. For added challenge, implement one that allows parallel functions to execute and waits for all of them to finish. Do not use the built-in Promise.
2. EventEmitter (Jet.com 2019, TwoSigma 2019) — Create an event emitter object or class that can be subscribed to using callback functions according to the event name. When an event with a specific name is fired, all functions that were attached to that name should be executed. Each subscription can be unsubscribed as well. Do not use the built-in EventEmitter.
3. Throttle/Debounce (Google 2016, Jet.com 2019)— Create a function that limits the frequency of a function called within a specific time frame. Implement leading and trailing as well. Remember to cancel when the async function is no longer needed.
4. Chaining timeouts (Google 2016)— Given a list of functions and their respective timeouts, execute each function one after another after the previous timeout ends. Be sure to cancel the timeouts if the function is no longer needed. For added bonus, allow arrays of functions that run in parallel.
5. Function currying (Squarespace 2016, Jet.com 2019)— Write a counter that can be repeatedly incremented like add(1)(2)(10)(4) infinitely.

Data Manipulation

Prep 2 hours

Like the async programming section, you probably use these utility functions often but rarely implement from scratch. It’s a matter of dedicating a little bit of time to practice so your execution is perfect when it comes time for interviews. These are often used as phone screens.

How to prepare

Implement these Lodash functions in vanilla JavaScript and compare your solution to their source code on GitHub:

1. flattenDeep (Facebook 2019) — Given nested array of elements, remove the nesting so that all the elements are placed in a single array.
2. merge (Jet.com 2019) — Given two objects, merge all the keys from one object into the other.
3. map (Facebook 2019) — Given an array and a function, return the list of results from applying the function to each element in the array.

If you need more practice, try implementing other Lodash functions.

System Design

Prep 10 hours

This interview is the bread and butter of engineers who want to land a job at a senior level or above and also the most important technical interview for determining candidates’ leveling. Candidates that do well on the systems design interview can potentially land a level higher than what the years of experience entails. Similarly, a bad one will almost always result in a under-leveled offer or even rejection.

System design is about architecting scalable, performant, and maintainable systems given a set of requirements. Sometimes, the given requirements are meant to be vague in order to gauge candidates’ ability to deal with uncertainty. Other times, the requirements can be more stringent to see if candidates can work within certain constraints. It is also important to understand how people and processes work with these systems as well.

I’ve found that the best way to learn about frontend systems is to keep up with current technology by reading technical blogs and watching conference talks. I personally subscribe to React Status, Frontend Focus, and JavaScript Weekly. I’ve also attended in person and watched videos from Fluent, React Europe, React Amsterdam, JSConf Berlin, and Chrome Developer Summit. All of these conferences upload past talks onto YouTube for others to watch for free.

Frontend Systems

There are two different areas of focus in frontend systems interviews, design systems/reusable components and web app architecture. The design systems interview will ask you to architect a complex reusable component, usually popup tooltip or input forms that comprise of many simpler components. The web app architecture will ask you to create the frontend for a popular web app such as Twitter or Gmail. Often times, the conversation starts in one of these two areas and touch upon the other as well. Unfortunately, I have yet to find a good one stop resource for learning about these frontend topics so here’s a list of relevant information I’ve gathered over the years.

• Design Systems — There are so many examples of component libraries and design systems out in the wild. Read the principles behind these systems and why systems are made a certain way. Take note of the simplest pieces such as token values and atoms, how they build into more complex inputs and buttons, and put together to form a user interface.
• Atomic Design — Brad Frost is one of the first to coin the term for the hierarchies of reusable components in user interfaces. He recently wrote a lengthy but insightful book about design systems and the processes and talent necessary to maintain it in large organizations. This talk is a good high level overview of design system challenges.
• React as a UI Runtime — What does React do under the abstraction that their APIs provide? You are expected to understand what frameworks do and provide an informed opinion on how it compares to alternatives you are familiar with.
• Progressive Web Apps with React — A good frontend system in 2020 generally looks something like a PWA. This is a high level overview of the different parts of a PWA along with some code examples.
• The Cost of JavaScript — Addy Osmani explains web performance in a way that’s very easy to understand. This talk during PerfMatters Conference will give you a basic understanding of where frontend performance bottlenecks are and how to mitigate them.
• Creating an Accessibility Engineering Practice — In depth resource about why accessibility is important and how to build an app that supports it.
• Inside Look at Modern Web Browser —High level overview of what browsers do at each stage of the render pipeline, great for answering discussions about how browsers parse code and display information. There’s 4 parts to this series of blog posts.
• Metrics & Performance Budgets — How to create trackable goals around web performance. What does fast really mean?
• Adaptive Loading — Strategy for loading only what’s necessary for the current user interface and device type.

Backend Systems

As mentioned, some companies don’t have frontend interviews and may ask backend and infrastructure focused systems design interviews. These should give you enough breath of information to talk about systems beyond the backend APIs for frontend.

• Grokking the Systems Design Interview — Paid course on Educative that goes through popular types of systems. Content is pretty concise and covers enough information to sufficiently pass a full stack or backend leaning systems design interview. Well worth the $39 for a month of access to the platform or $79 for lifetime access to the course, especially if you in a time crunch.
• System Design Primer — Free resource on GitHub that covers a very wide breadth of topics as well as many popular types of systems. As a frontend or full stack engineer, you will probably not encounter topics beyond backend and databases.

Behavioral

Prep 2 hours

The behavioral interview is usually conducted by a manager to determine your level of expertise, culture fit, and career interests. This is also an opportunity for you to improve your candidacy profile by highlighting your own strengths against the needs of the team or the company as well.

Expertise

You will be asked indirectly about your current role and past roles by examples of projects and teams you have worked on. When talking about your previous experiences, try to give examples that are of the highest impact and scope. The hiring committee and hiring manager will take this feedback into account when determining potential level at the offer stage.

Typically levels correspond to stories like this:

• New Grad (L3)— “I helped my team ship the new checkout experience by building the new payment input components and address forms.”
• Junior (L4)— “I rebuilt the shopping cart page from scratch as part of the new checkout experience to improve user experience and performance by migrating away from our legacy code .”
• Senior (L5) — “I lead the project to deliver a new checkout experience by scoping the project with our product manager and breaking down the technical tasks with my team. I also helped coordinate cross-team technical dependencies and resource constraints with other leads as they came up during development.”
• Staff (L6) — “I advocated for the e-commerce wide effort to improve performance and lead the effort across our shopping experiences by identifying areas of improvements. I then worked with stakeholders on each team to explore possible projects and define goals. Across the projects that include creating a brand new checkout experience and optimizing product pages, we saw a 30% reduction in page load times and an overall conversion rate improvement of 10%.”

Culture Fit

At smaller companies, this is more of the Airport Test — “Would you want to be stuck in an airport with this person?”. Do you like the person and would the person get along with you and the rest your team?

At larger companies, especially ones with more objective hiring criteria, this becomes a negotiation and conflict de-escalation discussion. You will be asked about how you resolve disagreements with coworkers and receive difficult feedback. There are a few right answers to these questions and some companies seem to prefer certain ones over others — the more “tech bro” companies like Palantir and TwoSigma seem to prefer direct feedback while the “diversity focused” types like Airbnb and Stripe seem to prefer the negative sandwich feedback. It really depends on the interviewer’s personality and also the personality types that the company attracts.

Career Interests

What types of projects interest you? Is it building user interfaces, component libraries, or architecture optimizations? How much CSS and HTML do you want to write? How much or how little backend development do you want to be involved in? Do you like fast moving projects or a steady stream of work?

Where do you want to be for your career in the next few years? Do you want to take on a bigger scope of work? Are you interested in leading a team or managing people? Or is work life balance extremely important to you because of other obligations?

How to prepare

Put some thoughts into how you would answer these questions and what examples you would give.

1. Tell me a little bit about you and your past work experiences.
2. What are you looking for in your next role?
3. Tell me about a project that you are most proud of.
4. Tell me about a project that failed and what you learned from it.
5. Tell me about the best feedback that you’ve received.
6. Tell me about a time you received critical feedback and how you handled it.
7. What is your biggest strength?
8. What is an area of improvement for you?
9. Tell me about a time you disagreed with your peers or your manager.
10. Was there ever a time when you advocated for something few people believed in? How do you influence others and get buy-in?
11. Why do you want to work for company X?
12. What interests you about team Y?

Frontend Trivia

Prep 1 hour

Sometimes, companies ask a few quick frontend focused questions to gauge your level of comfort with frontend early on in the process. If you don’t know the answers to a few of them, it’s not really a big deal although more preparation is always better.

• Facebook — recruiter phone screen
• Spotify — technical phone screen
• Squarespace — online HackerRank test
• Airbnb — technical phone screen

This Frontend Interview Handbook has 3 sections, HTML, CSS, and JavaScript. It covers pretty much everything interviewers might throw at you. You can read over them to refresh your memory.

Company Specifics

It goes without saying that not every company looks for the same combination of technical and people skills. Always do some homework and research into what the interview entails and mentally run through the leaked problems.

Interviews

Some companies have special interviews.

• Netflix has a huge emphasis on culture so it is a requirement that the candidates review the Netflix Culture page and Reed Hasting’s thoughts on culture to formulate their own opinions to discuss during the interviews.
• Shopify has a Life Story interview where the recruiter interviews the candidate about their upbringing, background, and life details that don’t normally surface in an interview. It’s important to have a few stories prepared that showcase your life in a positive manner about family, friends, and colleagues.

Additional resources

• Glassdoor — great resource for getting more details about the interview process, offer timelines, and occasionally some leaked questions
• Leetcode forums — lots of detailed interview experiences here too, mostly larger companies like Microsoft, Facebook, Google, and Amazon
• Rooftop Slushie— platform where people pay current employees at specific companies to answer questions, some pretty good information about teams, culture, and leaked problem sets too
• Blind — anonymous tech oriented discussion app, some pretty juicy insider information about company culture and team dynamics. great for getting second opinions on your job offer and negotiations

Additional Resources

This Tech Interview Handbook is written and curated by the same person who put together the Frontend Interview Handbook. It has a lot of good information about resumes, application processes, offer negotiations, and general tech job hunting tips.

Closing Thoughts

Don’t get too upset if you can work through these exercises just fine but stumble during your actual interviews. Everyone’s been there, even many of the engineers you admire. Try practicing with a buddy and do mock interviews with each other using the same tools such as CoderPad, white board, and Zoom to simulate the actual interview environment as closely as possible.

Good luck with your interviews!

Overview

Translation is usually the most obvious step in localization (l10n) and internationalization (i18n) efforts where applications are adapted to fit the needs of users in specific regions or markets. It is also the most standardized process and most organizations follow similar processes with similar tools to get their frontend strings translated.

This guide focuses on translation and the content here is intended to connect the dots between various i18next library documentations while providing additional code required to get an app translated inside Create React App. I found that while many other guides exist, very few of them explain why certain processes or tools are required. I will try to provide the necessary context for both technical and user experience related decisions as well as internationalization best practices whenever possible. This guide assumes you have working frontend knowledge including JavaScript, React, NPM, etc. Full example code will be provided in a GitHub repo linked at the end.

Even though this guide targets Create React App, it should be applicable to most React apps. I will try to note the differences whenever possible. Please leave suggestions in the comments.

What this guide will cover:

1. Why i18next
2. Initial setup
3. Writing translations
4. User language and locale detection
5. Extracting strings for translation
6. Async load translated strings
7. Switching from one language to another
8. Pluralization
9. ICU JSON syntax validation
10. Fallback scenarios
11. Smartling processes for getting content translated

What this guide will not cover:

• Adapting visuals to different cultures and identities — People relate to products better when their identities are represented in photos and graphics
• Modifying content to suit the tastes of different markets — Humor and idioms don’t always translate
• Adjusting feature sets for different consumption habits — Some Europeans prefer SEPA direct debit over credit card payments
• Adapting designs and layouts to properly display translated text — German words can be very long, Chinese characters can be very dense, Arabic and Hebrew are read right to left
• Converting to local units such as currencies and units of measure — Most of the world do not use U.S. Dollars or inches
• Using proper local formats for date, time, addresses, and phone numbers — Some use 24 hour time, country and area code for phone numbers differ
• Adhering to local regulations and legal requirements — Cookies and user data are regulated by GDPR in Europe
• Technical infrastructure changes — Setting up servers and content delivery networks closer to users will give users faster access more reliability

Why i18next?

When I was looking for a set of translation tools for a project, I was measuring them based on a few criteria: ease of use, vendor integration, bundle size, feature set, and reliability. It should be easy to set up and use, cover almost all cases, and require little maintenance.

Available open source libraries:

1. Format.js — Library with extensive but relatively young ecosystem that does almost everything. Unfortunately, it has many quirks and unresolved edge cases with how the tools work together.
2. Globalize.js — Comprehensive library that covers every possible formatting need very well, leverages Unicode CLDR, but has very limited React integration and other tools
3. i18next — Good ecosystem of plugins and third party tooling, works with React well, supported from early jQuery days with minimal API changes
4. Polyglot.js — Lightweight but extremely limited library, does not support any standardized formats

The decision came down to Globalize.js and i18next. Globalize handles formatting very well but setup can be a pain and bundle size bloat from Unicode CLDR data negates the benefits. Most apps will also never require the advanced formatting that sets Globalize apart. i18next is more of a swiss army knife in that it does many things relatively well and is lightweight and intuitive to use.

Helpful i18next plugins:

1. i18next-react — full React support including <T> component, higher order component, hook, and render prop
2. i18next-browser-languageDetector — detect user language from browser or previously saved cookie and LocalStorage
3. i18next-parser — automate extraction of strings embedded within JavaScript code to a dedicated JSON file to submit for translations
4. i18next-http-backend — load translation strings dynamically to minimize initial bundle size
5. i18next-icu — support industry standard ICU JSON format for submitting and reading translations from tool vendors like Smartling. ICU JSON allows translators to specify different forms of pluralization, pair gendered nouns with the appropriate adjectives, and more advanced things of that nature.

Initial setup

In src/index.js in Create React App or wherever your app is initialized before React is called, initialize i18next and react-i18next following the official documentation.

Create a file called i18nextInit.js. I put this file under src/. Import this file in src/index.js so it runs when the app starts.

The initialization code is used to bootstrap plugins that can help detect language, load the desired language, and get the react-i18next connected to i18next.

Writing translations

Do not import the t() function directly from i18next

This sounds strange, but the t() from i18next operates outside of react-i18next and React component lifecycles. Strings will not translate if called before async translations are loaded and will not update if language is changed.

React hook

This is newest and probably easiest way if you use functional components.
Official hook documentation

import { useTranslation } from 'react-i18next';

const { t } = useTranslation();

t('key.something', 'This is the default English version of the string')

React component

This is more versatile and self contained, especially if the existing string was passed around in utility functions that don’t have access to t() any other way. Make sure a component can be rendered where the string was previously used.
Official component documentation

import { Trans } from 'react-i18next';

<Trans i18nKey="key.something">This is the default English version of the string.</Trans>

Higher order component and render prop

Official HoC documentation
Official render prop documentation

In src/App.js, I added an example of both but you can pick one or the other. Notice I hardcoded the number of apples in the string. We will pluralize it later. I added <React.Suspense fallback="loading"> to index.js as well because useTranslation can trigger suspense when the language strings are loading. You can turn this feature off if you’d like.

The translation functions rely on a set of translations for each defined locale. It will look up the translated string using the key provided in the function so these keys should all be unique. We will define the translated strings in a separate file later.

Tip 1: Use a different key for each string, even if the content of the string is the same. Take advantage of the hierarchy allowed by the . to split keys into smaller subgroups. “okay” can be used as “confirm” in a confirmation dialog or “average” in a survey and should have different translations. Rather than sharing okay as the key, it will be easier to manage for translators and engineers if this same string is split into something like confirmation.okay_button and engagement_survey.okay_satisfaction_rating.

Tip 2: Add context in the string key to reduce uncertainty in the meaning of each string. While it is possible to provide translator notes in other ways, I found it much simpler to include context in the key itself. As a translator, “Letter” with a key of print.letter can mean a few different things, but print.letter_paper_size makes it clear that this is a paper size and not a type of document or an individual character. It is also helpful to include information about the type of interface the string is used in such as button, tooltip, and alt tags as well.

Tip 3: Avoid using abbreviations as much as possible. “PB&J Sandwich” may not mean much to translators in other countries. Some may choose to keep the abbreviation in their translation while others will request additional context and translate that. It would be easier to write out like “peanut butter and jelly sandwich” instead.

Tip 4: Do not split up phrases or sentences. If certain portions of a phrase need to be stylized, it would be better to highlight the whole phrase instead of individual portions. <b>t("Do not split")</b> t("the sentence up like this") ,<b>t("Instead emphasize the whole thing")</b>. Often times in other languages, syntax order is different and stylizing certain portions would be almost impossible — *Do not* the sentence *split* up like this. Same for specifying things like Blood type: O. It would better to allow the translator to place variable like "Blood type: {bloodType}" instead of "Blood type: " + bloodType so translators have the flexibility to rearrange words and numbers according to local customs.

User language and locale detection

In order to provide a good translated experience, an app should try to automatically figure out the user’s preferred language without prompting the user. The browser API window.navigator.language is probably the easiest, most reliable, and well-supported way.

i18next-browser-languageDetector plugin takes care of reading from window.navigator.language as well as maintaining any language selection in the browser cookie and LocalStorage. If the initially detected language is not preferred one and the user changes the language, the plugin will automatically persist that change for next time.

We need to chain the browser detection library to i18n to let it initialize together. langDetectorOptions is a set of optional parameters for tweaking the default behavior. For the purpose of this guide, we use en, zh, es as our 3 languages and we need to provide this in the whitelist has a list to pick from.

Don’t worry if your languages are actually locales with country codes like en-US. i18next will approximate 2 letter language codes to 4 letter locale codes like en to en-US and vice versa.

Official documentation

Tip 5: Try to create region-specific translations whenever possible if your budget allows, especially for those your app is specifically targeting. Swiss German has different idioms and syntax patterns than German Standard German. Chinese readers struggle between the simplified characters used in Mainland China and the traditional characters used in Taiwan, Singapore, and Hong Kong. Even with languages that have a lot in common such as American English and British English, users will feel much more comfortable reading their own localized language. Automated tools for these also exist.

Extracting strings for translations

We can use i18next-parser to extract the strings that are embedded in our JavaScript into a dedicated JSON file that we can then submit to Smartling or other vendors for translation.

In the root project directory, create i18next-parser.config.js. The file output location is changed because Create React App only allows imports from within the src/ directory.

Run extraction by calling npx i18next-parser.

This should generate a file src/locales/en.json with the strings you’ve previously created. I took the liberty to manually create es.json and zh.json as well for demonstration purposes. We can then add the content of those locale files to i18next in the initialization code. JSON webpack imports are built-in for Create React App. You may need an additional webpack plugin otherwise.

At this point, you can try viewing other languages by manually setting the locale cookie.

Official parser documentation

Note that sometimes this extraction library doesn’t always pick up all the translations. There are some edge cases with the <Trans> component as well as the t() where you may need to try a different syntax or calling inside a different function or file for it to work. I don’t recommend using this parser in a fully automated script.

Async load translated strings

This is more or less a hack because i18next doesn’t support async loading locales from webpack bundle splitting. Only recent versions of webpack support async imports.

String text can make up a significant portion of the total app bundle size, especially if many languages are involved. Loading only the required language can speed up page loading significantly.

The i18next-http-backend is built for loading language JSON from static folders. It is not only inconvenient to copy translations files every time, but also tedious to implement cache invalidation for every update. Instead, we can leverage webpack and the import() promise to create language bundles that can be served alongside existing JavaScript. The plugin’s async fetch behavior can be overridden to load from promises.

In localeBundles.js, we create a list of async imports and generate a list of supported languages from those. We then write a helper function loadLocaleBundle in i18nextInit.js to select the right bundle to load and optionally always bundle a default fallback language. In backendOptions, we override the default behavior of request to load from import() promises instead of URLs and we get the language requested by overriding the loadPath so it could be parsed in request easier.

You should now see an additional request being made for your selected locale.

There should really be a backend plugin that takes in a list of async imports. Please steal this idea and open a PR against i18next!

Official HTTP backend documentation

Before anyone calls out the other million ways to split bundles by locales, I want to emphasize the simplicity of this solution. This does not require any webpack config changes or infrastructure changes necessary to serve static locale files.

Switching from one language to another

What if you don’t want a hard refresh for users when changing locales? Fortunately, react-i18next supports dynamic language changes and updates existing translations after a new language is finished loading.

Do not import the i18n object directly from i18next

Again, i18next falls outside of the React component lifecycle and will not trigger the appropriate updates to translate and render the changed components.

We add a button to cycle through the 3 different languages we have configured. We then add the I18nextProvider to the root of our rendered app so it can propagate language changes to the children. The i18n object as a method i18n.changeLanguage to change language as well as information about current language i18n.language.

Tip 4: If you have components or APIs inside your app that requires locale information such as third party payment widgets, make sure you get i18n.language through one of the React methods and not directly from i18next import. Otherwise, the third party component will not change language when requested and you end up with partially translated pages.

Pluralization

Why do I have to worry about pluralization?

Different languages have varying degrees of pluralization and different sets of rules for plurals.

English

• First form: for 1
• Second form: for all other

Arabic:

• First form: for 0
• Second form: for 1
• Third form: for 2
• Fourth form: for numbers that end with a number between 3 and 10 (like: 103, 1405, 23409).
• Fifth form: for numbers that end with a number between 11 and 99 (like: 1099, 278).
• Sixth form: for numbers above 100 ending with 0, 1 or 2 (like: 100, 232, 3001)

ICU Plural MessageFormat

I chose to use the ICU JSON format for a few reasons. Most translation vendors support this format so there is no TMS vendor lock-in. ICU JSON supports multiple forms of plural as well as variations of phrases for masculine and feminine forms of words in certain languages. These functionalities are self contained in a single string so it works with i18next-parser out of the box.

The i18next JSON format also supports multiple forms of plural but it uses a new key for each plural form. Key additions are not an ideal solution because it is only supported by a single TMS vendor, Locize.

Since this guide is in English, I will only cover how to create the 2 English plural forms, singular and plural. The other forms for other languages should be generated by your translation vendor after strings have been translated. We will also need to provide the corresponding ICU locale data in the app for i18next-icu format plugin so strings can be formatted properly in our app.

Simple plural example in English

You have 0 credits remaining.

You have 1 credit remaining.

You have 2 credits remaining.

t(“key.credits_remaining_warning”, { defaultValue: “You have {numCredits, plural, one {1 credit} other {{numCredits} credits}} remaining.”, numCredits: x }};

Plural example with special case for zero in English

Play this game for free.

Play this game for 1 credit.

Play this game for 2 credits.

t(“key.play_for_credits_prompt”, { defaultValue: “Play this game for {numCredits, plural, 0= {free}, one {1 credit} other {{numCredits} credits}}.”, numCredits: x }};

Multiple plurals example in English

Smartling and some other translation management software vendors do not support multiple plurals in a single string even though it is part of the ICU MessageFormat standard. We can get around this by creating 3 separate strings, 2 for each plural form, and 1 for the sentence.

Adam has 2 apples and Betty has 1 orange.

Adam has 1 apple and Betty has 2 oranges.

Adam has 2 apples and Betty has 2 oranges.

const adamsApples = t(“key.apples”, { defaultValue: “{numApples, plural, one {1 apple} other {{numApples} apples}}”, numApples}}; // 1 apple, 2 apples

const bettysOranges = t(“key.oranges”, { defaultValue: “{numOranges, plural, one {1 orange} other {{numOranges} oranges}}”, numOranges}}; // 1 orange, 2 oranges

t(“key.apples_and_oranges”, { defaultValue: “Adam has {adamsApples} and Betty has {bettysOranges}.”, adamsApples, bettysOranges }}; // complete sentence

Masculine and feminine forms

I’m going to skip over this one because it is easier to rewrite the phrase to avoid using pronouns altogether. Creating a system in place to save and render gender information for properly conjugating phrases is not worth the effort. In addition, gender is also not binary in certain parts of the world as well.

Gendered:

He/she needs additional time.

Gender neutral:

The customer needs additional time.

For those intellectually curious, gendered forms can be created using the select function from ICU Message Format.

We can create another toggle button in App.js that will cycle a variable between 0–3. In the t() function, we can pass in an object with the translation string as defaultVariable and other keys as replacement variables. This will give us a way to test pluralization with different quantities.

We also need to provide the ICU formatter plugin for i18next as well as the associated formatting data for each language. The formatting data is relatively small so it is probably not worth the effort to bundle split.

ICU JSON syntax validation

The ICU JSON format is not the most straightforward format to read and write manually. i18next-icu also crashes when there is a syntax error in the translation string. We can reduce the number of syntax errors and mistakes by using eslint-plugin-i18n-json to scan all of the translations.

I created a .eslintrc.js file in the src/locales directory to specifically target translation json files with root=true to avoid inheriting the project config. I also turned off sorted-keys because it conflicts with the i18next-parser order and generates merge conflicts.

Run npx eslint src/locales/*.json to validate your translation syntax.

Tip 6: In your tests or prepush git hook, you can add the extract and validate scripts to make sure all translation changes have been extracted and that the syntax is correct.

Fallback scenarios

In the case that a translation is not available in a certain language or the additional bundles do not load for whatever reason, i18next has a series of fallbacks the app can rely on to display something meaningful to the user.

Here’s the order of precedence for language matching as defined by the whitelist:

1. Exact match of language or locale code requested: es to es
2. Nearest match of language or locale code: es-MX to es and vice versa
3. Fallback language defined in init(): fallbackLng: 'en'

The order is similar for individual translation key lookup:

1. Exact or nearest match of language or locale
2. Fallback language
3. String provided as defaultValue for the translation function

Tools and processes for getting content translated

Getting the right tools and implementing a smooth process can make the overall translation much less painful. This is more important the larger your organization is. A new startup may choose to have internal staff translate the JSON files directly and avoid additional tools and vendors as well.

Translation Management System

You will need a translation management system (TMS) to process the original strings, allow translators to input their translations in different formats, check for quality, and output translations in a form engineers can use. The system will typically also save previous translations and match new ones against those as well.

I’ve only had extensive experience with Smartling. Other systems include XTM and Transifex.

Smartling Pros:
It seems like this is a popular choice among smaller tech companies. Their cost is fairly reasonable and the interface for managing translations works as intended. The software seems to be designed for non-technical people who are involved in internationalization, namely the translators and program administrators. Single sign on support and cost previews are helpful as well.

Smartling Cons:
Their developer-facing tools rarely get updated and technical support is almost nonexistent. Smartling GitHub Connector is inflexible and a pain to use. Current PRs must be kept open for translations to be added back in and there is always a risk of merge conflicts. Their API documentation leaves a lot to be desired as well.

A typical translation process for Smartling looks like this:

1. Write the translation in code
2. Extract to JSON file
3. Commit changes and push to GitHub
4. Open PR for Smartling GitHub Connector to pick up translation
5. Keep PR open until Smartling GHC opens another PR against the existing PR branch to merge translations in
6. Resolve any merge conflicts and then merge

Translators

Now that you have a system to manage translations, you will also need someone or something to actually translate.

• In-house translators — Product support specialists and product owners who work in other languages are great candidates since they understand your product and typically require less context. They will require training so consider the opportunity cost vs. hiring external vendors.
• Third party translators — Hiring professional third party is a good choice if your budget allows. RWS Moravia and Eriksen are two I’ve worked with in the past. It usually takes about a couple business days for strings to be translated and returned back.
• Machine translators — This is similar to using Google Translate across your app where the translation might not always make sense. There is an emerging trend to temporarily use machine translations when human translations are not yet available. Machine assisted translations exist as well where a human translator proofreads and edits machine translations.

Once your translators are added to the translation management system, you are ready to begin the process of translating your app!

What’s next?

As mentioned earlier, there are many more steps to properly internationalize and localize an app, many of which are a combination of technical and non-technical tasks. Translating an app alone will only bring limited success if the app features aren’t adapted to other markets. Take some time to review the list of topics not covered and see which ones are important to your product. This guide is already long enough so I will leave you with just a few more things to consider.

Date and time formatting

If you find yourself translating anything date or time related, even if the phrases are simply days of the week or months, consider using a library instead.

Human readable relative time — A few seconds ago

Duration — 2 hours

• moment.js — mature full feature library that can do everything, comes at a very large bundle size
• luxon.js — lightweight, relies on browser APIs, minor inconsistencies in older browsers from missing browser APIs
• date-fns — young and modular full feature library that uses browser APIs, pick and choose necessary functionality

Locale specific layout and design changes

Some languages such as German have longer words that may not fit in your English layout. A common pattern to detect these visual defects is to programmatically generate a test language that is 2x longer than the English phrase with a minimum word length of 10–15 characters and manually review each interface.

Languages in other regions of the world may not have the same typography attributes found in European languages. East Asian text is typically illegible under 12px font size on low resolution screens. Letter spacing cannot be applied to languages such as Arabic where characters are connected. Language specific customizations like these can be applied by adding thelang to HTML elements and styling using the :lang() CSS selector.

Fully supporting right to left language is a huge pain because users prefer having their entire layout horizontally flipped. Fortunately, there are tools like PostCSS-RTL that will programmatically generate a set of CSS styles that has all horizontal styles flipped.

Example code

As promised, here’s the final app with all the steps combined. Feel free to fork or copy. Happy translating!

danielduan/i18next-create-react-app

Many thanks to all the people at Squarespace and WeWork who helped me learn about internationalization from the ground up. Please leave comments and suggestions.