Skip to content
🛡️ FREE Master Frontend Security · All 7 modules live · 100% free Start free →
Episode 36 54 minutes

Frontend at Meta with Evyatar Alush

Key Takeaways from our conversation with Evyatar Alush

Evyatar Alush

Software Engineer at Meta, Tel Aviv. Creator of EmojiPicker React and Vest, ex-Frontend Platform Lead at Fiverr

Señors @ Scale host Neciu Dan sits down with Evyatar Alush, software engineer at Meta in Tel Aviv and the creator of EmojiPicker React and Vest. Evyatar's path is one of the most unusual on the show: no degree, no high school diploma, learning JavaScript on Code Academy during military night shifts in a server room, then talking his way into Fiverr, scaling to frontend platform lead, and getting recruited into Facebook in 2019. From what Meta's frontend infrastructure actually looks like — Hack instead of PHP, Flow instead of TypeScript, Relay instead of Apollo, Sapling instead of Git, stacked diffs instead of pull requests — to why move fast and break things is dead, to why he writes his own libraries rather than pulling dependencies, this is the inside view almost nothing you know from outside prepares you for.

🎧 New Señors @ Scale Episode

This week, I spoke with Evyatar Alush, software engineer at Meta in Tel Aviv with over six years at the company. Before Meta he spent nearly five years at Fiverr, rising to frontend platform team leader. He's also the creator of EmojiPicker React, the most popular emoji picker for React with around 600,000 weekly downloads, and of Vest, the validation library that grew out of a Fiverr-branded project called Passable.

His route in is genuinely unusual: no degree, no high school diploma, and JavaScript learned on Code Academy during night shifts in a military server room because the shifts were boring and there was nothing else to do.

In this episode, we dig into how he bluffed his way into a team at Fiverr with a banner and a logo, what Meta's frontend and backend infrastructure actually looks like from the inside, why "move fast and break things" is over, how stacked diffs change code review, and why he'd rather own the context package on npm than depend on someone else's.

⚙️ Main Takeaways

1. He learned to code on night shifts because there was nothing else to do

The origin story, and it's about as far from a CS pipeline as it gets.

  • Where he started: Four years in the military, doing what he describes as DevOps for Windows infrastructure — mail and exchange servers, virtualization, storage.
  • The setup: Server rooms need someone present 24 hours a day in case of an emergency. "Night shifts were very boring. And I remember just deciding, well, I could just spend the time learning JavaScript, because what else do I have?"
  • The starting point: "I did not even finish high school." No engineering experience at all, and one month of Code Academy in 2012 or 2013.
  • Why frontend: "It was the path of least resistance. I'm dead serious." He had no idea how to install Python or get C# running. "When I wanted to do something with frontend and JavaScript, I could just open a Chrome tab, take an index.html file and an index.js file and things would just run."
  • What he misses: That simplicity. "I actually miss those days. It's not as simple today." You can still write those two files — "but you would not get an app approved this way."

2. The Fiverr interview he failed, and got hired from anyway

A very good story about persistence and a forgotten meeting room.

  • The application: A friend told him to apply. He sent in "my very experienced resume of one year" and heard nothing back at all.
  • What he did: Told the friend to go knock on HR's door and vouch for him. It worked.
  • The written test: A paper questionnaire of statistical questions. "I had no degree, I did not finish high school, I know nothing about mathematics — but apparently that part was okay, I guess."
  • The coding test: Build an infinite picture carousel in plain JavaScript, 45 minutes. "I had no idea how to build it. I had a vague idea."
  • The thing that saved him: They forgot about him. "They left me in the room for two hours. Nobody came to actually ask what I'm doing and if I'm still there." He watched people leave through the glass in the door, eventually wandered floors to find his interviewer, tapped him on the shoulder and asked if he was going to let him out.

3. Five years at Fiverr, from failed products to the systems he's known for

