Prologue

Hi everyone, how's everyone doing? It's been a while since I've written another blog. I'm doing good :) This May 2025, I'm graduating and happy to announce that I'm starting my employment at Igalia this June hacking on compilers :)

Igalia is a "worker-owned, employee-run cooperative model consultancy focused on open source software" and I'm so happy I am accepted and offered to work here. I'll be working remotely from home, hacking on compilers :) Besides the diversity and the worker cooperative model, family and work-life balance also play a huge role in my life, hence my pick for Igalia.

During my compiler-focused recruiting time, in interviews, I got asked a lot of compiler-related questions and I felt really under-prepared for them. I have some experience in compilers, but there wasn't a database like leetcode that you can turn to to practice and hone your compiler skills. I want to write this article to talk about compiler (related) questions asked in interviews, to share with everyone who's looking for a junior job; maybe it can help you with your compiler recruiting.

I want to also extend my acknowledgement to everyone who believed in me and supported me throughout, including, but not excluding:

• My family: you already know what it is haha
• Emi & Noah: for being there for me, for sleepovers, and helping me with offer decisions :)
• Lizzie: your mom hhahahah
• Tim: For your help in the Igalia process.
• Ish: for your "youll b fine" and "itll b fine" affirmations :)
• Quân: for Yosemite and for everything since 2023.
• Carol: For your acceptance and support to me during Fermilab's CCI and SULI program. You helped shape my early-early-early career.
• Eduardo: For befriending me and for shuriken-analyzer :)
• Antonio: For referring me to mmm and nnn :)
• Arthur: for your support during GSoc and GT.
• Josh: For referring me to different companies, helping me with offer negotiation and going on walks with me :)
• Nicole, Roger and everyone for your patience.
• Brian and James: For our little biweekly virtual meet up since Fall 2023 :)
• Max & Audrey: for your CS265 class and for SIGPLAN-M :)
• Jasmangle: for chatting with me through the hiring cycles and helping me with my leetcode.
• Ahmad: for chatting and being dumb with me through the latter half of the recruitment cycle.
• Barbara: for practicing Leetcode with me (fall 2024).
• Sriram: For your reference.
• Iman & Yaron: For referring me to xxx and yyy :) I'll always be grateful to you.

As is tradition :) I also want to recommend two songs for this article. One is Iris by Ashes to Amber and the other one is Strawberry Sunscreen by Lostboycrow.

Both give my heart this feeling that summer is coming through soon; that the heat of youth will strive again and that I'll be on the beach again :) I guess now you know which season is my favorite :)

The article is around 5800 words, with the reading time around 22 minutes. I hope everyone enjoys :)

Introduction

It's often discouraging as a new grad to feel like no matter how much effort you put in, it's never quite enough.

In this currently dire and over-competitive economy, once you apply for a role, it's hard to compete and get past the OA stage; once you get past the OA stage, it's hard to compete and get past the résumé screen stage; once you get past the résumé screen stage, it's hard to compete and get past the interview stage.

Companies are asking (compiler) questions that are often not addressed in your average compiler class, and it's hard to be prepared for them; you ask ChatGPT to prep up some questions for you, but it doesn't seem to go into details much. In this article, I want to put together all the (compiler related) questions I've been asked so that you can hopefully get a head start in your recruiting.

Company names will be replaced by names of dishes for anonymity reasons, and to also avoid tunnel-visioning. There won't be any name-dropping. There also won't be no behavioral questions mentioned. Interviewers will be addressed in the commonly used gender-neutral pronoun they/them.

All the code I have written for the interviews (including pseudocode) is in C++17/20.

The questions compiled here, as well as my perspective on each interview round, have been written since November 2024.

If a question doesn't have a hint, that's because the answer is either too broad, too personal, too hard or the hint might have been too obvious.

If a company's process doesn't have any result, that's because of the company's anonymity as well as to avoid tunnel-visioning for readers.

Pre-December 2024

During this time starting between Aug 2024 to December 2024, my mind was still dull and unsharpened. Limited interviews and leetcoding from the previous year have frozen my leetcode, technical and behavioral interview skills. I started and had been doing leetcode on the daily throughout the timeline to get back into the game.

