Mastering Frontend Interviews: 10 Essential Concepts Every Developer Should Know

Frontend development interviews can be daunting, particularly with the breadth of topics covered. From JavaScript fundamentals to performance optimisation, demonstrating a solid grasp of key concepts is crucial for success. Whether preparing for your first interview or refining your expertise, here are ten essential areas to focus on.

1. The JavaScript Event Loop

Understanding how JavaScript handles asynchronous operations is critical. The event loop enables non-blocking execution, managing tasks from the call stack and the message queue. Be prepared to explain how it works and how concepts like microtasks (Promises, MutationObserver) and macrotasks (setTimeout, setInterval, I/O) differ.

Interview Tip

• Explain what happens when setTimeout(fn, 0) is called.
• Discuss the difference between synchronous and asynchronous execution.

2. Closures and Scope

Closures allow functions to retain access to variables from their lexical scope, even when executed outside their original context. This is fundamental to JavaScript’s behaviour.

Interview Tip

• Be ready to demonstrate how closures work with an example.
• Explain real-world use cases like memoization and data encapsulation.

3. Performance Optimisation Techniques

Frontend performance impacts user experience and SEO. Key areas to focus on include:

• Lazy loading to improve initial page load times.
• Debouncing and throttling to optimise event listeners.
• Minification and tree shaking to reduce bundle size.
• Optimising critical rendering path for faster paint times.

Interview Tip

• Explain how to improve performance in a React or Vue application.
• Discuss how content delivery networks (CDNs) help optimise page speed.

4. CSS Specificity and Inheritance

Understanding how browsers determine which styles apply is fundamental to writing maintainable CSS.

Key Concepts

• Specificity calculation (inline styles > IDs > classes > elements).
• Cascade rules and inheritance.
• Avoiding !important and deeply nested selectors for maintainability.

Interview Tip

• Be prepared to debug a conflicting CSS rule.
• Explain how CSS variables (--custom-prop) work and their advantages.

5. The Virtual DOM and Reconciliation

For frameworks like React, the Virtual DOM enhances performance by minimising direct manipulations of the real DOM. React’s diffing and reconciliation algorithm determines what updates need to be applied efficiently.

Interview Tip

• Explain how React updates the UI when state changes.
• Discuss why reconciliation is faster than direct DOM manipulations.

6. Security in Frontend Development

Web security is crucial, and understanding common vulnerabilities can set you apart.

Key Topics

• Cross-Site Scripting (XSS) – Prevent through input sanitisation and Content Security Policy (CSP).
• Cross-Site Request Forgery (CSRF) – Mitigate with CSRF tokens and SameSite cookies.
• Clickjacking – Protect with X-Frame-Options headers.

Interview Tip

• Explain how to prevent an XSS attack in a React or Angular application.

7. Responsive and Accessible Design

Modern web applications should work seamlessly across devices and be accessible to all users.

Key Concepts

• CSS Flexbox and Grid for responsive layouts.
• ARIA attributes for better accessibility.
• WCAG guidelines for an inclusive user experience.

Interview Tip

• Demonstrate how you’d make a button accessible to screen readers.
• Explain the difference between rem, em, vh, and vw units in CSS.

8. State Management in Modern Applications

As applications grow in complexity, managing state efficiently becomes crucial.

Key Approaches

• Local state (useState, useReducer in React).
• Global state (Redux, Zustand, Vuex, Pinia).
• Server-state management (React Query, SWR).

Interview Tip

• Compare Redux vs. React Context for state management.
• Explain when to use client-state vs. server-state solutions.

9. Web APIs and Browser Storage

Understanding browser capabilities and client-side storage methods can be useful in interviews.

Key APIs

• Fetch API vs. Axios for handling HTTP requests.
• LocalStorage, SessionStorage, IndexedDB for data persistence.
• Service Workers and the Cache API for progressive web apps (PWAs).

Interview Tip

• Implement a simple API call using Fetch and handle errors gracefully.
• Explain the differences between cookies, localStorage, and sessionStorage.