The trajectory, including a product with a beautifully absurd operational secret.

  • First team, Tigers: Financials — the payment page and payment system frontend, making sure every payment provider actually worked.
  • The failed product: Fiverr Print, where you'd take a logo from a designer and get it printed on a t-shirt or hat. Around 20 people a day used it. "It was so poorly integrated that during the night, our product manager would go download all the requests for those prints and then go to a third party printing website, make the design themselves and ship that to the customers." It was switched off after a few months.
  • Second team, Panthers: Communications — notifications, emails, in-app messaging. "How do you provide a good notification system that you do not bombard the user, but you also retain them in the system?"
  • The job he has no nostalgia for: Fixing Fiverr's email HTML. "You do everything with table layouts and you have only a subset of HTML and a subset of CSS. That's the part I don't have nostalgia for."
  • What came out of it: The in-app notification popup and drawer, then a full inbox — "just imagine a Facebook Messenger, a big chat application." EmojiPicker React was built for that inbox, alongside a toast system and a pile of utility libraries that became open source. "I found my niche there."

4. He got a team by ordering a banner and telling everyone his manager approved it

The best story in the episode, and there's a real lesson underneath it.

  • The problem: He wanted to move from product to infrastructure, but "there was no frontend infra team." The backend had one; frontend didn't.
  • The opening move: A six-page manifesto to the CTO, titled Unmask, on what needed to change.
  • What he got: Permission to join infrastructure directly under the head of platforms — but no team. "Frontend doesn't need an infrastructure team. They just need one person building all of the stuff."
  • The observation: He looked around the office at what every real team had in common. "All of the teams had an animal name. All of the teams had a big banner, printed and hung. So all I need to do is have an animal name and have a banner, that's it. And I will have a team."
  • The name: Front Ants. "Ants do infrastructure, they go on the ground, and Front Ants sounds very nice."
  • The execution: He asked an internal designer for a team logo. "Does your manager approve that? Yeah, of course." He took the PDF to the operations team to be printed as a banner — "You got your manager's approval? Yeah, of course I have it." Then facilities, to hang it above his desk, with the same answer.
  • The result: "Believe it or not, two weeks later, I have two employees working with me." His own note on the approval question: "Technically, yeah, I'm the manager of the team. I approve — even though I wasn't."

5. Micro frontends bridging a Rails monolith, with type-safe routes across the boundary

The infrastructure work he's proudest of at Fiverr.

  • What they built: An internal server-side rendering setup for React on Node, resembling what Next.js became — but Next didn't yet have the features Fiverr needed.
  • The requirements: Shared layout components, multiple frontends that worked with their microservice architecture and domain-driven design, and clean boundaries between teams.
  • What made it hard: "A shared layout that's coming from one service, rendering a React page coming from another service, and actually making it all work together" — plus interoperability with a legacy Ruby on Rails app.
  • The problem he singles out: Links. Inside the monolith you get autocompletion for routes; inside a separate React package or Node service you get nothing.
  • The fix: A tool that exposed every Ruby on Rails named route as constants consumable from React applications on Node services. "You could say, I'm going to the orders page — and somehow it would go to the correct orders route in the Ruby application, even though it's nested or even though it was moved to a V2 or V3 URL route."

6. He said no to Facebook, and two people talked him out of it

The recruitment story, which nearly didn't happen.

  • The email: A recruiter who'd noticed he had no degree "which I think is a good thing, because it means that you work out of passion," and who had actually looked at his GitHub contributions.
  • His answer: No. "I was really comfortable where I'm at." He went home proud of having turned Facebook down.
  • His wife's response: "Are you stupid? Go back and apologize to them."
  • His HR manager's response, the next day: From an ex-Google HR lead — "You don't say no to a company like that. You go, you say yes. You see what they have to offer and then you decide. And I know you'll decide you don't want it, because I don't think it's a good company for you. But you just say yes."
  • What he wrote back: "Maybe I was too eager to say no. Maybe we should talk again."

7. The Meta interview loop, including the one he completely blew

