One thing worth noting upfront: Cohere has several FDE specializations, including Agentic Platform, Infrastructure Specialist, and Prompt Specialist. The interview process is largely the same for all of them. The difference shows up in two rounds where the focus shifts based on which specialization you're applying for.

Hiring Manager Interview

The process started with a 45-minute call with the hiring manager. This wasn't a deep technical grilling. It was more about whether my experience actually maps to the shape of the role.

The questions were broad: have I deployed systems in on-prem or restricted environments? Have I scaled distributed systems? What's the hardest technical problem I've owned? Have I worked with customers who have strict security requirements?

What caught me off guard was how much they cared about the customer dimension. It wasn't enough to say "I built a scalable system." They wanted to hear how I navigated constraints that came from the customer's environment, things like networking boundaries, compliance requirements, and deployment restrictions that you don't deal with when you're shipping to your own infrastructure.

The key is not just telling war stories. You need to show that you can move between technical depth, customer context, operational constraints, and executive-level judgment, sometimes in the same sentence.

System Design Debugging

This was the most distinctive round and the one I'd recommend preparing for the most.

I was given a complex architecture diagram, something resembling a large-scale distributed system, and a deliberately vague prompt: "A customer reported that requests are failing. Debug the issue."

That's it. No stack traces. No error codes. No hints about where the problem might be. The interviewer sat back and waited.

The entire round is about whether you can run a hypothesis-driven debugging process under ambiguity. You're expected to drive the investigation: ask for specific logs, metrics, or traces. Explain why you want each piece of data. State your hypothesis. Update it when the evidence doesn't match. Converge without thrashing randomly.

The mistake I almost made was jumping straight into a generic debugging checklist: "check the load balancer, check the database, check the cache." That's not what they want. They want to see you reason about failure domains, prioritize what to investigate first, and make the investigation legible as you go.

I found the best framing was to think out loud: "The most likely failure domain is X because of Y. To confirm, I'd want to see Z. If that's clean, I'd move to W." When the interviewer handed me a piece of data that contradicted my hypothesis, the right move was to say so explicitly and pivot, not to force-fit the evidence. If you've ever been on-call and had to debug a production incident with incomplete information while someone is watching, that's the energy of this round.

Architecture Presentation

This round flips the dynamic. Instead of the interviewer presenting a problem, you present the architecture of a real project you've worked on.

Project choice matters more than presentation polish. Given Cohere's focus on enterprise AI deployment, the best projects involve distributed systems, infrastructure-heavy design, reliability tradeoffs, or security-sensitive environments. The interviewer wants to look at your project and imagine you deploying large-scale LLM systems for demanding customers.

I chose a project that involved deploying a data pipeline in a compliance-constrained environment. It wasn't the most technically flashy thing I'd built, but it was deeply relevant. The interviewer's questions were probing: why did you make this reliability tradeoff? What would break under 10x traffic? How did you handle failure isolation?

A simpler but highly relevant system beats a flashy but unrelated one. Prepare to talk through system context, scale assumptions, reliability decisions, security constraints, and what broke and how you fixed
it. If you applied for a specific specialization, say Infrastructure Specialist, expect the questions to lean heavily into that domain.

VP Behavioral Interview

This was conducted by senior leadership and was the most customer-focused round.

The representative question: "Tell me about a time you took customer feedback and contributed to core product improvements or built new features."

They're not looking for stories about workarounds. They want evidence that you can identify recurring customer pain, separate local symptoms from product gaps, and work with product and engineering to drive durable fixes. The loop from customer problem to product improvement, that's the FDE job, and they want to see you've done it before.

I talked about a situation where I kept hearing the same complaint from multiple customers about a configuration edge case. Instead of patching it each time, I documented the pattern, brought it to the product team, and worked with them on a proper fix. The interviewer pushed on the specifics: how did I get buy-in? How did I prioritize it against other work? What was the outcome?

Prepare two or three stories where you worked directly with customers, identified a repeated pain point, and influenced product or engineering changes beyond a one-off workaround.

HR Interview

The final round was 30 minutes covering culture fit, motivation, and compensation alignment. Not the hardest round, but weak answers can still raise doubts if your story about why Cohere and why FDE feels generic.

Know what Cohere does and who their customers are. Have a clear answer for why FDE specifically, not just "I want to work at an AI company."

Summary

Cohere's FDE interview doesn't test what most people prepare for. There's no LeetCode. No algorithm puzzles. No memorized design patterns. Instead, they test whether you can debug a distributed system under ambiguity, present an architecture and defend it under probing, and show that you've turned real customer pain into real product improvements.

The biggest trap is preparing for this like a standard software engineering interview. It's not. This loop is much closer to enterprise AI deployment + technical leadership + systems debugging. If your preparation only focuses on coding rounds, you're preparing for the wrong job.

Prepare like someone who has to walk into a customer environment, debug a failing AI system, explain the architecture clearly, and then help the product improve because of what you learned.

The full interview guide with practice questions is available at https://furustack.com/interview/company/cohere/forward-deployed-engineer

An FDE at OpenAI isn't a regular software engineer. You don't sit on a product team shipping features. Instead, you work directly with enterprise customers, deploying and integrating OpenAI's AI solutions into their systems. Think half engineer, half consultant. Your job is to take AI from "cool demo" to "production business system." When I got the chance to interview, I wanted to see how OpenAI evaluates for this hybrid skillset.

Recruiter Screen

The process started with a 30-minute call with a recruiter. They walked through my background and spent a lot of time on why I wanted FDE specifically, not just "work at OpenAI." This distinction matters. If you can't articulate why you want customer-facing technical work versus pure engineering, the process stops here.

They also asked about my experience with production AI/ML systems. Not "have you used ChatGPT" but "have you deployed AI in production and dealt with the messiness that comes with it." I talked about a RAG system I'd built and the real-world challenges of chunking strategies and retrieval quality. The recruiter seemed satisfied that I understood what the job actually involves.

Technical Assessment (Take-Home)

This is where OpenAI's process gets interesting. They give you a substantial take-home project, about five hours of work, building something with OpenAI's APIs. The deliverable isn't just code. You also record a video walkthrough explaining your solution.

The video part is brilliant and terrifying. FDEs present to customers every day, so they're testing that skill directly. I treated my walkthrough like a customer demo: here's the problem, here's my approach, here's how it works, here's what I'd improve.

I spent extra time on production considerations: error handling, graceful degradation, logging. A lot of candidates probably build a working demo and stop there. But FDEs ship production systems, not prototypes. I made sure my code reflected that.

One mistake I almost made: I nearly over-explained the code line by line in the video. Instead, I focused on decisions and tradeoffs. Why I chose this embedding model. Why I structured the pipeline this way. What would break if the customer's data was messy (it always is).

Technical Screen

Next was a 60-minute live session where the interviewer dug into my take-home submission. They asked about specific decisions I made: why this chunking strategy, why not a different retrieval method, what would I change if the dataset was 100x larger.

Then they moved into additional technical questions about production AI systems: API rate limiting, retry patterns, prompt engineering for robustness, and how to evaluate AI system quality beyond "does it look right."

The interviewer also asked about debugging. "Walk me through how you'd diagnose high latency in an LLM inference pipeline." They wanted me to think through the full stack: is it token generation, network, preprocessing, or something else entirely? Then we discussed batching strategies and caching.

My takeaway: "I just call the API" won't fly here. You need to understand what's happening under the hood.

Virtual Onsite

The onsite was 3-4 hours with three sessions.

Hiring Manager Round (60 min): Deep conversation about my background, with heavy focus on customer-facing experience. They asked about challenging deployments, how I handle ambiguity, and times I had to explain technical limitations to non-technical stakeholders. When I mentioned a project where I had to tell an executive their timeline was unrealistic, the interviewer leaned in and asked how exactly I framed that conversation. Communication skills are not a nice-to-have for this role. They're the job.

Solution Design Round (60 min): The interviewer presented an open-ended customer scenario and asked me to design a complete AI solution. I won't share the exact scenario, but think along the lines of "a company wants to use AI to solve X business problem." The key was starting with the customer, not the technology. Who uses this? What decisions do they make? What does success look like? Only then did I work backwards to the architecture.