10. Testing Frontend Applications

Testing ensures code reliability and maintainability.

Key Testing Methods

• Unit testing (Jest, Mocha, Vitest).
• Component testing (React Testing Library, Vue Test Utils).
• End-to-end testing (Cypress, Playwright).

Interview Tip

• Explain how to test a React component with Jest and React Testing Library.
• Discuss the importance of mocking API responses in tests.

Final Thoughts

Frontend interviews often require both theoretical knowledge and practical implementation skills. By mastering these ten essential topics, you’ll be well-prepared to tackle a variety of challenges with confidence. Stay up to date with modern web trends, practice coding exercises, and approach interviews with a problem-solving mindset. With the right preparation, you’ll be in a strong position to excel.

Writing Effective Design Docs: Steering Your Team as a Principal or Staff Engineer

 As a Principal or Staff Engineer, one of your key responsibilities is guiding technical direction across teams. While code speaks volumes, clear design documentation is often the bridge between ideas and execution. A well-crafted design document (design doc) ensures alignment, reduces unnecessary debates, and helps teams move forward with confidence.

But writing a great design doc isn’t just about capturing technical details—it’s about driving clarity, collaboration, and decision-making. This guide explores how to write effective design docs and how they can help you steer your team in the right direction.

---

Why Design Docs Matter

Design docs serve several critical functions:

✅ Aligning Teams Early – They help ensure everyone understands the problem, the proposed solution, and any trade-offs before work begins.
✅ Encouraging Thoughtful Design – Writing forces engineers to articulate their ideas clearly and consider alternatives.
✅ Reducing Unnecessary Rework – Addressing key questions upfront prevents wasted effort on incorrect or inefficient solutions.
✅ Creating a Historical Record – They provide a reference for why decisions were made, helping future engineers understand past choices.

For Principal and Staff Engineers, design docs are a tool for influence—they allow you to shape decisions across multiple teams without micromanaging.

---

What Makes a Good Design Doc?

A design doc should be clear, concise, and structured. While formats vary, a strong design doc typically includes:

1. Title & Summary

Keep it brief but descriptive. A good summary should answer: What is this document about, and why does it matter?

➡️ Example:
Title: Scaling the Authentication Service for 10M Users
Summary: This document outlines a plan to refactor our authentication service to handle a 10x increase in traffic while maintaining low latency.

2. Context & Problem Statement

Explain why this design doc exists. What problem are you solving? Why does it matter?

➡️ Example:
"Our authentication service currently handles 1M active users. As our product scales, the current architecture will struggle due to bottlenecks in session management. Without changes, we risk increased latency and service failures."

3. Goals & Non-Goals

Define the objectives and also what’s out of scope to prevent scope creep.

➡️ Example:
✅ Goals: Improve authentication performance to handle 10M users with <100ms response time.
❌ Non-Goals: This proposal does not cover authorisation changes or UI enhancements.

4. Proposed Solution

Describe your approach, balancing technical depth with readability. Use diagrams if needed.

✅ Break it down logically:

• How does the new design solve the problem?
• What are the main components?
• What technologies or frameworks are involved?
• How does it compare to alternatives?

5. Trade-offs & Alternatives Considered

No design is perfect. Acknowledge trade-offs and explain why you made specific choices.

➡️ Example:

• Option 1: Horizontal Scaling (Chosen Approach) – Pros: Better fault tolerance. Cons: More complex load balancing.
• Option 2: Caching Layer – Pros: Faster reads. Cons: Doesn’t solve write-heavy traffic issues.

6. Risks & Mitigation Strategies

Highlight potential failure points and how you plan to address them.

➡️ Example:
Risk: Increased database load due to higher concurrent logins.
Mitigation: Introduce rate limiting and optimise database indexing.

7. Rollout Plan & Timeline

Describe how the change will be implemented safely and incrementally.

✅ Phased rollout example:

1. Deploy a shadow system for read-only testing.
2. Migrate 10% of traffic to the new service.
3. Scale up gradually while monitoring performance.