Having bought leetcode premium (for editorial viewing), I also joined the leetcode discord server to help keep me in check. Back then, I also did every daily problem on the leetcode website. It's really cute :) You get to have a medal at the end of the month if you don't miss any day; they also have two rewind tickets for you if you miss a day. I also focused a lot on easy and medium, and oftentimes I came back to the same problems multiple times to imprint the problems in my brain.

By the time the pre-December period ended, I would have done around 350 leetcode problems.

Beginning of August 2024, I hadn't yet taken any advanced compiler course, nor had I been focused on my own toy compiler project. The GSoc project for gccrs had just started to wrap up; with now only two compiler projects, I was still struggling to frame my résumé in the best light for potential compiler employers.

Pad Kee Mao

One of my first interviews for the recruiting season. 4 rounds of technical interviews. The company really loves leetcode-typed questions.

Round 1

Question is Leetcode 1462 - Course Schedule IV

A classic graph traversal problem that's solvable by DFS or BFS. I read the problem statement and coded up the solution, step by step explaining it to them.

There were some bugs in my code. But I debugged it and fixed it right away. After the code passed the test case, the interviewer asked how I can speed it up. I answered by using cache on the edges of the graph. The interviewer then explained that caching was good but hinted that caching on the nodes of the graph was more efficient. I paused for a bit, asked them to explain to me why caching on nodes is better (lol). After a minute or two, I agreed with them and provided pseudocode for the implementation.

Shortly after this, we ended the interview.

Round 2

Question is Leetcode 40 - Combination Sum II

Another DFS problem that's powered by backtracking. I think anybody who's done some leetcode has seen it. Personally, I'd recommend readers to also solve Leetcode 17 - Letter Combinations of a Phone Number and Leetcode 2787. I spent around 10–15 minutes to walk over an example, asked the interviewer about the constraints as well as coding up the implementation.

There were 2–3 followup questions:

• What is the time and space complexity of this? (Hint: constant time for an upper limit on the input size, but please explain this in detail)
• How do we make sure we don't waste time computing the combination sums that doesn't have an answer? (Hint: think about the comparison between the sum of all elements and the target being asked)
• Given a big list of elements to sum up, and a large number n, and around 1000–2000 machines, at a high level, how would you parallelize this? (Hint: think about when you first split up the big problem into smaller subproblems, how that exposes the independence between them.)

Although the interviewer didn't ask me about the time and space complexity when the input isn't bounded, I think it's a good exercise to try and figure it out. Some pencil and paper would suffice.

Round 3

The interviewer started with non-leetcode questions, then they transitioned into leetcode questions.