I made the mistake of jumping into technical design too quickly. The interviewer stopped me and asked "what questions would you ask the customer before designing anything?" That reset was important. FDEs don't build in a vacuum. They build for specific people with specific constraints.

Technical Deep Dive (60 min): This was the most intense round. Deep questions on RAG architecture (embedding selection, chunking, retrieval methods, reranking), fine-tuning tradeoffs (when to fine-tune versus RAG versus prompt engineering), and guardrails for production LLM applications.

The interviewer pushed hard on evaluation. "How do you know your AI system is actually working well?" This is a question most engineers hand-wave through, and they clearly use it as a differentiator. I talked about combining automated metrics with human evaluation and building feedback loops, which led to a good discussion about the tradeoffs of each approach.

Summary

OpenAI's FDE interview tests exactly what the job requires: can you build production AI systems, present them clearly, and design solutions for real customer problems? The take-home with video walkthrough is the most unique element and a direct simulation of the daily work.

The biggest trap is treating this like a regular SWE interview. It's not. Communication skills, customer empathy, and AI-specific depth matter just as much as coding ability. If you've only ever built internal tools and never explained a technical concept to a non-engineer, prepare for that gap.

The process took about three weeks. Communication was prompt throughout.

Want to save your preparation time? Check out https://furustack.com to understand what you need to prepare instead of guessing.

Phone Screen

The process kicked off with a short phone screen, about 15-30 minutes. This wasn't deeply technical. An engineer asked about my background, my strongest technical achievement, and why xAI.

One thing that stood out: xAI asks you to submit a "statement of exceptional work" with your application. During the phone screen, they referenced it and asked follow-up questions. If you're applying, don't treat that statement as a throwaway. Pick something genuinely impressive and be ready to defend it in detail.

The call was quick and direct. No fluff. Very on-brand for a company that prides itself on moving fast.

Live Coding Assessment

Next was a 45-60 minute coding session. Some candidates report using CodeSignal, others get a live session with an engineer. I got the live version.

The problems were medium to hard, with a focus on data structures and algorithms. Nothing exotic, but they expected clean, correct code with solid complexity analysis. The interviewer asked me to explain my approach before coding, and pressed on time/space tradeoffs afterward.

Language-wise, they're flexible: C++, Rust, Go, or Python. I went with Python since I could move faster, but if you're applying for infrastructure roles, demonstrating comfort with Go or Rust probably helps.

My advice: don't rush. They care about correctness and clarity. Explain your invariants, handle edge cases, and be upfront about the tradeoffs you're making.

Distributed Systems Design

This was a 60-minute whiteboard-style session focused on scalable architecture. Given that xAI runs some of the world's largest GPU training clusters and is building a payment system (X Money), they need engineers who think about distributed systems seriously.

The interviewer gave me an open-ended problem and wanted to see how I reasoned about scaling, consistency, and fault tolerance. We covered topics like sharding, replication strategies, message queues, and service contracts.

What surprised me was how practical the discussion was. They didn't want textbook answers about CAP theorem. They wanted to know what I'd actually build, what would break first, and how I'd monitor it. When I gave a generic "use Kafka" answer, the interviewer pushed back: "Why Kafka specifically? What are the alternatives and why are they worse for this case?"

The lesson: have real opinions backed by real experience. "It depends" is fine, but you need to explain what it depends on.

Hands-On Practical Session

This was another 45-60 minute round, but instead of designing on a whiteboard, I was writing real code for a systems problem. Think: implementing a component that needs to be thread-safe, optimizing a microservice, or debugging a concurrency issue.

I hit a wall here. The interviewer asked me to implement something with concurrent access, and I tried to go with a fancy lock-free approach. When they asked me to walk through the correctness argument, I couldn't do it convincingly. I ended up simplifying to explicit locks and explaining exactly which race conditions I was preventing.

xAI has the same philosophy as Databricks on this: simple and correct beats clever and broken. If you can't explain why your concurrent code is safe, it's not safe.

Project Deep-Dive Presentation

This is what makes xAI interviews unique. You prepare a 20-minute presentation about the most challenging technical problem you've ever solved, then defend it in Q&A.

I chose a project where I rebuilt a real-time data pipeline, and I'm glad I did. The interviewers went deep. They asked why I chose specific technologies, what I tried that didn't work, what the measurable impact was, and what I'd do differently today. When I mentioned a metric, they asked how I measured it. When I described a design choice, they asked what alternatives I considered.

This is not a resume walkthrough. They want to see that you truly own your work and can reason through hard technical decisions under pressure. Prepare one project, know every detail, and have numbers ready: latency improvements, throughput, cost savings, whatever applies.

Structure your presentation like this: context, constraints, approach, tradeoffs, results, learnings. Practice the 20-minute version and a 5-minute version. The Q&A will fill whatever time is left.

Team Interview

The final round was a 30-45 minute conversation focused on culture and collaboration. xAI has a strong "only engineers, no researchers" philosophy. Musk has compared the culture to SpaceX: high accountability, first-principles thinking, and zero tolerance for low-ownership behavior.

They asked about times I navigated ambiguity, wore multiple hats, and took initiative without waiting for permission. They also probed my genuine interest in xAI's mission. This wasn't the "why do you want to work here" softball. They wanted specifics about what I'd want to build and why.

Summary

xAI's interview process is thorough and tests a wide range of skills: algorithms, systems design, hands-on coding, presentation, and culture fit. The project deep-dive presentation is the standout round and something most companies don't do. If you have a genuinely impressive technical project in your history, this is where it pays off.

The concurrency and systems rounds are demanding. If your day job doesn't involve thinking about distributed systems or thread safety, you'll need to prepare specifically for these.

The whole process took about three weeks. Communication was fast and direct. No weeks of silence between rounds. If you're the kind of engineer who likes ownership, moves fast, and has real production experience to draw from, xAI's process will feel fair. If you're used to pure LeetCode grinding with no systems experience, you'll struggle.

Want to save your preparation time? Check out https://furustack.com to understand what you need to prepare instead of guessing.

Recruiter Call

The first step was a 30-minute call with a recruiter. Standard stuff: my background, why Sakana, what I'm looking for. They asked about my experience with AI/ML infrastructure and fullstack development. Sakana is a research lab, but their engineering roles require broad technical skills since you're building the infrastructure that powers the research.

The recruiter mentioned that Sakana values "understanding over implementation." I didn't fully grasp what that meant until later.

Technical Assessment (Take-Home)

Here's where Sakana diverges from everyone else. Instead of a timed coding test or a live coding session, they gave me a take-home project with an extended deadline. Not a weekend. Not 48 hours. Up to one month.

At first I thought this was generous. Then I realized it was a trap of sorts. With that much time, there's no excuse for a shallow solution. They're not testing whether you can solve a problem under time pressure. They're testing whether you truly understand what you build.

I spent about two weeks on it, going through multiple iterations. The key thing I did right: I documented everything. My README explained my hypothesis for each major design decision, what alternatives I considered, what limitations my solution had, and what I'd improve given more time.

When I talked to someone who had done the same process, they told me they spent three weeks and submitted a polished project but bombed the follow-up interview because they couldn't explain why they made certain choices. The code was good, but the understanding was missing.

The lesson is clear: Sakana cares more about your decision-making process than your final output. A simpler solution with well-reasoned decisions beats an over-engineered one you can't fully explain.

Technical Interview

This was a 60-minute experience deep-dive. No whiteboard. No LeetCode. The interviewer pulled projects from my resume and went deep.

They picked one of my past projects and asked me to walk through it end-to-end. Then the follow-up questions started. "Why did you choose this database over that one?" "What was the hardest bug you encountered?" "What would you do differently now?" Every time I gave a surface-level answer, they pushed for specifics. Numbers, metrics, exact technical details.

They also tested fullstack knowledge. Even though I'd mostly worked on backend systems, they asked about frontend considerations, deployment strategies, and infrastructure choices. Sakana builds research infrastructure that spans the entire stack, so they want engineers who can think broadly.