8. Success Metrics

Define how you’ll measure success.

➡️ Example:

• Authentication latency remains under 100ms at 10M users.
• Error rate stays below 0.01%.

9. Open Questions

If there are unresolved aspects, list them for discussion.

➡️ Example:

• Should we introduce a new authentication protocol now or later?

---

How Design Docs Help You Steer Your Team

As a Principal or Staff Engineer, you can’t be in every meeting or review every pull request. Instead, you influence through design docs by:

1. Providing Technical Direction Without Micromanaging

A well-structured design doc empowers teams to make informed decisions without needing constant oversight.

2. Creating Alignment Across Teams

Design docs facilitate asynchronous collaboration, allowing cross-functional teams to review, give feedback, and resolve disagreements upfront.

3. Elevating Engineering Quality

By promoting thoughtful design discussions, you reduce rushed or poorly planned implementations, leading to more robust and scalable solutions.

4. Training Future Technical Leaders

Encouraging mid-level engineers to write design docs helps them develop technical leadership skills, ensuring a strong engineering culture.

---

Best Practices for Writing and Reviewing Design Docs

✅ Keep it concise – Avoid unnecessary details; focus on what matters.
✅ Make it accessible – Use simple language and diagrams where helpful.
✅ Encourage feedback – Share it early for input from peers and stakeholders.
✅ Revise as needed – Design docs are living documents; update them as plans evolve.

---

Final Thoughts

Writing effective design docs is a core skill for Principal and Staff Engineers. It’s not just about documenting ideas—it’s about steering teams, aligning stakeholders, and ensuring long-term technical success.

By mastering design documentation, you increase your impact beyond coding and help your organisation scale with clarity and confidence.

What’s your approach to writing design docs? Share your thoughts in the comments! #EngineeringLeadership #DesignDocs #TechnicalStrategy

The Hidden Costs of Slow TCP Handshakes: How to Optimize for IPv6 Performance

In the world of network performance, milliseconds matter. A slow TCP handshake can degrade user experience, increase latency, and even impact business revenue. While IPv6 adoption continues to grow, optimising its performance remains a challenge—one that requires a deep understanding of how TCP handshakes function and how inefficiencies can creep in.

Understanding the TCP Handshake in IPv6

TCP (Transmission Control Protocol) establishes reliable connections using a three-way handshake:

1. SYN – The client sends a synchronisation (SYN) request to the server to initiate a connection.
2. SYN-ACK – The server acknowledges the request and responds with a synchronisation-acknowledgement (SYN-ACK).
3. ACK – The client acknowledges the server’s response, and the connection is established.

This process is fundamental to communication over the web, but when it becomes slow, the effects cascade across an entire system, impacting everything from page load times to API responsiveness.

Why Are TCP Handshakes Slower on IPv6?

IPv6 was designed to address the limitations of IPv4, offering a vastly expanded address space and improvements in routing efficiency. However, the transition from IPv4 has introduced some challenges:

1. Larger Packet Headers

IPv6 headers are 40 bytes, compared to IPv4’s 20 bytes. While this design supports more flexible routing, it adds processing overhead, especially in environments with heavy packet filtering or deep packet inspection.

2. Path MTU Discovery (PMTUD) Issues

IPv6 relies on Path MTU Discovery (PMTUD) to determine the maximum transmission unit (MTU) without fragmentation. However, network misconfigurations or overly restrictive firewalls can block ICMPv6 messages, leading to delays as TCP retries different packet sizes.

3. Happy Eyeballs and Fallback Delays

Many systems implement the Happy Eyeballs algorithm, which attempts both IPv4 and IPv6 connections simultaneously, prioritising the faster response. If IPv6 is slow due to network inefficiencies, users may experience delays before falling back to IPv4.

4. Suboptimal Routing and Peering

IPv6 routing paths may be less optimised than their IPv4 counterparts, leading to higher latency. ISPs and data centres have not always invested equally in IPv6 infrastructure, causing inconsistencies in network performance.