Concrete detail on what the process actually was, and what happens when you fail one round.

  • Screen one: A recruiter call with basic questions purely to establish he wasn't a fraud. "He asked me what data type is the DOM. Stuff that you would obviously know if you wrote 10 minutes of JavaScript in your life."
  • Screen two: An algorithmic JavaScript call. He'd done a month of LeetCode to prepare, having no CS background at all. "The biggest challenge for me was communicating it. He asked me what is the space and time complexity of that, and I did not even know how to answer that."
  • What sold him on the company: Being flown to London for the onsite. "We're sending you to London, not on your expense but on our expense. We're booking you a hotel for a weekend so you can go watch a game or do whatever." Flights, hotel, food, taxis. "If that's how they treat their interviewees" — and he notes friends interviewing in the US were flown business class.
  • The onsite: Three rounds. A JavaScript algorithmic test framed through real web fundamentals — "you don't deal with just a tree, the API could be a DOM tree." Then a frontend system design round on a whiteboard, with follow-ups on performance, caching, cache invalidation and race conditions, "to see how you think about it, not necessarily how well you code."
  • The lunch strategy: "I remember specifically trying not to eat beans," because the final round was with Dan Abramov. "The final boss of interviews." He ate lettuce and chicken breast surrounded by good food.
  • How it went: "I was crushed. I think I was starstruck a little bit and I failed the interview completely." He went home devastated.
  • What Meta did about it: Called a few days later. "All your interviews were good except from that one with that last guy, Dan Abramov. Is that because he's famous? Were you starstruck?" They scheduled a replacement round in Tel Aviv, he passed, and joined in 2019.

8. He didn't join Facebook — he joined the crypto wallet behind a badge-locked door

The unusual first couple of years.

  • The project: Calibra, later Novi — the crypto wallet meant to give financial independence to people without bank accounts.
  • How separate it was: "Our floors specifically, we had to badge in to enter. Nobody else from the company could enter our floors." A completely different codebase, different infrastructure, different tooling, different databases, all built in-house for that org.
  • Then COVID: "Right after I joined, everything was shut down and I was back at home for 15 months." He notes Meta was a hard place to work through it, because policy had to work globally "for something in the vicinity of 100,000 employees."

9. Hack, Flow, Relay, Sapling — everything you use, but different

The clearest summary of what Meta's stack actually is.

  • The backend language: Not PHP, but close enough to look like it. Around fifteen years ago Facebook concluded it was too big to move off PHP and that PHP wasn't performant enough, so "they decided to rewrite PHP to be a compiled language and basically run in a different runtime." That's Hack, on HHVM — with async, types and generics, "some of the features that do not even exist in PHP 8 today." The file extension is still .php.
  • His honest take on it: "I don't think there is any reason for any other company in the world other than Facebook to use that" — especially now, since "AI is not trained on that."
  • Why it works anyway: Entire teams exist to make the developer experience around it good — internal database engines, internal ORMs, chainable APIs, all integrated with the privacy and user-data constraints the company operates under.
  • The frontend: React everywhere, but written in Flow, not TypeScript. "In the beginning there was TypeScript and there was Flow, and they were pretty much the same level and they were competing." TypeScript won on adoption and tooling; Flow stayed largely Meta's. "If you look underneath the hood, you'll see that they're very different, and stuff that you expect to work in one way in TypeScript would work very differently in Flow." He hits unexpected bugs switching between his personal TypeScript projects and work.
  • Data fetching: Relay with GraphQL, not React Query or TanStack Query. "It does all the things that TanStack Query would do, only that it does that in a typed way."
  • Source control: Sapling, an open source fork of Mercurial, with an internal review tool rather than GitHub.
  • The culture shock, summarised: "Everything you have outside, we have inside but different. We don't use Docker and Kubernetes, we use our own thing. We don't use AWS, we have our own data centers. The first few months, you just relearn engineering."

10. Stacked diffs are the thing ex-Meta engineers actually miss