The most interesting question was: "Tell me about a technical decision you made that you later realized was wrong." They wanted to see intellectual honesty and the ability to learn from mistakes. I talked about a caching strategy that seemed clever at the time but created consistency issues we didn't catch until production. The interviewer nodded approvingly when I explained how the experience changed my approach to caching in subsequent projects.

System Design (Optional)

I have heard system design round but it depends on the team and your interview performance. I will update this when I heard back more regarding their system design

Culture Fit

The final round was a 45-60 minute conversation about how I work with people. Sakana is a startup that works with enterprise clients, so they need engineers who can communicate with non-technical stakeholders.

They asked about times I navigated ambiguous requirements, translated business needs into technical solutions, and collaborated across
teams. One question that stuck with me: "Tell me about a time a customer or stakeholder asked for something technically infeasible. How did you handle it?"

They're clearly looking for engineers who can operate in the messy space between research and product, where requirements change fast and you need good judgment about what to build and what to push back on.

Summary

Sakana AI's interview process is refreshingly different. The month-long take-home project rewards depth over speed. The technical interview is a conversation about real experience, not a coding exam. And the culture fit round tests whether you can operate in a fast-moving research startup.

The biggest risk is underestimating the take-home. You have time, which means they have high expectations. Document your thinking, acknowledge limitations, and be ready to explain every decision you made.

If you're the kind of engineer who geeks out over understanding why things work (not just making them work), Sakana's process will feel natural. If you prefer the structured predictability of LeetCode rounds, this will be uncomfortable in a good way.

The whole process took about five to six weeks, partly because of the extended take-home timeline. Communication was responsive throughout.

For anyone interested in working at the intersection of AI research and engineering in Tokyo, Sakana is one of the most exciting opportunities right now. The founders' pedigree is world-class, and the problems are genuinely interesting.

Want to save your preparation time? Check out https://furustack.com to understand what you need to prepare instead of guessing.

The process started with a 30-minute recruiter call. No technical questions here, just a conversation about my background, why Sierra,  and what I'm looking for. The recruiter was genuinely curious about my motivation for joining an AI startup versus staying at a bigger  company. They also explained the interview process clearly upfront, which I appreciated. No surprises.

One thing worth noting: they asked about my preferred programming language early on. Sierra primarily works in Python and TypeScript, and they want you to interview in one of those. If you're a Java or C++ person, you'll want to get comfortable in Python or TS before the process starts.

Technical Screen

This is where it gets interesting. Not LeetCode — it simulates a real scenario you'd encounter working at Sierra. Conducted on CoderPad (sometimes they ask you to share your screen). You'll be given a practical multi-part problem that builds progressively. For example, you might start by calling an API endpoint that fails occasionally but eventually succeeds. After solving that, the response contains a product list with fallback IDs, and you need to iterate through the list and resolve each product's eventual set of IDs into the product objects.

The key here is that each follow-up adds new requirements on top of your existing code. This tests whether you write flexible, extensible code from the start and not whether you memorized a sorting algorithm.                                                                                    

Debugging round

This round was surprisingly fun. You don't need to write a lot of code — you need to understand code.

You're given a small codebase (around 4-5 files) that implements an agent, plus a diagram showing how
the agent should work. The diagram is your source of truth. You can run the agent and iterate on the CoderPad terminal.

At each part, the interviewer describes a scenario they want to test. You need to figure out what's wrong in the code and fix it before moving forward. There were about 3 bugs to find, and if you have time left, they'll ask you to think about how to optimize the code

Agent Building (Take-home + 60 minutes onsite)

This is a two-part round and the most unique part of Sierra's process.

Part 1 — Take-home: You receive an API key and a prompt to build an agent that carries out different functions

Part 2 — Onsite presentation (60 minutes): You present your agent to an interviewer who will ask a ton of "why" questions. Why this architecture? Why this approach to tool calling?

Hiring Manager Round (60 minutes)

Behavioral interview focused on agency and collaboration. You'll be asked about how you've demonstrated ownership and driven projects forward in past roles. How you collaborated with others, handled disagreements, and worked across teams.

They also care about alignment — how this role fits your professional interests and career goals. This isn't a generic "tell me about a time" round. The questions are specific and they dig into details.

Summary

Sierra's interview process is practical and well-designed. They test what actually matters for the job: can you write clean, extensible code? Can you adapt when requirements change? Can you reason about data structure tradeoffs? Can you communicate clearly about your past work?

The technical screen with layered follow-ups is the most unique part. It rewards engineers who write flexible, well-structured code over those who memorize algorithms. If you've spent your career building real systems, you'll feel right at home. If you've only been grinding LeetCode, you might struggle with the open-ended nature of the problems.

The whole process took about two to three weeks. Communication was clear throughout. For a startup, they run a tight process.

My biggest takeaway: Sierra interviews like a company that actually cares about hiring good engineers, not good test-takers. Focus your preparation on practical coding, class design, and being able to talk concretely about your past work. That'll get you further than memorizing sorting algorithms.

Want to save your preparation time? Check out https://furustack.com to understand what you need to prepare instead of guessing. Also https://singdev.fyi contains real interview experience with Sierra, so check it out !

1. Phone Screen

The recruiter scheduled a 60-minute technical screen with an engineer. I was expecting the usual LeetCode grind, but Databricks does things a bit differently. Yes, there was coding, but the interviewer spent a good chunk of time just talking through my approach before I wrote a single line.

I got a medium-difficulty problem involving some data structure manipulation. Nothing crazy, but the interviewer kept asking "why" questions. Why did I choose this approach? Why not use a different data structure? What would happen if the input was 100x larger? It felt less like an exam and more like a design discussion with a colleague.

The thing that caught me off guard was when I started coding immediately. The interviewer stopped me and asked me to explain my plan first. At Databricks, they really want to see how you think, not just whether you can produce working code. I adjusted and talked through my invariants before implementing. The rest of the interview went smoothly after that.

2. Onsite - High Level Programming

This round was unlike anything I'd done before. Instead of solving a LeetCode problem, I was asked to design and implement a class from scratch. The interviewer gave me a simple API specification and said "implement this."

I made a rookie mistake here. I jumped straight into coding without asking enough questions. About halfway through, the interviewer asked "What happens if someone calls this method with invalid input?" and I realized I had no idea because I never asked about edge cases. We had to backtrack and discuss requirements properly.

The lesson was clear: Databricks wants engineers who think before they code. They're not impressed by how fast you can type. They want to see you ask clarifying questions, consider edge cases, and make deliberate data structure choices. I ended up using a TreeMap for ordered access, and the interviewer seemed satisfied with my reasoning.

The code review at the end was thorough. They asked about alternative approaches I considered and why I rejected them. It felt like a real code review you'd have with your team, not a gotcha session.

3. Onsite - Low Level Programming

This is where I almost failed.

I knew Databricks cared about concurrency, so I'd done some preparation. But knowing the theory and actually implementing thread-safe code under pressure are two very different things. I was asked to implement a component that needed to handle concurrent access safely.

My first instinct was to show off with some lock-free approach I'd read about. Big mistake. The interviewer asked me to explain why it was thread-safe, and I stumbled through an explanation that even I wasn't convinced by. They gently suggested I try a simpler approach with explicit synchronization.

The second attempt went better. I used a straightforward synchronized block and could clearly explain what race conditions I was preventing and what ordering guarantees I was providing. The interviewer nodded and asked follow-up questions about potential deadlocks and performance implications.

What I learned: Databricks doesn't want cleverness. They want correctness. A simple synchronized solution that you can reason about beats a fancy lock-free implementation that might have subtle bugs. Many candidates apparently fail this round because they try to be too clever or because they've never really thought deeply about thread safety in their day-to-day work.

Want to save your preparation time? Check out https://furustack.com to understand what you need to prepare instead of guessing.

4. Hiring Manager Round

After the intense concurrency round, I expected the hiring manager round to be more of the same. It wasn't. This was a deep dive into my past experience, with a focus on how I've handled real engineering challenges.