• (Why is)/(Give a reason why) hardware important for faster inference of machine learning models? (Hint: think about information/memory traversing time in the hardware, how custom hardware can make this better, don't be afraid to ask ChatGPT for some help, I did it after the interview ended, you might as well do it before the interview hahaha)
• Leetcode 198 - House Robber - A simple 1d-DP problem.
• Leetcode 2016 - Maximum difference between increasing elements

Follow-ups on leetcode questions were still the same: "what's the time and space complexity?"

Round 4

The interviewer provided me with the schematics for the untyped lambda calculus syntax and asked me to code up a recursive descent lexer/parser combination for it. I was kind of taken off guard by the question a bit. But I had been hand-writing recursive descent parser in my compiler project as well as for gccrs, so I kinda got the general idea.

I was relieved (?!) that they didn't ask about operator precedence climbing as well as Pratt parsing as I didn't get into them until after December 2024.

In this economy, it's hard to know what questions will be thrown at you. Please be prepared for operator precedence climbing and pratt parsing by implementing a simple calculator with +, -, *, /, (, ) yourself. As they always say, it's better to learn in the practice exam than in the exam itself.

I heard back a week later that I didn't get the job. The lack of behavioral preparedness, together with the nervousness, got to me.

I was quite desolate and crushed. That week, each breath was shaky and heavy.

Post-December 2024

The post-December era seemed like Luffy's post-timeskip in One Piece.

Interviewing with a lot of stray companies has made me more indifferent, more efficient and better at the recruiting process. Ghosting or generic rejections don't bother me as much. Rejections just mean there are better candidates than me; they are a much better fit than me, and that I need to strive to better myself more.

I learned that in a competitive market, it is important to market oneself to the employers. Thus, I polished my website and published a lot of blogs, and posted them on LinkedIn, X, bluesky for visibility, meanwhile advertising in each blog article that I am actively looking for a full time compiler job. For LinkedIn visibility, my school offered a free 6 months of LinkedIn Premium, which boosted my viewership. An employee from a company has reached out, as well as recruiters from top companies to offer referral or advancement to bypass OA and straight to the interviewing stage. More often than the other way around, I reached out to employees myself, and had secured a few referrals for myself.

It is important to keep on improving and advocating for yourself, especially in an over-saturated market, whether it is through your projects, leetcode, résumé or general marketing and networking. I can't stress that fact enough; please never forget that.

I am much more confident in my interviewing skills now. My résumé's also been much more refined with my graduate class project. By the time I wrapped up my recruitment process, my leetcode count has hit 520+, compared to the pre-December period of ~350 leetcodes.

Macaroni and Cheese

3 rounds of technical leetcode interviews. I'm beginning to be convinced that companies really like leetcode questions, even in compilers.

Round 1

A leetcode-styled question on a string-stack-parsing problem.

Given a string of "add(mul(5, 2), 3)", produce the final numeric answer.

Hint: if you're a compiler person, at a high level, think about this in terms of phases, from the perspective of lexing tokens first, and then transition into parsing.

The interviewer then asked me to provide the complexity of the problem. End of round, they asked "which area interests you the most in cs," of course the answer is "compilers" hahahaha. They also asked "outside of your technical areas, what do you enjoy doing." I said "reading up on social issues and technical writings."

Round 2

Another leetcode-styled question, this one is named "Bit-flip."

Given a monochrome bitmap represented as a flat array of bytes, with one bit per pixel, flip it horizontally in-place. The follow-up question was "if you have a lot of requests, what kind of optimization/parallelization can you perform?"

The problem was 3-fold. It tested if the interviewee could map indices from 2D array to 1D array. It then tested if interviewee was comfortable with bit manipulation. Finally, it tested the interviewee's ability to parallelize the problem.

Round 3

Weww, it's raining BFS and DFS everyone. This time it's another modified version of an official problem that I know of: Leetcode 63 - Unique Paths II

I didn't have much passing impression with this round, just the fact that we bonded over our usage of vim/nvim in our daily work life :)

Sinigang ng hipon

Interviewers in this company asked a lot of tricky and hard problems. Some are straight examples of compiler optimization, some are leetcode hards, some are related to compiler + AI.

Together with Takoyaki and Honey Almond Cream Cheese Bagel, the three companies asked really hard and creative questions, all have caught me off-guard in different ways.

Round 1

Given a sequence of matrix multiplication (for example, in a convolutional neural network), optimize the order of matrix multiplication such that we use the least amount of memory other than the pre-existing memory used to store the matrices.

For example;

A = ARR(12000x7)
B = ARR(7x3000)
C = ARR(3000x9000)
D = ARR(9000x15000)
E = ARR(15000x2)

Result R = AxBxCxDxE.

To obtain R, should we do BxC first? or CxD first? How about AxB?

Please algorithmically figure this out.

This problem (Matrix Chain Multiplication) can be solved in $O(2^n)$ time naively or $O(n^3)$ time with dynamic programming. There are also an $O(n\log n)$ solution and another $O(n)$ approximation solution. I rank it a leetcode superduper crackhead hard. I could only come up with the naive solution. Personally, I struggled to understand the reasoning behind asking this question; there are more productive and efficient ways to go about testing an interviewee's knowledge and skills.

To make up for my lack of AI skills, the interviewer then gauged my knowledge of the compiler's middle end:

• "Have you worked on any SSA form in your project or experience?"
• "Explain to me common subexpression elimination (CSE)"
• "What kind of compiler optimization have you dealt with?"

Round 2

Another leetcode hard, this time it is Leetcode 127 - Word ladder.

I have done the problem 2 or 3 times over, and was able to answer this.

With my high level answer (and code) containing an std::unordered_map of std::string to set of std::string as pseudo-edge between a pseudo word and the original words as follows, the interviewer then asked me if there were any way to optimize the space usage:

std::unordered_map<std::string, std::unordered_set<std::string>> dict;

for (auto &word : wordList) {
    for (int i = 0; i < word.size(); i++) {
        auto transformed_word = word.substr(0, i) + "*" + word.substr(i+1);
        dict[transformed_word].insert(word);
    }
}
...

I then told them we can turn the std::unordered_map into a trie, and that we can map a transformed_word to an std::unordered_set of std::string_view instead of constructing a full string everytime to optimize on space.

In this round as well as round 1, in retrospect, I don't think I could come up with the (efficient) solution without seeing them previously. It is sadly the current state of affairs in an employers' market.

The interviewer also asked me stuff about C++, a few examples are: "what's a smart pointer?", "when you first construct a unique ptr, it assumes the ownership of object, yet you can still assign the construction of that unique ptr to a variable, why is that?" (Hint: std::move and rvalue), "How do shared ptrs work?" (Hint: reference counting).

Round 3

The interviewer started off with "how would you lower a convolution down to some specific architecture or to a lower form of IR?" (Hint: I actually have no hint. I don't know how to answer this question...)

Interviewer also asked about my projects with GPU and AI. I didn't have much experience in the areas and thus could not answer either question. I transferred to UC Berkeley 1.5 years ago and could only have so much time to learn so many different courses; sadly, compilers and algorithms were prioritized instead of GPU and AI. I was still trying to improve in the area and was feeling pretty defeated. The interview ended shortly after.

Honey Almond Cream Cheese Bagel

Round 1

The screening round (round 1) started off with Leetcode 509 - Fibonacci - simple, but you'll soon realize :)

This round was designed to test the interviewee's software engineering skills and practices. A lot of refactoring was needed throughout all the iterations. I'm glad I know vim pretty well to handle all the code changes.

Interviewer asked me to implement the naive, recursive approach. Then moved on to ask me how I would test them and asked me to come up with different ways to test this. They also asked me to make sure the test wasn't just reusing the linear pattern: testing $f(1)$, then $f(2)$, then $f(3)$ as the implementer could easily exploit the linear nature.

I said let's break the fibonacci instance recursively into its sum. like $f(3) = f(2) + f(1) = 2(f1) + f(0)$ and test each of them (P versus NP much anyone?!), despite me not knowing how to actually break it up hahha.

They said this could work. But another (easier) way was to perform randomized testing: pick a number randomly in a range and test it; repeat this for $k$ times.

They then asked for the complexity of recursive fibonacci and asked me to code up the caching scheme for the version. I said this is $O (2^n)$ from the master theorem, or we can see that each time, we recomputed the subproblem twice, leading to $O(2^n)$.

They asked me for my choice of types as input and output to the function. What would happen user put in negative number? I proposed uint64_t in C++ and then they asked me "why not just use unsigned." I said that different platforms might have different meaning for unsigned, that "I felt really weird about using unsigned", and that "users might have chosen to use our fibonacci library over our competitor partly due to the reliability of our implementation. If they can't count on the fact that different platforms with the same library will provide the same result, I think that speaks to us and our software engineering practices."

We switched to a different direction. They then asked me to do the iterative implementation. I admittedly used a different naming convention for my variables, and I think that must have made the interviewer think I was struggling. They directed me to have two variables, now named current and prev. During this time, I really felt I've nailed it down, so I took initiative, asked the interviewer to trust me and let me code the implementation.

Things slowly got more complicated. They then asked for the iterative version's run time and memory complexity. I was also asked to test the iterative version as well, so I then had to refactor the original test to accept a callable instead (with std::function). I embarrassingly needed the interviewer to remind me how to embed a function signature to a function parameter, as I didn't remember the old school way with function pointers in C++.

Interviewers then finally asked me, "is there any other way to speed this up?" I thought they meant complexity-wise, so I answer "yes, with matrix multiplication this goes down to $O(log(n))$." They indicated they were more looking for this behavior "User calls $f(1)$, then calls $f(10)$ then $f(20)$. How to speed up?"

I then proposed that we used C++'s std::map<uint64_t, uint64_t> to handle this: binary search to the smaller and nearest cached instances to the current input and start the computation from there.

At this point, the interviewer indicated that they wanted a language-agnostic name for the data structure, to which I refined on and answered "binary search tree."

The interviewer seemed satisfied, and we ended this round of interview. I went over the time limit by a few minutes.

This round, as well as the next two rounds, are all highly interactive and advanced.

Round 2

This round tested my practical knowledge in the middle-end and back-end phase.

The interviewer gave me a piece of code that involves a for-loop, together with array accesses in said for-loop.

fun DoYouKnowTheMuffinMan(arr: List<Int>, info: List<Int>) {
    for (i in 0 until arr.size) {
        println("Element at index $i is ${arr[i]} with info ${info[arr[i]]}")
    }
}

They told me that "this is a safe language, so array accesses, when lowered into assembly, will need to have a branch that jumps to a section of code that handles error."

After the information, they asked me to "please lower this into assembly, you can ignore $\phi$ nodes but keep in mind about the SSA value. When lowering, remember that you will need to create a branch and a jump section for the array bound access."

They also specified that the language also has overflow checking on its integers, and that "show that via some compiler optimization, the compiler can guarantee that the overflow check on i=i+1 in the IR never happens, thus speeding up the program considerably."

After all this, depending on my jump assembly section ordering, they asked me to explain why different placements of the jump assembly section might affect the execution speed of my executable in my CPU (hint: this depends on the branch predictor, cache size of the CPU as well as pipelining?!).

Round 3

This round was all about the front end as well as the general type-checking.

The interviewer asked me about the different phases of the compiler and how it works (front-end, middle-end, back-end). They also wanted to know which phase I was the most comfortable with. I told them front-end and middle-end, but I was willing to dabble in and learn anything.

The interviewer then asked me about my toy compiler project, and what I plan to do next with it. I told them, "I probably would want to implement a type checker in the compiler." They then iterated on this, saying "ok, how would you assign types in your language initially." After a little bit of thinking, I told them "after the parsing and AST construction stage, I would assign types, for example, a NumberExpr would probably get a f64_t type."

We moved on to talk about if-else type checking. They wanted me to provide pseudocode (in a CoderPad) that type checks an If-else expression. I had to quickly make up a struct-like version of the If-Else expr, gave them the high level overview (of what a laywoman thinks) on what it means that an if-else expression is checked successfully. I asked them a lot of questions about the language's syntax and the assumption that I could make behind the type system.

💡Jas here with more hints💡. A few examples you can ask are:

• "Has the visitor (and walker) pattern been implemented for me?"
• "Have the types already been assigned for me, so I can just check them?"
• "Can I assume I can just call some function named get_type() to get the AST's type?"
• "Can I use Rust's smart enum for the sake of elegance instead of C++'s crude integer enum when typechecking?"
• "Can I skip this interview because it's too hard?"

Be sure to not assume too much, because by then the interviewer could grade your abilities as "not good" since you have nothing to show for yourself. Asking good assumptions is a skill to be trained for.

For visualization, I typed something similar to this for the AST's struct:

struct IfExpr : public Expr {
  Expr* m_cond;
  Expr* m_then;
  Expr* m_else;
  ...
  // after this, struct depends on what interviewer answers about the assumptions
};

They then followed up with "given two types A and B, how would you find out the lowest supertype (LS) of those two types?" After this, they then followed up on the followup with "now that you have a way to find out the LS of 2 types, with this tool in mind, how would you go on to check the LS of k types?" (Hint: Draw out a diagram as a tree representing all the types in your language, with the supertype of all types at the root of the tree.)

We then ended the interview.

Introspection

In all rounds at Honey Almond Cream Cheese Bagel, I struggled through round 2 the most. I got all the knowledge needed to ace the round, but nobody had told me: "this is how you combine everything together Jaz." I'm glad I went through the trials.

This company featured the most interactive interview style in the whole line up, just a bit behind Takoyaki. A lot of the questions being asked in this company's interviews really made me think hard about my answers. It's clear to say their challenging questions blended perfectly between practicality, depth and theory.

Looking back, I think working more on my toy compiler would have helped a lot. If I had implemented a simple bidirectional type checker for my compiler, the if-else expr type checking question would have been easier—I could have been more methodical in my answers. If I had enrolled in one of our school's upper divisions in "software-hardware architecture" instead of "randomized processes and algorithms," answering the question on assembly lowering could have been smoother. Ah well, maybe one day when martingales show up in compilers :) Whatever, we work with what we have :)

It was also during this time period that I realized not every answer needed to be perfect. Oftentimes, as long as I managed to spell out the keywords that the interviewers were looking for, or as long as I was progressing towards the goal, interviewers were willing to guide me to get to the question's answer myself.

The recruiter thankfully gave me very helpful feedback: "you have some of the skills the team is looking for, but it's not there yet." I was grateful for the recruiter and the team's honesty. Needless to say, what followed next was a rejection.

As I'm writing this article, I shudder to think about my past selves and all the times I've been rejected: "I hope the past Jasmine didn't attribute her self-worth to a result of an interview process." I hope you don't either - we play the card we're dealt with, and refuse to let them define us.

Takoyaki

The Takoyaki company process was completely different from the rest of the line-up. If Honey Almond Cream Cheese Bagel wanted to gauge my skills through providing actual pseudocode for simulated problems, then Takoyaki opted for high frequency of questions in randomly different areas that were tailored specifically to my résumé.

Interviewing with the company felt like talking to a colleague instead of being quizzed on a test with leetcodes. I felt like I was also contributing to the conversation, it was amazing :)

The Takoyaki was also one of the few companies that really hold in respect their transparency. They clearly set the interview expectation, told me straight from the start, "there won't be any leetcode, we're gonna talk about your résumé," and talk we did!

Gosh I hope I'm not gushing over Honey Almond Cream Cheese Bagel and Takoyaki too much. At least now you know which of the listed dishes are my favorites (together with Phở of course) :)

I also like redbull :) if you like this article, maybe consider buying me one ? :)