A workflow difference worth understanding even if you'll never work there.

  • How it works: Instead of a branch and a pull request, "you create a commit and it creates a review. And on top of that commit, you create another commit and that also gets its own specific review." Ten in a row is normal.
  • The requirement: Each one has to stand alone. "The assumption is that each of those is its own complete part of the feature that you can ship to production and will not break anything."
  • The payoff: "When the entire stack is completed and it's all reviewed, you can just merge the entire thing" — no rebasing each piece individually.
  • Who reviews: You assign reviewers from your team or from whichever team's code you're touching. "I can do a code review for a different team completely on the other side of the ocean, nobody cares. It's a very open engineering culture."

11. Nobody develops locally — you reserve a dev server that runs all of Facebook

The practical upside of a gigantic monorepo.

  • The setup: "You never work locally on your machine. We always connect to our remote server," reserved at the start of the day, with your editor connecting to it.
  • What that gives you: "The entirety of the system can actually work from there. You don't need to set up a full environment with microservices and everything."
  • Testing: Internal frameworks for end-to-end tests, browser tests and snapshots. "Don't ask me if we have Storybook. We don't have Storybook. Don't ask me if we use the same kind of Jest that you do, because we don't."
  • What's genuinely the same: React itself, mostly — some different lint rules and constraints. Server components and server actions are out, because the servers are Hack, so rendering React on the server goes through a different internal API.

12. Move fast and break things is over, because incidents hurt real people

The cultural shift, argued from his own team's blast radius.

  • The change: "In the past three years, there has been massive backlash on that specifically. Meta is trying to most actively pursue quality."
  • Why: "With the scale of Facebook or Instagram or WhatsApp, incidents in production do have real consequences on people's lives."
  • His own example: He works in financial fraud prevention. "If I mess up, people either get scammed, or people lose money, or the company loses money, or people are unable to pay and businesses get hurt." A business blocked from paying for an ad on a false fraud signal loses the business that ad would have brought.
  • Where speed still applies: "Internal tools — yeah, ship whatever, if it doesn't hurt anything or if it doesn't touch any production system."
  • Why it matters more now: "Especially now that you ship much, much more code with AI."

13. He owns the context package on npm, and that's the point

His open source philosophy, which is really a supply chain argument.

  • The pattern: He built his own CSS-in-JS library for EmojiPicker React. He uses no state management library. He built his own context library. "I own the word context on JavaScript. If you go to npm, package context, you'll see my name there. My proudest moment."
  • The reasoning: "Today we have a serious problem of supply chain attacks, and we have a serious problem of bloat inside of our open source packages. I try to avoid that and ship the highest quality code that I can to my users."
  • How he self-describes: "I'm sort of a control freak, but low-key."
  • On contributions: Genuinely open — "if you want to contribute, come contribute" — with two conditions. "Just know that I will not mentor you forever about that change. And let me know if you want to make some change, because I don't want to review a 40 file change before I even have the context on why you're making it."
  • On AI-generated PRs: "Cursor is an amazing tool for at-home development. It's a terrible thing for an open source maintainer." He rejects more PRs than he used to. "It only makes me click more red buttons." Though he notes the volume comes alongside real growth in adoption.