The interviewer asked me to describe a production incident I'd dealt with. Not just "what happened" but the full story—how I detected it, what I tried, what worked, what didn't, and what I changed afterward to prevent it from happening again. They pushed for specific technical details. When I said "I optimized the database queries," they asked "Which queries? What was the before and after? How did you measure the improvement?"

I appreciated that they weren't looking for hero stories. When I mentioned a situation where I had to escalate to a more senior engineer because I was stuck, the interviewer nodded approvingly. They want engineers with good judgment who know when to ask for help, not lone wolves who think they can solve everything themselves.

Summary

Databricks has a focused interview process that tests what actually matters for the job. They don't care how many LeetCode problems you've solved. They care whether you can write correct code, reason about concurrency, and handle real-world engineering challenges with good judgment.

The concurrency round is the make-or-break moment for most candidates. If you've spent your career at companies where you never had to think about thread safety, you'll struggle here. Spend extra time preparing for this, and remember: simple and correct beats clever and buggy.

The whole process took about three weeks from first screen to offer. Communication was professional throughout, with the recruiter keeping me updated even when there were scheduling delays.

Despite the challenging concurrency round, I think Databricks has one of the more reasonable interview processes out there. They test practical skills over algorithmic party tricks, and the interviewers genuinely try to help you succeed rather than catch you out. If you're strong on fundamentals and have real production experience, you'll do well here.

Want to save your preparation time ? Check out furustack.com to understand what you need to prepare instead of guessing.

1. Take-home assignment

I was asked to write a simple command-line tool that parses and aggregated some data. You are free to use any programming language that you like. I was told usually one will spend 2 ~ 4 hours but it took me 5 hours to complete the interview. This is better than a lot of other companies' take-home assignments because the scope is smaller and the instruction was clear. The best way to tackle this is to write the code as you would in production. Woven by Toyota deals with huge data so it's important for them to see how well you deal with scalability.

2. First technical round

My first interviewer was very friendly and smart. In a way, he knows how to make interviewees feel relaxed while supporting them by giving hints in a smart way. This interview starts with domain knowledge tests that go through Linux kernel to browser DOM (because I was interviewing the full stack position). Then we started the review of the take-home assignment. While they managed to follow up on some scalability concerns, overall I didn't feel that they have spent enough time going through my works to give good enough feedback. The last session of this interview was live coding. I think they just want to make sure you can code, so there were no Leetcode hard problems and I am thankful for that.

Want to save your preparation time ? Check out furustack.com to understand what you need to prepare instead of guessing.

3. Second technical round

The second technical round was more or less like the first round but they spend more time going through my resume to understand my work. We then have a very short session of domain knowledge tests. Some of them make my eyes roll but overall they were easy enough. We ended the interview with another live coding session.

4. Tech lead round

I expected this round to be a hardcore round but it was totally the opposite. It was more like getting to know each other working styles and preferences. We spend time talking about the ongoing projects and what are the biggest challenges in their team. The interviewer did go through my resume to ask what kind of project am I working on and what was some challenges. Took some time to make sure I cover everything and he thinks my current project choice makes sense.

Some questions that I asked:

• How do you deal with an unsolved problem that might bug your team for a while but apparently has a low priority

5 HR round

A few typical behavioural questions start with "Tell me about a time...". You might want to prepare a few stories for this. Prepare a less technical interview because I had a difficult time explaining technical terms such as “crawler” to the interviewer.

Some questions that I asked:

• How diverse is Woven by Toyota holdings since all of my technical interviewers are all white male

• Why is Woven by Toyota a holdings

6 Manager/VP round

It took them around 2 weeks to schedule this round. This 30 minutes conversation contains a few short behavioural questions that focus on conflict resolution in your past experience. They also talked a lot about company cultures and key improvement areas. Because it's a very short interview and the interviewer seems really busy (stopped interview 1 minute before our time ends), I don't have much time to ask questions.

Summary

Despite the negative comment on reddit, I think the process has been improved over the year. In my opinion, Woven by Toyotas has one of the most humane interview processes compared to others. Instead of accessing candidates via crazy/stressful leetcode hardcoding, or designing a system that only scales theoretically, they do it in a better way like short take-home assignment and accessing past projects deeply. On the other hand, they took really long time for the whole process. They only got back to me after 2 weeks (yeah another 2 weeks) of VP round.

Want to save your preparation time ? Check out furustack.com to understand what you need to prepare instead of guessing.

1. HR Screen (30 minutes)

Standard HR phone call. I like how they tell you to switch off the video in the email so that you don't awkwardly turn on the video alone for the screen. This round mainly was a casual conversation around your motivation and what to expect during the interview round. I always think that if you don't say something crazy, you will be safe for the HR screening round.

2. Pair Programming Screen (45 minutes)

I really like how they approach this in an incremental way. The question goes from a straightforward one and they will add more complexity as you solve. The interviewer describe the question clearly and was a very experienced in leading interviews. They are also very open-minded, as in they let you search on Google / StackOverflow if you don't know something.

I didn't solve the last session of the question completely but we had a discussion on it and they seem happy with my thinking.

3. Pair Programming 1st round (45 minutes)

Leetcode medium question. Similar to the screening round they are obviously trained (really great to see how much effort they put in training the interviewer) and they will guide you if you are lost. You will be in a good position if you have enough Leetcode practice (100~200 should be enough).

4. Past Technical Experience

I don't have any idea what they expect in this round. Like system design round, you will be the one driving this interview, with your interviewer having less context compared to system design depending on what past project you are talking about. I presented a past project that migrate a DynamoDB cluster to Redis that solve a performance problem. They don't prepare anything for me so I asked to present my idea on excalidraw.com.

5. Pair Programming 2nd round (45 minutes)

They break the question into 2 parts this round. The first one is very straightforward and they add some complexity in the second part. They are very consistent in pair programming round. Leetcode medium question + 45 minutes, so nothing surprising.

6. QA Architecture/Design

Watch out for the email their recruiter send out. This round starts with "design an xx". But then they will let you drive the interview 100% on your own. So you need to be good at imagining things and leading the system design. You are told to show your best, so pick up the component that you are most familiar with and deep dive into it. You can show how critical you could think of if a part of the system does work well, and how do you solve it. For instance, if we only want one node (among a cluster of nodes because of availability) to run at a time, we need a distributed lock. In that case, do we need to design our distributed lock to be efficient, or to be correct?

7. QA Leadership

This is a behavioural round where you usually have to talk all the time. Prepare a story that shows your leadership (leading a project, mentoring a teammate, migrating a project) that show both technical and non-technical (soft) skill you have.

Summary

Take time to prepare, as this is a lengthy interview that needs you to think back on your own experience (Past Technical Experience, QA Leadership) and prepare for technical parts.

1. Recruiter meeting (30 minutes)
2. Hiring Manager
3. Technical interview
4. Macro Interview (system design)
5. Product, Culture and Process (behavioural)
6. Engineering Director Conversation (30 minutes)

Recruiter meeting

A short call with a recruiter to understand the interview process, company culture and how the team works in Japan. The recruiter was professional and friendly. So it gave me a very positive first impression.

Hiring Manager

It was more like a conversation than an interview, in a good way. The hiring manager is good at making you relax. This interview gives you a deeper overview of how the team works, including their collaborative and remote culture.

There will be a few questions to make sure you are a good fit and how you think about your past experience and your thought on their working culture.

Technical interview

This is a pure technical interview round. Because I was applying for a full-stack position, I was asked to design an API and did a small coding question (not too crazy).

Macro interview (system design)

I met with two engineers. I really enjoy their way of conducting system design. Instead of throwing you "Design a Twitter", they do it iteratively. They start with a simple question and add features to it. Interviewers were well prepared and they apparently want to hear different solutions from you. I tend to give too complex solutions to solve the problem but thanks to the interviewers, I managed to figure out a simpler solution. Collaborative!

Product, Culture and Process

A lot of behavioural interviews start with "tell me about a time...." but this wasn't true for CircleCI. They are interested in how do you work, your leadership experience and your past projects. I recommend you pick a story that can highlight your collaboration skills.

Engineering Director Conversation

This was a short conversation to wrap up the interview if you make it to this stage. The engineering director acts as closer to answering any questions and concerns I have.