5. TLS Overhead

Modern applications often use TLS encryption, adding another layer to the handshake process. While IPv6 itself does not inherently slow TLS, poor IPv6 configurations can compound handshake delays.

How to Optimise TCP Handshakes for IPv6 Performance

While IPv6-related TCP handshake latency is not entirely avoidable, there are several key optimisations that can significantly reduce delays.

1. Enable and Monitor TCP Fast Open (TFO)

TFO allows clients and servers to send data during the handshake rather than waiting for it to complete. Enabling TFO can reduce round-trip times (RTTs), improving responsiveness. However, it must be carefully tested, as some network configurations may drop TFO packets.

2. Optimise MTU and Ensure ICMPv6 Is Unblocked

Configuring MTU properly and ensuring ICMPv6 packets are allowed can prevent performance degradation due to failed PMTUD. The recommended approach:

• Set the MTU to 1,500 bytes if supported.
• Ensure ICMPv6 messages, particularly Packet Too Big, are not blocked by firewalls.

3. Monitor and Optimise IPv6 Routing Paths

To reduce routing inefficiencies:

• Use traceroute6 or mtr to check IPv6 paths.
• Work with ISPs and cloud providers to optimise peering relationships.
• Prefer content delivery networks (CDNs) with robust IPv6 support.

4. Reduce TLS Handshake Overhead

If using TLS 1.3, ensure session resumption and 0-RTT (Zero Round Trip Time Resumption) are enabled to decrease handshake delays. Minimising unnecessary round-trips during secure connections can significantly enhance performance.

5. Implement IPv6-Specific Performance Testing

Regularly test IPv6 handshake times using tools like:

• Wireshark to inspect packet exchanges.
• curl -6 --verbose to check response times over IPv6.
• Google’s IPv6 Speed Test to compare IPv4 and IPv6 latencies.

Final Thoughts

A slow TCP handshake over IPv6 is more than just a technical nuisance—it can lead to real-world performance bottlenecks. By proactively addressing common pitfalls such as inefficient routing, blocked ICMPv6 messages, and handshake overhead, teams can ensure that IPv6 adoption brings its intended benefits rather than unnecessary slowdowns. Investing in IPv6 performance today will pay off as more of the internet transitions away from IPv4, making seamless, low-latency connections the new standard.

Monorepos vs. Polyrepos: The Ultimate Guide for Scalable Frontend Development

In the ever-evolving world of frontend development, the choice between monorepos and polyrepos can significantly impact scalability, collaboration, and maintainability. While both approaches have their merits, selecting the right one requires a clear understanding of their strengths, weaknesses, and the contexts in which they thrive.

Understanding Monorepos and Polyrepos

Monorepos: A Unified Codebase

A monorepo is a single repository that houses multiple projects, often sharing dependencies, tooling, and configurations. This approach is widely adopted by large-scale engineering teams as it promotes consistency and reusability across projects.

Advantages of Monorepos

• Centralised Dependency Management – Shared libraries and dependencies are easier to maintain, ensuring uniformity across projects.
• Atomic Changes – Updating multiple projects simultaneously is more straightforward, reducing compatibility issues.
• Better Code Reusability – Shared components and utilities are naturally encouraged within the repository structure.
• Consistent Tooling and Processes – Teams work with the same linters, build tools, and CI/CD pipelines, reducing cognitive overhead.
• Enhanced Collaboration – Changes made to shared libraries are immediately visible, leading to better communication and fewer integration issues.

Challenges of Monorepos

• Tooling Complexity – Large monorepos require sophisticated tools (e.g., Nx, Turborepo, Bazel) to maintain efficiency.
• Longer CI/CD Pipelines – Running tests and builds across multiple projects can slow down deployment processes.
• Access Control Limitations – Granular permissions can be more challenging to manage, as all projects reside in the same repository.

Polyrepos: Decoupled and Modular