🧠 What I Learned

  • Evyatar learned JavaScript on Code Academy during military night shifts, with no degree and no high school diploma, because server room shifts were boring.
  • He chose frontend purely because an index.html and an index.js ran without any toolchain to install — the path of least resistance.
  • He got into Fiverr by having a friend knock on HR's door after being ignored, then survived a coding test he couldn't finish because they forgot him in the room for two hours.
  • Fiverr Print quietly ran on a product manager manually placing orders on a third party printing site overnight.
  • EmojiPicker React (around 600,000 weekly downloads) started as an internal tool for Fiverr's inbox.
  • He created a team by observing that every real team had an animal name and a printed banner, then getting a logo and a banner made by telling everyone his manager had approved it.
  • His Fiverr micro frontend work exposed every Rails named route as constants consumable from React on Node, so links stayed correct across the monolith boundary.
  • He turned Facebook down and was talked back into it by his wife and by his own HR manager.
  • He failed the Dan Abramov round of his Meta onsite outright, and they simply rescheduled that one round because the others went well.
  • His first years at Meta were on Calibra/Novi, behind badge-locked floors with an entirely separate codebase, immediately followed by 15 months of COVID.
  • Meta runs Hack on HHVM (compiled, typed, generics, async — beyond PHP 8), React written in Flow, Relay instead of Apollo or TanStack Query, and Sapling instead of Git.
  • Stacked diffs mean each commit gets its own review and must be independently shippable, then the whole stack merges at once — the thing ex-Meta engineers miss most.
  • Nobody develops locally; you reserve a remote dev server that can run the entire product out of the monorepo.
  • Move fast and break things is dead at Meta because production incidents at that scale cost real people real money.
  • He writes his own libraries rather than taking dependencies, explicitly because of supply chain risk and package bloat.

💬 Favorite Quotes

"Night shifts were very boring. And I remember just deciding, well, I could just spend the time learning JavaScript, because what else do I have?"

"It was the path of least resistance. I'm dead serious."

"All of the teams had an animal name. All of the teams had a big banner. So all I need to do is have an animal name and have a banner, that's it. And I will have a team."

"Technically, yeah, I'm the manager of the team. I approve — even though I wasn't."

"Are you stupid? Go back and apologize to them."

"You don't say no to a company like that. You go, you say yes."

"I was crushed. I think I was starstruck a little bit and I failed the interview completely."

"Everything you have outside, we have inside but different."

"The first few months, you just relearn engineering, I guess."

"With the scale of Facebook or Instagram or WhatsApp, incidents in production do have real consequences on people's lives."

"I own the word context on JavaScript. My proudest moment."

"Cursor is an amazing tool for at-home development. It's a terrible thing for an open source maintainer."

🎯 Also in this Episode

  • The Israeli work week running Sunday to Thursday, and the ongoing comedy of US colleagues scheduling meetings on a Friday
  • Comparing compulsory military service in Israel with the two weeks of high school military training I got in Romania, which was mostly two weeks off school
  • Why Vue got popular by letting you drop a script tag into a single HTML file — and why even Vue isn't that simple anymore
  • Passable, the validation library he had to retire because it was Fiverr-branded, and how it became Vest
  • Why Meta's Tel Aviv office has the best cafeteria of the dozen-plus Meta offices he's visited
  • The three separate times an internal transfer to the React Native infrastructure team fell through, twice on company-wide policy changes
  • GraphQL and React both leaving Meta's sole ownership — GraphQL to a foundation, React to the React Foundation
  • Lightning round: plain CSS over CSS-in-JS (despite having written his own CSS-in-JS library), and no state management library at all
  • Book recommendations: The Design of Everyday Things by Don Norman, for API design rather than product design — including the Norman door — and Never Split the Difference by Chris Voss, which we both credit with improving salary and deal negotiations

Resources

More from Evyatar and the tools mentioned:

  • Evyatar on GitHub
  • Evyatar on LinkedIn
  • EmojiPicker React — The most popular emoji picker for React
  • Vest — His validation library, successor to Passable
  • Sapling — Meta's open source Mercurial fork used for source control
  • Hack and HHVM — The compiled PHP dialect and runtime behind Meta's backend
  • Flow — The type layer React itself is written in
  • Relay — Meta's typed GraphQL client, in place of Apollo or TanStack Query

Books mentioned:

  • The Design of Everyday Things by Don Norman
  • Never Split the Difference by Chris Voss

🎧 Listen Now

🎧 Spotify
📺 YouTube
🍏 Apple Podcasts

Episode Length: 54 minutes on learning to code with nothing, faking a team into existence, Meta's frontend and backend infrastructure from the inside, stacked diffs, and open source maintenance in the AI era.