Summary

So how to prepare for your interview for CircleCI. There isn't much to do to be honest, except being yourself. I don't think practice 200 LeetCode will help, but getting yourself prepare to express your thought and experiences might help.

They are pretty open with their hiring process, so I don't really have anything to give except writing down my experience. Overall they are good at making you relax, especially when it comes to pair programming. You are free to google anything (ahem, just like how we work) and try to make it collaborative.

1. Hiring Manager round

2. Pair programming round x 2

3. Story of life

4. Technical Deep Dive

Hiring Manager round

A lot of insights around team and products which is very helpful. They also share what does future roadmap looks like and what kind of work I can expect myself to be doing if I join. The reason that the hiring manager is spending time talking to candidates in the first round is that they want to reduce mismatch. Most of the time, you will interview with a higher position/rank interviewer, but Shopify is the opposite. They just don't think manager time is more valuable than team members time which is a very valuable thing.

Pair programming round

As I mentioned both of my pair programming rounds were fun. The interviewers were patient, collaborative and keen on learning what I am thinking. They prefer a working solution to a perfect one, so I was talking to my interviewers most of the time. It's really nice to feel that they are actually engaged and interested in what you are thinking.

I have to say you can't really prepare for this round. You can practice on LeetCode to sharpen your thinking process but their questions are not LeetCode style.

I have around 15 minutes (which is a lot) to ask questions, so I recommend you to understand their engineering culture to be able to ask better questions. One question that I asked was how do they manage one of the world biggest Rails monorepo while making sure they can ship as fast as possible.

Story of my life

I googled a bit and Shopify has a course for this. This was an interview with HR and I really enjoy that they are willing to spend time listening to my story. Of course, they are more interested in how/why/when did you start programming than what makes you a great swimmer. So preparing a story that tells how do you fall in love with programming might be a good idea.

Technical Deep Dive

To me, this round is very ambiguous. I actually don't know what to do before the interview and even after the interview. It was me telling one of my past projects. I am glad that I proposed to use some drawing tools to describe my project. I think Shopify can be more specific about this round. Things like what do they expect and what will make candidates successful should be mentioned before the interview.

Want to save your preparation time ? Check out furustack.com to understand what you need to prepare instead of guessing.

Summary

The interview with Shopify has been one of the most fun processes. Less stressful and more humane way. You don't have to study big O or practice LeetCode. It really depends on how do you approach a problem collaboratively from day-to-day. But it will definitely make your interview smoother if you are a good storyteller (=

• relearn a lot of things
• learn how to tell your own stories
• learn how to interview
• and more....

But do you ever wonder how do we learn at the best? To learn that you need to learn how to learn (yeah kind of recursive, but I promise this is not an infinite loop). There are a lot of great courses out there, including one of my favourites: Learning How to Learn. I spend a few weeks completing this course and figuring out how I can utilize the knowledge to help my interview preparation.

Focused vs diffuse mode

image source

First of all, we need to understand our brain has 2 modes

• focused mode: analytical, intense
• diffuse mode: relaxed

For example, practising LeetCode is an intense activity. Not only do you have to figure out how to solve it, in case you couldn't you have to read through the top votes comments to understand how it works. To me, I do this best when I am in focused mode. This usually happens to me in the morning and at midnight. I will get frustrated more if I try to practice LeetCode during my diffuse mode.

So, understand your brain and try to leverage that!

Spaced and Interleaved practice

Do you know why school mixes up all subjects in one semester rather than teaching one subject in one semester? Because of both spaced and interleaved effects!

Don't finish "Cracking the Coding Interview" in a week, it won't stay in your brain until your interview day. Instead, space out with other types of interviews. Learn the company cultures, design your past project story or fill your time with non-coding technical preparation. To achieve interleaved effects, you can also do LeetCode, watch video and write a priority queue by yourself.

Active learning

This is the biggest reason I help people to practice system design. You should do this with other types of interviews too. I also recommend LeetCode Timer to time yourself during LeetCode or practice behavioural interviews with your peer to switch your brain to active mode.

Why ByteDance?

• Build credibility on your resume
• Competitive salary + (pre IPO) RSU stocks
• A lot of large scale products (not only TikTok !)

Once you begin your interview, the coordinator will reach out to you almost the next day (or on the same day) if they proceed you to the next round. ByteDance backend engineer interview is relatively technical, but it's not like you have to remember dynamic programming techniques perfectly. But instead, you have to revise your computer science knowledge (which you will see below). The interviewers I've met are very energetic, passionate and knowledgeable.

1. First technical round
2. Second technical round
3. Third technical round (hiring manager)
4. HR round

All interviews were conducted online.

First technical round

The interviewer was from another team and they will mainly focus on your resume. One of the deep dives asked is how the GC (garbage collector) works on my most familiar programming language. Every GC works differently, so study it! They also go through basic data structure and ask how it works internally.

The last session of my interview is a live coding question. Nothing is difficult if you practice Leetcode. I solved the problem relatively quick, so I get another follow up question. Also, you have to know your program time and space complexity.

Second technical round

This round is also similar to the first technical round. I am lucky to have a very friendly interviewer who is interested in my life in Japan. My interviewer focus on my past project and distributed system.

I enjoy this round of coding questions because they seem very up to date (They made the story relate with COVID19). While I appreciate my friendly interviewer, he was trying to chit chat with me while I am coding. I guess it's another way to test my skill? Just kidding. My interviewer was confident with my approach as I told them how would I write my code.

Third technical round (hiring manager)

This round focus on backend knowledge. I was asked about how data structure works internally. The interviewer wants to understand if you know your data structure shit deeply, so they will deep dive. For instance, I was asked for the amortized complexity of a data structure and how was the complexity calculated.

The last session of this round is a (short) system design round, mainly focusing on scalability.

If you are interested in practising system design, we are here for you

HR round

Introduction of the companies, teams and cultures. Also, they will have conversations to understand your past experience, team structure and some achievements. One thing that ByteDance value rewards the individual who performs well, so I guess that they want to see how far have you gone in your past project.

Summary

The best way to prepare is

• LeetCode. Focus on top 100 interview question
• Computer science knowledge especially algorithm and data structure. If you have time I will recommend MIT 6.006: Introduction to algorithem
• Know your programming language, study distributed system if the position you are applying for need it

• (application user use case) What is this domain total impression last hour?
• (internal analyst use case) What is the total revenue by all customers for the last quarter?

We are going to talk about:

1. How do we collect data
2. Where do we store the collected data aka centralized system of records
3. How do we aggregate our collected data to answer questions

If you prefer video, here you go:

High Level Design

Before we start let's start with a very naive approach to understanding our data flow from a high level. The naive approach looks like this

We have an API server that's ready to accept HTTP requests from the internet. How the requests are generated is not within the scope of this discussion they might come from our own javascript tag or public API. Once we get the request we parse the request and store them into our database to provide metrics for every domain in time series we design our database table to have domain and date time as a primary keys

This approach works and could answer our questions definitely. However, they are not flexible reliable and scalable as in

• what if you want to understand the total impression for the last 30 minutes
• what if our database has an outage during the insertion of data
• is our database able to store data over 10 years 20 years for our business needs

We'll look at how we address these problems step by step

Detailed steps

1. How do we collect data

This is usually solved by exposing an HTTP endpoint. Since it is a public HTTP endpoint it means everyone from the internet is able to hit the endpoint from any source. We can have a token based authentication or if we are generating the URL dynamically we can append and encrypt the hash that contains information for our server to validate if the URL is generated by yourself. This endpoint is expected to have a high volume of traffic thus it should be responsive and fast.

The main job of this API server is to persist the log into a centralized system of record like a database which is probably through a TCP connection. Opening up a socket for every request to send data directly to the database will be time and resource-consuming. And because the database might go offline it is unreliable so it makes sense to persist the log to a local file system at first. The logging library we choose should be able to write some logs to memory and bulk append them to a disk at a later point for performance reasons. We need a background worker to send those requests to our centralized system of record at a later point periodically. One downside with this approach is we might need a bigger disk for our API server and if the disk fills up we need a mechanism to rotate them.