Round 1 & 2

The company seemed really interested in trying to know me as a person, through my résumé as well as my thoughts on certain topics. As a result, they asked me a ton of questions about my résumé, about my experience in GSoc gccrs, about MLIR, about the difference between GCC IR versus LLVM IR; let's just say that if a project has the word "compiler" or "programming languages,", they were gonna ask, in detail, each word and each line that I wrote in the résumé. It really felt like they were looking for an independent thinker who's also a problem solver in their own ways.

They also asked me that in one of my compiler projects, did it have error reporting? I reluctantly said no, and that's why I incorporated that feature and wrote about it in this article.

There are also non-résumé questions:

• "What's the most important thing in software engineering, according to you?" - I told the interviewer that it's "building tools."
• "On a high level, how would you debug a JIT compiler?" — Hahah this is a hard question. I talked about how difficult it is to debug a JIT compiler instead. It seemed to suffice.
• "On a high level, how would you debug/detect a memory bug?" — Static analyzer, sanitizers, valgrind, gdb, and lldb.
• "How useful do you think AI is in your day-to-day workflow?" — It's not good enough, but it's helpful for searching for documentation.
• "What, to your knowledge, might be a difference in a compiler's AST and HIR?" (Hint: syntax desugaring, custom SSA IR form, sometimes it also happens that your compiler typechecking and such only exists in the HIR level (this is true in gccrs) so even though there might be no difference in a compiler AST and HIR, there is a difference in the visitor pattern in a compiler's AST and HIR stage)
• "Describe how you would debug an issue that popped up on your most recent commit" - Domain specific knowledge and git bisect. I also told them I like to pose hypothesis and test them out to guide me to the underlying issue.
• "What do you like to do outside coding, in a business setting? There may be other roles you can take on" - Same as the Mac and Cheese interviewer in round 1, my answer is technical writing.
• "What OS would you like to use for compiler dev?" — I answered them: "I have a Macbook right now, but it's a pain to set up LLVM on macOS, I'd like to switch to Ubuntu, it's just a popular linux distribution."
• "What's your favorite programming language?" — I actually don't know if I have a favorite language :) Rust is probably one of them. C++ scores pretty high on the nostalgic feel as well. It's hard.
• "What's your experience with CI/CD?"
• "How does linear register allocation work? How does register coalescing work in this scheme?" — No hint for this question.

I hope to appeal to potential interviewers that although not a single leetcode questions or programming questions were asked in both rounds, the interviews at Takoyaki were still highly technical and demanding of the interviewee.

Phở

I have a disclaimer to make. There wasn't any company that interviewed for only 3 rounds or fewer, except Takoyaki. Most of them interviewed for 4 or 5 rounds, even 6; in protecting companies' anonymity, I need to cut out some questions that might reveal them and put them here. Phở is actually not a single company. But it's actually an amalgamation of different companies' questions that were asked. I want to add all the relevant questions that I was asked, not a single question wasted. Hence, the name.

Questions

• "What do you like about programming languages and compilers?"
• "It is possible to perform dataflow analysis on non-SSA values, even so, we keep on insisting on transforming our IR to SSA-IR form. What's going on here?" (Hint: something about complexity hmm).
• "Tell us about all the compiler optimization you can think of"
• Leetcode 38 - Count and say
• "What's your experience with CMake? Any other build systems?"
• "How about your CUDA skills?"
• "Which version of C++ are you using daily?"
• "What's your experience with AI models?"
• "What are your favorite gcc flags?" - Wall, Wextra, Werror :)
• "Can you tell us what free software is and how you feel about the concept?"
• "How are your Python skills? If you're comfortable, can we do the technical interview in Python?"
• "What's your experience with quantum computing?"
• "If one day you're starting a new company, how would you like it to be run?"
• "Explain to me what's the visitor pattern?"
• "Explain to me what's the concept of the mixins pattern?"
• "You'll notice that when you make a class in C++, you cannot make the class's templated method virtual as well. Why is that?" (Hint: something about vtables, hmmm)
• "What's your experience with the RISC-V architecture?"
• "Do you have any experience with any JavaScript compiler? Can you tell us why you think there are different JavaScript compilers? If you have no experience, you're welcome to take some guesses, let's discuss this together."
• Leetcode 90 - Subsets II
• "We highly value inclusivity together with diversity here at the company. Can you tell us your experience (professional or not) that speaks to this aspect? It doesn't need to be a 1-to-1 match."
• "Here's our newly published open source codebase. Can you tell us anything you like or don't like about the repository? We welcome all suggestions!"
• "We care deeply about giving back and contributing to open source software, have you had any experience in this facet? It is completely ok if the experience is not compiler-related or PL-related."
• "As the job application (that you have read and applied) for the compiler team is about the development of our language SkibidiToiletRizz, can you tell us (even if you haven't coded in it) what you like about the language? What about it that you don't like? We value all inputs."
• "Given the following piece of code, tell me what's the run time complexity of the executable after some possible compiler optimizations, feel free to take your time. Please specify in depth the compiler optimization as well as the framework behind it":