Whether you're curious what a hundred-thousand-person engineering org actually runs on, or you just want proof that a career can start on a boring night shift with no degree, this one delivers both.

Happy shipping,
Dan

🛡️ FRONTEND SECURITY · REACT · VUE · ANGULAR · VANILLA JS

Master Security in Frontend Applications

Free, comprehensive frontend security course.
XSS, CSRF, AI security, broken access control & the vulnerabilities that actually get you breached.

100% FREE 7 MODULES · ALL LIVE
Start learning free →

All 7 modules live now. No credit card.

💡 More Recent Takeaways

Accessibility at Scale with Craig Abbott
Episode 48

Señors @ Scale host Neciu Dan sits down with Craig Abbott, Principal Accessibility Specialist at TetraLogical and the former Head of Accessibility at the UK's Department for Work and Pensions, one of the largest government departments in the country, where he built a dedicated accessibility practice from nothing and open sourced the DWP Accessibility Manual. Craig has over 15 years in user centred design and has led accessibility work across the public sector and at Elastic. From what sustainable accessibility actually means and why third party audits alone don't get you there, to the three C's of compliance, culture and capability, to running screen readers in VMs without expensive licences, to accessibility acceptance tests in CI with Playwright, Cucumber and Guidepup, to why compliance does not mean usable, this is the accessibility conversation for teams who want it to survive the person who cares about it.

Versatility at Scale with Carmen Huidobro
Episode 47

Señors @ Scale host Neciu Dan sits down with Carmen Huidobro, CTO at Incredible Bee in Vienna, where she builds products and helps teams figure out what should be automated and what should stay in the hands of users. Carmen has spent 17 years in tech, almost all of it freelancing, working across Objective-C, Ruby on Rails, the web, mobile, hardware, and even ABAP inside an SAP consultancy, plus five years in developer relations and developer education. Her argument is that the generalist versus specialist debate misses the point: the durable skill is being an expert at adapting. From adding a local Mistral model to a twenty-year-old macOS app without betraying the people who use it, to the refugee hackathon project the City of Vienna still runs a decade later, to why she won't take money from junior developers, this is a conversation about the skills that survive the shift.

CI/CD at Scale with Marko Gacesa
Episode 46

Señors @ Scale host Neciu Dan sits down with Marko Gaćeša, Head of Product at Semaphore, the agent-native CI/CD platform, and the first product guest on the show. Marko is a serial entrepreneur whose career spans developer tools, IoT, industrial automation and enterprise SaaS, including founding Dry Tools and serving as Chief Product Officer at Alchemy Cloud, with earlier work in domains like medical equipment where quality is non-negotiable. From why testing rather than coding is now the bottleneck, to what agent-native CI/CD actually means when developers live inside their coding agent, to how SemAI attacks flaky tests and automates migration off GitHub Actions, to pricing a platform where a minute of CI is not the same minute everywhere, this is the product side of developer tooling from someone shipping it.

AI Harness at Scale with Maxim Salnikov
Episode 45

Señors @ Scale host Neciu Dan sits down with Maxim Salnikov, AI Dev Tools Solution Engineer at Microsoft, where he leads AI native development enablement for over 100 enterprise customers of Microsoft and GitHub in Norway. Maxim has been building for the web since the late 90s and spends his days inside real enterprise dev teams across finance, energy, agriculture, and pure software companies, watching AI adoption succeed and fail. From why adoption is a change management problem rather than a technology one, to the anatomy of an AI harness and the external layer successful companies build on top of it, to the context engineer and agent ops roles now appearing in team topologies, to managing agent skills as versioned dependencies instead of letting them pollute the repo, this is the enterprise AI adoption conversation from someone who sees a hundred versions of it.

📻 Never Miss New Takeaways

Get notified when new episodes drop. Join our community of senior developers learning from real scaling stories.

💬 Share These Takeaways

Share:

Want More Insights Like This?

Subscribe to Señors @ Scale and never miss conversations with senior engineers sharing their scaling stories.