2. Centralized system of records

Where do we install the collected data aka centralized system of records? Our data are immutable log so most of the storage you are aware of should be able to store them fast enough since the operation is only appending. A few options we can have for our centralized system records are

• Database of your choice (Could be RDB, key-value, document-oriented)
• Distributed file system or object storage. Like S3
• Stream database A few worth considering points are durability, redundancy and single source of truth

Durability

We want our logs to be persisted one is written so we like our data to be stored on disk over memory. So no Redis (although Redis has a persistence option) or Memcached.

Redundancy

Even if it is persisted the hardware problem such as corrupted disk might lead to data loss. If the data is critical to our mission we want to reduce such risk. One way to increase redundancy is to copy data from another disk so that we could locate them on a different machine with the tradeoff of a higher cost.

Single source of truth

If anything happens at the post-processing stage there should always be one single source of truth to consume data from. This makes sure our data is consistent of course across the post-process results.

Hence I'd like to propose a solution that fulfils the above requirements: stream database. Everything new event goes into the stream and the stream will act as our single source of truth.

Choosing a stream database like Kafka will give us durability and we can replicate our data into a different cluster for redundancy one really great benefit of stream database that other systems do not have is it treats changes as events. Let's say if you want to reprocess data you can always process the data in the order that they were inserted.

3. How do we aggregate our raw data to answer questions

Let's revise the two questions that we need to answer again:

• What is this domain total impression last hour?
• What is the total impression by all domains for last week?

Depending on the questions, our solution may or may not be different, but let's discuss the 2 common approaches: online transaction processing (OLTP) vs online analytics processing (OLAP)

The difference between these two are shown in this table:

Let's dig in a little bit into each question.

application user use case: What is this domain total impression last hour?

This question is typically asked by a domain owner, that's application user.

To answer this question, we are only interested in certain data, that's this domain data. Our query will usually come with a "WHERE domain =" clause. So, it's more efficient to index the domain key.

In this case, it makes sense to design our database table schema like this

Aggregation granularity

The date field is added to help us answer the "last hour" part in this question. If we are only interested in the last hour, it makes sense to group the data by the hour instead of smaller units like a minute, second or a larger unit like a week, month.

However, if we only aggregate our data per hour, the latest data we could see would be the aggregated past hour data. There is no way to see the last 15 minutes data. Needless to mention real-time data. If that is important to our business, we might want to know how many time lags we are allowed to.

Remember, the smaller the granularity (second, minute) we will have more flexibility to answer our question. But at the same time, we have to store more rows, hence taking up more space. So, it depends

It's also very common to do further aggregation depending on your business. We could have hourly, daily, monthly aggregation to answer different queries. For old data, hourly, daily become less valuable and hence we can remove those from our database when we are not interested in them anymore.

Anyway, if we do not have an idea of what is the best granularity, 15 minutes is a good start in my opinion for 2 reasons.

• 15 minutes is a good midpoint between flexibility and disk resources. For data like stock prices, it makes sense to consume the data in real-time but even on Yahoo Finance, 15 minutes delays are not uncommon
• Time zone agnostic. In case you don't know, while nearly all countries have hourly, half-hourly time zones, Nepal and Chatham Islands have a quarter-hourly time zone (Source: https://www.bbc.com/news/world-asia-33815153). This is strange but timezone has never been friendly to software engineers =( So to serve our data globally, it's smart to aggregate our data by quarter-hourly.

internal analyst use case: What is the total revenue by all customers for the last quarter?

Unlike application users, internal analysts might want to ask a more flexible question. For instance:

• Total impression by all customers from Europe
• Average impression by each browser (detected by User-Agent)

In this case, we usually want to be able to query raw data so no aggregation will provide better flexibility. If you are concerned about the huge disk resources we have to use you are totally right. So they tend to be slower compared to the application use case. In most cases, we are ok with this because compare to application users, we will have lesser internal analysts hence fewer queries. Furthermore, LDAP is optimized to aggregate many rows of data across multiple keys as most of them are column-oriented.

If you want to understand how column-oriented databases work from a high level, this article from the honeycomb is a very good read.

So, it depends

Any way you go, you don't want to use one solution for a different problem. Both questions that we asked could be answered by OLAP or OLTP alone but if an OLAP cluster is both used by internal analysts and application users, the application user would be affected if the internal analyst usage is overloaded.

Using different workers to subscribe to our single source of truth allows us to achieve answering these questions in scale.

And this will be the design we propose to answer both questions.

One concern you might have is what if our worker that is inserting data to OLAP/OLTP has some bug and we need to retry. Or how do we handle duplicated data in our stream database? It could happen if there is a bug in API, or when our write to disk fails to respond, but we actually wrote it, and we retry again. Anything can happen.

We don't want to double up impressions because it wasn't correct. And that leads us to idempotency.

idempotency

To be idempotent, we can add a unique hash when we persist the data to the local filesystem. This could be done by though our API server.

{"url":"https://gaijineer.sh/page", "domain":"gaijineer.sh", "timestamp":"2020-10-10T15:30:20", "useragent": "Safari", "ip":"192.168.123.132", "hash": "w_kdj0192ilj12d9a0h2081" }

By using this unique hash, we have a way to detect the duplication at a later stage. For example, during our OLAP query, we can use UNIQUE in our query to remove the duplication.

That's all for today!

We are going to look at another common pattern that you can use to solve your system design question. I'll call this message queue and producer-consumer pattern. This pattern is really useful when it comes to an application that needs to deal with a lot of unreliable tasks such as networking tasks.

One of the most popular use cases is when you have to integrate with a 3rd party services like payment gateway, notification services that help you deliver your email, in-app notifications etc. These kinds of tasks are rather unreliable because 3rd party services might become unavailable.

The second use case I can think about it is to increase your application parallelism. Imagine when we need to process a very large file such as a video. Instead of having one node to handle the job alone you could spread the job load to multiple nodes so that you can process the file faster

During your high-level design phase, you could still complete the job your application needs to do without using this pattern but at the cost of low reliability and scalability. Let's talk about reliability with this super naive application managed by ourselves and 3rd party services we use

For example, let's say if our application HTTP requests fail for whatever reason. It could be a network problem, it could be a 3rd party service outage. In this situation, application layer retry might work but we can't retry like forever right since it will consume our resources and our own service might becomes unavailable during retry and this might lead to data (that we are supposed to use with the HTTP request) loss.

With this approach, we don't have a way to scale. Let's imagine that we have to deal with a large file like a video. We could only process the next file sequentially after the first process is complete t

Pros and Cons

This is when we enter the message queue and producer-consumer pattern. What are the pros and cons that you bring by introducing this pattern?

Before we interact with the party service we always have a copy of data inside our message queue and this is how it becomes so powerful. In case a 3rd party service becomes unavailable our consumer can stop retrying and proceed with other tasks without wasting the resources. In the meantime, our data will be kept in this message queue and get processed later without worrying about the risk of data loss

Pros: Reliability and Scalability

With our data get stored inside this message queue, our consumers become stateless as they don't have to persist any data. They can always connect and disconnect with the message queue at any time without the risk of losing data. This is a big win for scalability. We can always add our consumers horizontally and thus increase our system's scalability

Cons: Asynchronous communication, time lag

Of course like in life every choice comes with some trade-offs

• our programming models have to change from synchronous to asynchronous. in case you are processing a long-running task for your user, you have to find a way to notify your user after you complete this task. Communication just becomes harder

• we also introduce time lag since there will be another component between producer and third-party service

These are trade-offs that we are willing to make in most cases. Of course, you have one more failure point in the system since we introduced another component. Most of the time we are willing to give up this in order to provide our system scalability and reliability

More patterns

Separate queue

One thing that we want to consider is if we want to have another separate queue. Let's say we're integrating with two different payment gateway vendors. To be exact, let's say each of your vendors has an SLA of 95% if you are using a single queue for both vendors. Your pipeline SLA is going to be multiplied by 95% and 95% which is less than 95%

In order to prevent that we could have a separate queue for different vendors. That means each pipeline is going to get 95% per cent of SLA.