int YourMomHahahahahhhhah(const std::vector<int> &v) {
    int sum = 0;

    for (auto i : v) sum += i;

    return 42;
}

• "Do you have any experience in static analysis?"
• "Why do you think inlining and register allocation are really important in compiler optimization? Can you give us a high level overview on how you would implement inlining? It is ok to take a guess, let's work from there."
• "If, in testing, my algorithm implementation from a paper runs twice as slow when my input size $n_2=200$ is twice bigger than my initial input size of $n_1=100$, does that mean my implementation is linear in its complexity? Can you provide your reasoning or counter-examples on why it is or is not? If it is not linear in its complexity, what would you do to confirm/reject this hypothesis?" (Hint: something to do with plotting and coefficients and hidden constants)
• "Now if you were struggling with the previous question, let me ask you this, what if in testing another algorithm's implementation, my run time is now $4=2^2$ times as slow when my input size is $n_2=1000$, doubled compared to when my input size was $n_1=500$, does it imply that my implementation is $O(n^2)$?"

Epilogue

The recruiting process has been one of the most stressful times in my life. Countless times I've felt my heart pounding, my arms and knees get a little weak from thinking about all these processes.

Despite this, I've also been grateful for the situation that I'm in. With the current competitive and dire market, a lot of people who are significantly smarter and harder working than me who are not able to find a job in this economy, just because they're international. My heart goes out for those people.

I hope you've enjoyed this article detailing my recruiting journey. If you resonate with the article or if you've benefited from the blog, I'd love to hear your thoughts on this. Catch me on discord, Kofi or LinkedIn.

Here are some pictures documenting my emotions throughout the process. Thank you for reading.