A polyrepo approach involves maintaining separate repositories for different projects, services, or libraries. This is a traditional approach that works well for teams that require clear separation of concerns.

Advantages of Polyrepos

• Independent Deployments – Each project can be developed, tested, and deployed in isolation, reducing dependency conflicts.
• Simplified Security and Access Control – Teams can have dedicated repositories with finely tuned permissions.
• Focused Versioning and Release Cycles – Different projects can follow their own update and release schedules.
• Less Overhead for Small Teams – Managing smaller repositories with focused scope can be simpler, especially without the need for advanced monorepo tooling.

Challenges of Polyrepos

• Dependency Duplication – Without careful management, different projects may use diverging versions of the same dependency, leading to inconsistencies.
• Cross-Project Changes Become Cumbersome – Updating shared libraries across multiple repositories requires additional coordination.
• Fragmented Tooling – Teams may adopt different linters, build tools, and workflows, leading to inconsistency across projects.

Choosing the Right Approach for Scalable Frontend Development

The decision between monorepos and polyrepos hinges on several factors, including team size, project complexity, and long-term scalability needs.

When to Choose a Monorepo

• You have a large team working across multiple interdependent projects.
• Shared components and libraries are a core part of your architecture.
• You require atomic changes across projects to maintain stability.
• Your organisation has the capacity to adopt monorepo-friendly tooling and automation.

When to Choose a Polyrepo

• Your projects are largely independent and do not share much code.
• Teams operate autonomously with their own development and release cycles.
• You prioritise simpler repository structures with less overhead.
• Security and access control are key concerns, requiring repository isolation.

Hybrid Approaches: The Best of Both Worlds?

For some teams, a hybrid approach can provide the ideal balance. For example:

• A monorepo for shared UI libraries while keeping individual applications in separate repositories.
• A service-oriented architecture where frontend and backend services reside in distinct repositories but leverage package management tools (e.g., npm, Yarn Workspaces) to manage dependencies effectively.

Final Thoughts

There is no universal answer to the monorepo vs. polyrepo debate. The best choice depends on your team’s workflows, project scale, and operational constraints. While monorepos foster collaboration and consistency, polyrepos provide autonomy and flexibility. Whichever route you take, ensuring strong version control strategies, automation, and clear documentation will be key to maintaining a scalable and efficient frontend ecosystem.

The Archetypes of Staff Engineers: How to Excel and When Your Business Needs One

As engineering teams grow, so does the need for leadership that isn’t purely managerial. Enter the Staff Engineer—a senior individual contributor who shapes technical strategy, solves complex problems, and drives impact without necessarily managing people.

However, not all Staff Engineers operate in the same way. Their roles typically fall into distinct archetypes, each contributing to the organisation in different ways. Understanding these archetypes can help businesses decide when they need a Staff Engineer and guide engineers aspiring to grow into these roles.

Additionally, as engineers progress beyond Staff level, roles such as Staff+, Principal, and Distinguished Engineer offer increasing influence, from team-wide to company-wide technical leadership. Let’s explore how these levels align.

---

The Four Common Staff Engineer Archetypes

1. The Tech Lead – Guiding Execution

This archetype drives technical execution, ensuring projects are well-architected and delivered efficiently. They work closely with teams to set technical direction, review critical code, and remove roadblocks.

Signs You Need One:

• Engineering teams struggle with execution and technical direction.
• Projects are frequently delayed due to unclear architecture or lack of leadership.
• The team lacks a central figure to balance business priorities with technical feasibility.

How to Excel in This Role:

• Balance high-level technical vision with hands-on implementation.
• Prioritise effectively—know when to ship and when to refactor.
• Mentor engineers to raise the team’s overall execution quality.

⏩ Common at: Staff Engineer level, sometimes progressing into Principal Engineer

---

2. The Architect – Designing Scalable Systems

The Architect focuses on long-term technical strategy, ensuring that systems scale, remain maintainable, and avoid unnecessary complexity.

Signs You Need One:

• Your system is experiencing growing pains due to ad-hoc architectural decisions.
• There’s an increasing need for consistency across services and platforms.
• Engineers frequently reinvent the wheel instead of following shared patterns.

How to Excel in This Role:

• Stay hands-on enough to understand implementation challenges.
• Build pragmatic, scalable solutions rather than over-engineered abstractions.
• Communicate architectural decisions clearly, ensuring buy-in from teams.

⏩ Common at: Staff+ and Principal Engineer level

---

3. The Solver – Untangling Complexity

The Solver thrives on deep technical challenges—debugging mysterious failures, optimising performance, and solving the hardest engineering problems.

Signs You Need One:

• Your team frequently faces complex, high-stakes technical issues that block progress.
• There’s no clear owner for solving difficult debugging or performance challenges.
• Technical debt and deep system issues are piling up.

How to Excel in This Role:

• Dive deep into problems without getting lost in analysis paralysis.
• Document solutions to avoid repeated issues.
• Share knowledge to help the team develop stronger debugging and problem-solving skills.

⏩ Common at: Staff+ Engineer level, often progressing into Distinguished Engineer

---

4. The Right-Hand Engineer – Strategic Partner to Leadership

This archetype operates at the intersection of business and technology, working closely with executives and engineering leaders to align technical investments with company goals.

Signs You Need One:

• Engineering and business teams struggle to align priorities.
• You need a technical leader who can provide clarity to leadership without diluting technical realities.
• Scaling the organisation requires a mix of technical and strategic thinking.

How to Excel in This Role:

• Develop a deep understanding of business goals and constraints.
• Build trust with leadership by providing clear, actionable technical insights.
• Make strategic trade-offs that balance speed, quality, and scalability.

⏩ Common at: Principal and Distinguished Engineer level

---

Where Do Staff+, Principal, and Distinguished Engineers Fit?

As engineers progress beyond the Staff Engineer role, their influence expands:

• Staff Engineer – Focuses on guiding execution, resolving technical challenges, and influencing a single team or a few teams.
• Staff+ Engineer – An informal term covering late-stage Staff Engineers who are on the path to Principal, influencing broader technical areas.
• Principal Engineer – Operates across multiple teams, driving technical strategy and architecture at an organisational level.
• Distinguished Engineer – A rare, high-impact role with influence across the entire company, setting technical vision and solving problems at a global scale.

In many companies, Staff Engineers start by excelling in one of the archetypes above, while Principal and Distinguished Engineers often blend multiple archetypes, balancing technical depth with organisational influence.

---

When Does Your Business Need a Staff Engineer?

Not every company needs a Staff Engineer immediately, but as teams scale, having strong technical leadership without forcing top engineers into management becomes crucial.

You likely need a Staff Engineer if:
✔️ Your engineers lack a clear technical leader but don’t need another manager.
✔️ Large technical decisions are made inconsistently or without long-term vision.
✔️ High-impact technical challenges are falling through the cracks.
✔️ Your engineering team is scaling quickly, and architecture isn’t keeping up.

---

How to Become a Better Staff Engineer

If you’re already a Staff Engineer (or aspiring to be one), focus on these core skills:

• Influence Without Authority – You won’t always have direct reports, so you must earn trust and drive alignment through strong technical reasoning.
• Clear Communication – Great Staff Engineers make complex ideas understandable for both engineers and non-technical stakeholders.
• Technical Depth & Breadth – Balance deep expertise in specific areas with the ability to connect dots across systems.
• Mentorship & Knowledge Sharing – A great Staff Engineer elevates the entire team, not just their own work.

---

Final Thoughts

A great Staff Engineer isn’t just a senior developer who codes more. They are technical leaders who shape engineering excellence, bridge business and technology, and help teams execute at their best.

Whether you’re an engineer looking to grow into this role or a business deciding if you need one, understanding these archetypes can help ensure the right fit and maximise impact.

Which archetype resonates with you the most? Let’s discuss in the comments. #EngineeringLeadership #StaffEngineer #TechStrategy