Priority queue

Let's imagine that we are designing a news system. In our system, there are breaking news and normal news which has a different priority. We want to prioritize breaking news to help our users to get the best user experience. In this case, although our consumer has to be a little bit smart aka being able to recognize the priority of each queue

At least once guarantee queue vs at most once guaranteed queue

Finally we could also mention if you want an at most once guaranteed queue or at least once guarantee queue.

If you prefer a video version, here it's

Almost every system will read some data from databases. So let's look at a very common way to scale a relational database read step by step. By remembering this approach, you could apply it to most of your backend system design interviews.

Here we have a system composed of a client, a server and a database to persist data. We will mainly focus on the database read. We'll do this iteratively. This means we'll start from one single instance relational database. As our database read requests become higher we'll see how we can improve the read scalability while considering the trade-off.

Scaling up

First of all, we should always mention scaling up vertically. Scaling up vertically means adding more resources to your database instance. However, this approach will hit its capacity limits as it is capped by the hardware resources. For example, the largest memory-optimized instances of Amazon RDS(at this moment) is db.r5b.24xlarge

Read replicas

This is when we want to introduce read replicas.

Adding more read replicas, our database is now more capable of accepting more read requests. Also, since we separate our write and read instances, it increases our system reliability.

If our write instance is unhealthy, we can still serve our read requests through our replicas.

However, our application server now has to figure out which replica we have to read from since we have more than one replica. And we want to make sure the read requests are distributed evenly across our instances

The biggest challenge though is replication lags, which means we might not get the latest data before replication between leader and replicas are completed. So users might see outdated data like older profile pictures. However, in most cases, we are willing to sacrifice this kind of inconsistency with scalability

Replicas, they are nice. But it doesn't mean they are indefinite. Relational databases have group limit on the number of replicas you can set. So as our read request becomes higher and higher we are going to hit our replicas group limit.

Memory cache

Right now we will add a memory cache layer in front of database. If the data we want to read is in the cache we could avoid hitting database directly. Also, since memory is faster than disk. So it will decrease our system overall response time. It will also be beneficial to show your interviewer that you know the common latency.

However, similar to the replication lag we have to deal with data inconsistency. And since memory is not cheap we have to plan our memory capacity accordingly. If there's a number you can always do a quick calculation during your interview.

Let's say you want to store a list of user id in our memory cache We use integer type which will take 4 bytes of our storage and let's say our daily active user is 10 million

4 bytes * 10 million = 40 Mbytes

And we'll need 40 megabytes for memory cache which is a reasonable size. So I think we are good to go.

If you have time you could also mention about cache strategy that you will use. One common strategy is cache aside pattern or lazy loading. Most of the time, adding a cache layer with enough consideration should be more than enough.

Federation

If your interviewer doesn't stop we could talk about federation and sharding strategy Let's talk about federation. Usually, federation means splitting your entity into different databases.

By introducing another cluster of databases we are now capable to scale more read requests. However, we might lose all the benefits that a relational database provides like the ability to join while we are creating it. Also, we might have to deal with transactions across databases

Summary

So I have walked you through a few steps to scale database read as our request increases.

If you are looking for system design interview like this, you should check out systemdesign.gaijineer.co

• 10 + 15 + 25 minutes
• The 10 minutes left are buffers for introduction, minor technical problems, Q&A which usually doesn't affect your score

10 minutes: Clarification of the requirements

Different companies want a different thing. So you have to clarify unless they give you very detailed instructions. Some popular questions/assumptions look like

• Could we just focus on the backend?
• Are there any non-functional requirements?
• Does it make sense to assume we will have more reads than writes
• Is it ok to use 3rd party service for our payment gateway?
• Do we need to support multiple languages?

For estimation, confirm with your interviewers because not every company wants a number. Unless you are asked for, skip the estimation step to save time for other steps.

15 minutes: High-level design

The goal of this step is to provide a big picture to show that we fulfil the functional requirements. At the end of this step, both you and your interviewer should have a general idea of how the data flow from request to response. Some common things you could talk about are:

• An illustration of your simplest architecture (could be client -> server -> database in some cases)
• System interface
  • API (HTTP method, what your endpoint does)
• Databases
  • what kind of data do we want to store
  • what kind of databases and why (Relational, Key-Value, Graph, Search...
  • schema
  • (if you do estimation) figure out how much disk space do we need and see if that makes sense
    • For instance, storing TB sized data in a single relational database instance doesn't make sense (ref: Amazon RDS instance types)

To save time, skip talking about optimization, scaling etc. So no load balancers, no replicas at this point.

25 minutes: Detailed components, optimization, all the goodness

This is where you want to spend most of your time because

• Compared to high-level design, which might look similar across different titles (think TikTok vs youtube), interviewers are most interested in how deep could you go for the current title
• a place to show off how knowledgeable you are

Always confirm with your interviewers which components are they more interested in. This is the step you want to mention:

• How to scale your read and write
• Add more logic to help your system grows:
  • compression
  • an algorithm like splitting files into chunks etc
• adding more components/logic to help your system grow. For instance, message queue, CDN etc.

Buffers

If you have more questions than time allowed, it's ok to ask your interviewers to stay more for a few minutes. I did and so far no interviewer rejected.

Despite the opportunities, there aren’t a lot of information regarding the software engineer interview process in Japan. Many discussions on Glassdoors, leetcode focus mainly on big companies like FAANG. There are a lot of resources out there but to be honest some of them are overkilled. So hopefully I could give you some insights regarding the technical interview process here, and how I prepared them. The interview process of course varies from company to company. However, in 2021, I applied for more than 10 companies, went through more than 40 times of interviews. So they should cover a lot.

While being one of the weirdest countries, the software engineer interview process here is quite standard. For non-local tech companies, their process is similar around the world. Except that your interview might be conducted in the early morning or late evening because of the time zone. Or if you do not speak Japanese you might have to talk to your interviewer via an interpreter.

Live Coding / Whiteboard

Practice on leetcode is the best thing you can do. It really depends on you but I practice around 200 questions. Although some companies offer non-leetcode style coding interviews, in the end, they want you to solve a problem by writing code in front of interviewers under time constraints.

Take home assignment

This is a fair process. As your future potential employer, they want to see your ability to write code in a less stressful environment. One caveat about this is some companies have a larger scope of the question and you might have to spend a lot of time on this. Because you don’t know how hard should you try. Personally, I am not a fan of taking home assignments but it’s better to do this under time constraints. Most of the time, these assignments are what you are familiar with. Generating CSV reports, designing an API are a few examples. Besides, understand your own code really well, I don’t think there is a lot of preparation you can do.

General Computer Science Knowledge

This is a rare one but there are few companies in Japan that do this. Basically, they want to test your general computer science knowledge. A few examples of these kinds of questions will be “what is ACID”, “what is the difference between UDP and TCP”. By “general” it could be anything. From database to disk to network to virtualization to consensus algorithm.

A few books I had been reading multiple times including:

• Designing Data-Intensive Application: Database, distributed systems
• High Performance Browser Networking: Networking (Chapter 2, 3)
• Systems Performance: Enterprise and the Cloud: OS

System Design

Interviewer: Design a NewsFeed

Because there is no right answer (but you can give a lot of the wrong answers!), this is one of the most difficult to prepare. I can’t stress out how important is this round because it could affect your offer at a great impact. You can still pass your interview if you perform averagely in this round. However, if you are outstanding, you might end up getting an offer with a higher engineer rank (which usually needs promotion if you start working in the company). I recommend you to resources like:

• Bite Sized System Design Videos (video course by me)
• system-design-primer
• System Design Interview — An Insider’s Guide

Despite the great resources, you need to output what you have been disgesting to measure how much you know. And to achieve greatness, not only do you need to know as much as approaches and their tradeoffs as well, you need to think hard during your interview. Usually, after you have a high-level design you will be asked to make your system more reliable or scalable. Everyone has different opinions. So does your interviewer. So doing these interviews with friends or colleagues are the best way. Also, I found it was weird to talk to myself along with my practices so you really need help on this. Some companies, test your system design knowledge by asking you to describe your past project (for instance: Shopify technical deep dive)

To be honest, it’s a good time. Not only a lot of tech companies are hiring non-Japanese speaking software engineers, but Japan is also one of the top-paying markets around the world.

Subscribe to my newsletter for more things topics like this

• Exciting scale: 1000 Transaction/s on 2021 (source)

• Work From Anywhere at Anytime (WFA)

• Competitive salary

It took me 3 weeks to finish the process. While I am not allowed to tell you everything especially PayPay interview question, I will try my best to describe the experience.

1. Codevue online coding test

2. Phone Interview

3. Loop Interviews (x4)

4. Talent Acquisition round

Codevue online coding test

Time is valuable. Do things fast. To be fast, you have to get used to common operations. Like hackerrank etc, codevue coding test starts by reading input from os.Stdin and writing output to os.Stdout. So you have to get used to parse a string into a data structure in your programming language and vice versa fast. For instance 19.24,20.00 to [19.24, 20.00]: Array[Float] Practice how to use the standard lib of your programming language to do this. (If you use Go then strong, strings are your friends. Or better go practice in hackerrank)

Finally, if you are stuck, you are allowed to fmt.Printf or console.log. I was stuck during my second question for a few minutes and having my coding recorded I was hesitant to debug it the hard way. I debugged it by using “fmt.Println”, solved the problem immediately and passed! The best way to prepare this is no other than leetcode.

Want to save your preparation time ? Check out furustack.com to understand what you need to prepare instead of guessing.

Phone Interview

It is said 45 minutes but actually, it was 30 minutes + time for me to ask questions. The interviewer seems busy because he tries to end the interview at the 30th minute. This round mainly goes through your resume to make sure you know things. I heard that there are some candidates who have coding tests in this round (on Google Docs ?!?) but I didn’t.

Loop Interview x 4

While they might suggest you finish the loop interview in a day, I would suggest you avoid it. Because it’s draining. Give yourself some break between the interviews.

Loop Interview 1 (Programming knowledge)

I was interviewed by one of the team lead. Young, passionate and very friendly. This round starts with testing your most familiar programming language. Garbage collector, data races topics etc for around 30 minutes. Another 15 minutes was used to solve a leetcode question.

Loop Interview 2 (Data structure and algorithm)

Worst round because I don’t actually know what they want. They describe a case and ask what’s the best data structure for that. Then Big O topic. The interview then continued with a leetcode question.

Loop Interview 3 (Backend knowledge)

This is the only round without any coding. But it asks everything a software engineer should know. From networking to Linux to Database to container to a distributed system. Expect questions like “what happens when you open an URL from browser” and “explain ACID” A few good resources that I find really helpful are

• Systems Performance: Enterprise and the Cloud, 2nd Edition (2020): Models, Concepts, Architecture of every chapter are your alliance

• High Performance Browser Networking: Chapter 2 ~ 4 are your friends

• Designing Data-Intensive Applications: Chapters 2, 3, 5 ~ 9 is for you You are not expected to answer everything perfectly, so feel free to let them know you don’t know so that they can move to next. Luckily for me, my interviewer was very knowledgeable and willing to teach, so while I might not answer everything, I learned a lot.

Loop Interview 4 (System Design)

Interview with one of their senior manager. In this round, they will revisit your resume, have a coding session and finally ask you to design a small system. That’s a lot. I told the interviewer I have seen the coding question on leetcode so they pulled out another one which I also have seen on leetcode too but I decided to move forward because it was an easier one.

Summary

You can see that most of the interviews are general knowledge + one leetcode. So, to prepare well:

1. Read a lot especially the book I introduces

2. leetcode

3. For system design please check out http://systemdesign.gaijineer.co/

Want to save your preparation time ? Check out furustack.com to understand what you need to prepare instead of guessing.

• Competitive salary

• Great engineering culture

It took me a month to finish the process. While I am not allowed to tell you everything especially SmartNews interview questions, I will try my best to describe the experience.

1. Online coding test

2. Talent Acquisition/HR round

3. Programming round

4. System design round x 2

5. Backend domain knowledge round

6. Behavioural round x 2

Online coding test

There will be 2 hours for you to solve 2 leetcode style problems (easy ~ medium). Should have more time than enough if you practice your leetcode well. I finished both questions within 45 minutes. They evaluate via score but you never know what is your score during the test so optimize if you have time.

Talent Acquisition/HR round

Nothing to talk about. The HR will guide you through the interview process roughly (I believe my post will do better) and present you with company cultures. Might be a good time to clarify culture but you will have more time later.

Programming round

Not my favourite interview round especially they made me write my solution on a non-executable code editor. I have no way to verify if my code is working and I was asked to explain my codes step by step to my interviewer. I didn't come up with the most optimum solution. The interviewer had a hard time understanding my code, most probably the answer I gave wasn't what he expected. The best way to prepare this is no other than leetcode.

Want to save your preparation time ? Check out furustack.com to understand what you need to prepare instead of guessing.

System Design Round 1st

You will get a huge topic like "Design a youtube" and you have to drive your design from there. You should be familiar with a lot of system design concepts to pass through this round. My first round was really huge topic and it took me some time to clarify and complete high-level design. Time was up before we could discuss any topic in detail. The ability to engage your interviewer to ask questions and the ability to drive your own solutions play a very important role in this round.

System Design Round 2st

Unlike 1st round, this round is a more narrow topic. This round interviewer is one of the nicest interviewers I had met. The interviewer started the interview by clarifying something on my resume (which means he read my resume. Or he tried to show me that he read!). The process is an enjoyable one because the interviewer makes me relaxed by telling me that from now on we are teammates, we are going to design this together and present it to other people later. Although I have to lead the design, when I asked questions not only he that told me his opinions, but he also clarify the reason behind it. During the process, the interviewer tried to lead me by asking the right question, where it doesn't seem like the solution he wants but he ends up saying "yes that will work !" because it was something that makes sense. We ended our system design interview after 35 minutes and he spent the rest 25 minutes answering my questions. System design is the most critical process in the SmartNews process, so preparation is the key. I would recommend you to checkout systemdesign.gaijineer.co (my own product) to help your preparation.

Backend domain knowledge round

This round wants to test how broad your computer science knowledge is. From your favourite programming language GC to the database to distributed system. This round of interviews has a lot of similarities with PayPay so if you prepare well you can tackle both at the same time. A few good resources that I find really helpful are

• Systems Performance: Enterprise and the Cloud, 2nd Edition (2020): Models, Concepts, Architecture of every chapter are your alliance

• High Performance Browser Networking: Chapter 2 ~ 4 are your friends

• Designing Data-Intensive Applications: Chapters 2, 3, 5 ~ 9 is for you

Behavioural Round 1st round

To go through this round, you have to be able to understand what is your motivation (social impact, engineering culture etc) to join them. You also have to show a certain interest in their product and understand how their business model work to help you. Overall I feel like he is looking for particular answers the interviewer has in mind. Which made the interview a bit stressful because behind my mind I have to figure out what does he want and try to impress him. I feel like I cannot be myself for 100% and we are not having genuine conversations. However, he spent the last 20 minutes answering my behavioural questions patiently and I am satisfied with his answer. He is not the friendliest interviewer but he is honest, straightforward, open-minded and has a great idea of what he is looking for.

Behavioural Round 2st round

Besides typical behavioural, this round also wants to see if you have done any leadership work that involves complex projects. You might get a higher rank if you do well in this round. My interviewer was wearing the mask all the time so it makes communication harder through Zoom. My interviewer gave me the impression that they are busy. Trying to finish the questions all they want to ask instead of focusing on what I say and making real conversation. A few times, my conversation was cut off. In the end, I have 5 mins to ask questions and most of those answers are short without much more elaboration. I would probably make him fail if I were the interviewer.

Summary

You can see it's a rather long process.

• Read a lot especially the book I introduce

• leetcode

• For system design please check out http://systemdesign.gaijineer.co/

• Understand the company culture and practice behavioural

Want to save your preparation time ? Check out furustack.com to understand what you need to prepare instead of guessing.