2017 Frontend Interview Reflections

Introduction

I finally found time to write up my recent interview experiences. To summarize a few observations first:

1. Typically, company interviews only test familiarity with JavaScript, mostly focusing on algorithms or explaining the prototype chain, and rarely testing DOM or Event manipulation.
2. CSS is almost never tested; even if it is, it’s just basic questions like determining class vs. ID specificity.
3. No interviews tested HTML, such as semantic tags, accessibility, input type usage, etc.
4. React, Redux, and ES6 syntax have practically become mandatory skills for frontend developers, while fewer companies adopt Angular.
5. In general, headhunters lack professionalism—though it’s also possible I was just too junior to be approached by the good ones.

Here are the companies I interviewed with this time:

1. Accupass
2. Codementor
3. Linker Network Inc.
4. Rakuten Taiwan
5. 17 Media

Background

Graduated from the Information Management department of a national university of science and technology, currently with two years of work experience. I usually focus on frontend development, with about two years of experience in React and Redux. Beyond general frontend “engineering,” I also really enjoy UI implementation and interaction design. At the same time, I practice backend knowledge in my own side projects, such as AWS, Lambda, Node.js, databases, machine learning, and so on, though I am still most proficient in frontend technologies.

Desired Work Environment

1. Being able to collaborate with a frontend team. In my previous work experience, I was the sole frontend developer, making it difficult to discuss specific frontend technologies.
2. Not having too many unexpected surprises—like sudden requirement changes, scrapping products mid-development, or being forced to build projects just out of personal favors.
3. Having a core product and well-defined services.
4. High technical depth, working alongside an exceptional team.

Job Search Channels

• Inside Jobboard
• Yourator
• 104 Job Bank
• f2e jobs
• PTT Soft_Job board

1. Accupass

Applied Position: Frontend Developer

An event ticketing platform that was recently rewriting its architecture from Angular to React, because the original Angular codebase was difficult to maintain and had high coupling where a small change could break everything.

Before the Interview

Invited to interview via 104 by a PM.

During the Interview

The team was expanding. The interview mainly involved discussing my past work experience and some small projects. The frontend engineer who interviewed me that day was Japanese XD, but spoke fluent Mandarin (the entire interview was conducted in Mandarin).

We discussed Accupass’s development status, how they build features, timeline management, and so on. I also chatted about tech with the frontend engineer, ranging from CSSModules and RxJS to CycleJS. He felt like an engineer who was very passionate about frontend tech.

Result

Declined offer.

The PM really hoped I would join the Accupass team. After I declined, he called to ask why and mentioned hoping to work together if an opportunity arises in the future. However, because another role was more appealing to me, I turned down Accupass’s offer.

2. Linker Network Inc.

Applied Position: Frontend Developer

Specializes in cloud computing platforms for IoT, AI, and machine learning. Since these platforms require UI support, they needed frontend development help. Their official website was quite bare-bones and didn’t show much, but the work they do has high technical depth.

Before the Interview

Actively applied on 104 and received a phone invitation for an interview. This company has deep technical depth and also organizes offline community events.

During the Interview

You could tell it’s a company with very solid technical chops. During my self-introduction, I talked about past work experience and using React and Redux.

I later found out that the person interviewing me was c9s—I was wondering why he looked so familiar! You could tell he’s a heavyweight in the field, with deep technical mastery. (Though he looked a bit weary in person.)

The interview included some optimization-focused questions, such as:

1. How does JS minification work? This question required explaining the general process of JS minification, narrowing down to how unnecessary whitespace is eliminated from code. The concept is straightforward, but implementation involves some edge cases. I didn’t think it through enough at the time and needed several hints before writing it out.
2. How can you optimize frontend performance? I mentioned some common approaches, but they didn’t seem to hit what the interviewer was looking for—things like base64 encoding to reduce requests, caching, Service Workers, etc.
3. If you were asked to build a SPA framework, how would you do it? If I had to build one, the first thing to consider is routing handling, since SPAs rely on client-side routing. Later, I was reminded that lifecycle management also needs to be taken into account.
4. Some JavaScript questions
5. The principles behind the prototype chain
6. What happens behind the scenes of new?
7. How to implement inheritance
8. What does this point to?

Finally, someone who appeared to be a manager talked with me about the company’s current status, future development, etc.

Result

Ghosted (it’s been three weeks now). Probably because I was too green QQ.

3. Taiwan Rakuten

Applied Position: Frontend Developer

I had interviewed here once before, but couldn’t commit to full-time hours back then (not entirely sure if that was the only reason). So I applied again. The office vibe was similar to typical large corporations—you need an employee badge to enter.

Before the Interview

HR reached out and sent me a background questionnaire along with a coding test. The questionnaire format was similar to a 104 resume. Here, I’d like to give special mention to their interview invitation email.

Most companies just attach an address in the email, but Rakuten highlighted key landmarks, such as “Exit XX,” “above XX Bank,” “turn right out of the elevator,” etc. While a minor detail, it’s very helpful for candidates—after all, nobody wants to be navigating Google Maps under the scorching sun only to walk in the wrong direction.

During the Interview

Compared to before, this interview felt even more formalized. I had to take written IQ and personality tests, answering questions like basic arithmetic; I think I even got a few wrong XD. This lengthened the overall interview process quite a bit.

The interview with the engineers was very pleasant. It mainly revolved around work experience and technical understanding. Both engineers clearly had strong technical chops. One of them had interviewed me previously and told me, “I don’t have major issues with your technical skills,” but I had been rejected back then due to military service scheduling. That was really touching QQ.

Later, I discovered that one of them was the creator of react-bootstrap-table.

The interview mainly tested JavaScript concepts, such as:

1. Recursion and practical applications For example, there was a string reversal question where the interviewer asked me to implement it recursively and asked what the benefits were. I racked my brain but couldn’t think of one, and couldn’t find an answer online either.
2. Closures and practical development applications
3. Benefits of IIFE (Immediately Invoked Function Expressions) I gave a few examples, but then an engineer shared jQuery’s source code, explaining that using IIFEs also effectively aids minification (by parameterizing window). That was a trick I had never thought of before.
4. Scenario applications of React and Redux Tested common Redux development scenarios, store management approaches, and React lifecycle usage.
5. (Update) How to implement addition without using + This tested understanding of bitwise operators. It can be done using XOR—taught in high school adder logic XD—though you still need to sketch out a truth table.
6. (Update) Taiwan Rakuten had a memorable slogan: “Simplify the complex, proceduralize the simple, standardize the procedural, and automate the standardized.” (Not sure if that’s the exact phrasing.)

After that, we covered some engineering questions like CI/CD and development workflows. Rakuten has a diverse tech stack—Angular, React, RoR, and GraphQL are all in use.

Result

Since I still didn’t meet the eligibility requirements, I was essentially disqualified. However, the frontend team felt very solid. Both engineers had development experience outside of frontend, and they were very friendly. At the end of the interview, they even treated me to a drink (from the company vending machine, though XD) and gave me plenty of career advice.

4. Codementor

Applied Position: Frontend Developer

A platform offering 1-on-1 online mentoring services, which has expanded into services like online code review, debugging, pair programming, etc.

Before the Interview

Because of its high technical depth and the fact that its target audience is engineers, I thought it would be a great place to hone my skills. I applied via 104 and received an online interview invite from HR the next day. I really like online interviews—not having to travel to the office in person is a huge blessing for engineers!

During the Interview

Round 1 — Engineer Interview

Interviewed with the team lead, discussing past work experience and development questions. Orally tested understanding of JavaScript and React:

1. Closures
2. Flux vs. MVC: what problem does it solve? To be honest, I hadn’t used Flux in production, only looked at architecture diagrams and code, so I could only answer based on my own understanding.
3. How does JavaScript achieve asynchronous execution? Discuss call stack and event loop understanding.

Round 2 — Co-founder Interview

Also chatted online with the co-founder. This stage focused less on technical details. After my self-introduction, he seemed very interested in one of my side projects XD, asking about my initial motivation for creating it and why I hadn’t turned it into a full service. We spent quite a while discussing this project, and also talked about Codementor working on similar content platform services.

Afterwards, I asked about Codementor’s history and team culture. In total, it took about 30–40 minutes.

Round 3 — CEO Interview

The CEO was based in California, also interviewed online. We mainly discussed my work responsibilities, development experience, and personality traits. The goal was probably to assess mutual culture fit through the conversation. It took about 30–40 minutes in total.

Since both the co-founder and the CEO of Codementor come from engineering backgrounds, the conversation was very pleasant, without any feeling of being looked down upon.

Later, he asked: “Do you consider yourself a smart person?” I answered no—the more code and algorithms I see, the more I feel that way.

I might never be able to design a massive architecture like React or devise various sorting algorithms in my lifetime; I just don’t see myself as particularly smart.

After the Interview

Rejected about five days later; it seemed they found a more senior frontend developer. Codementor gave me a great impression—both the CEO and the team lead came across as genuinely passionate about their product. I hope to have the chance to work with them in the future.

5. 17 Media

Applied Position: Frontend Developer

This was probably the most enjoyable interview experience I’ve had so far. I saw the job posting on f2e jobs, hesitated about whether to apply, and eventually got an interview invite through a friend’s referral.

During the Interview

Because the team lead used after-hours time to interview me at 18:30, I arrived at the office right on time, and the team lead showed up punctually as well. I really appreciated that.

At some companies, because they aren’t sure when candidates will arrive, engineers are often working and then abruptly notified of an interview, scrambling to gather materials or glance over the resume at the last minute. When I asked how many people he had interviewed so far, he even showed me his Slack messages, noting down who was late. He was someone who clearly values punctuality.

First, HR gave me a tour of the office. It was quite spacious, with an impressive snack pantry and fridge, plus coffee machines, coffee beans, microwaves, etc. I heard the RD team had another office, but the space still felt a bit cramped on the day I visited.

Next was the interview with the team lead. It started with a self-introduction and discussing work experience.

As we talked, the conversation transitioned into the current state of the company and team. He gave the impression of someone who really protects his team. Then came live coding. To simulate real-world conditions, internet access was not restricted. It mainly tested common JavaScript development use cases and implementing built-in functions.

Once written, the team lead started discussing technical details based on the code I wrote—why I wrote it this way, whether there was a better approach, etc. He spent a lot of time discussing, asking questions, and sharing his thoughts on the code, feeling just like a real code review. This part took the longest, roughly 1.5 hours.

Finally, he gave me a messy piece of code for a code review and bug fixing. After discussing it together, the interview concluded.

When I left the office, it was already around 21:50. He had been patiently working alongside me the entire time. What impressed me most was our discussion of \B. It’s a regex token rarely deeply understood, so after discussing the original answer, I asked him about the usage of \``B.

He patiently explained from \b and \w all the way to \B one by one, solving a question I had held for a long time. (Online resources rarely explain \b clearly.)

He gave me a few impressions:

1. Authentic: He didn’t hide the company’s real situation to avoid making you feel deceived after joining. Throughout the conversation, he casually shared some frustrations and sighs encountered at work; you could tell he had weathered many storms.
2. Sincere: He didn’t use bizarre puzzle questions to grill candidates, but instead discussed code quality and how to improve the code together. That is remarkably rare in an interview. Furthermore, when I mentioned that the office was so big I didn’t know who to look for upon entering, he said he would pass the feedback to HR. At first, I thought it was just lip service (since most companies just nod along), but to my surprise, he actually relayed it to HR, which deeply impressed me.

Result

Offer received. HR called to explain the onboarding process.

Reflections

Interviewing is truly exhausting QQ. If possible, I’d really prefer not running around everywhere—conducting everything online suits lazy engineers best!

Beyond just “job hunting,” this round of interviews allowed me to meet many developers. They might not often appear in major tech communities, but in terms of strength and depth, they are far more profound than some developers who blow hot air in the community. That’s not to say community involvement is bad—many people contribute tremendously to the community. But many people are also quietly contributing offline, and one shouldn’t judge someone’s competence by how publicly active they are.

Beyond “job hunting,” what I learned from this interview cycle is—humility. There are simply too many brilliant people in software development, constantly reminding me of how ignorant I am.

1. Resume Preparation

Since I’m already in the habit of writing on Medium and my blog, I could easily link to them in my resume. And because my resume is hosted on GitHub, updating it is very easy.

2. Work Experience

Work experience shouldn’t just be company names, job titles, and years of tenure. What were your responsibilities? What did you accomplish at the company? Be as specific as possible. For example:

• Managed complex page development using React and Redux
• Optimized homepage loading performance

This is much better than simply writing “Frontend Developer.”

3. Side Projects

Beyond your day job, having your own side projects is even better. As an engineer, there are bound to be problems you want to roll up your sleeves and solve yourself.

It lets interviewers know your areas of interest and tech stack. In every project, there are bound to be specific problems that troubled you for a long time or took considerable effort to solve.

4. Ask More Questions

An interview should be a two-way street of communication, not just a standard Q&A interrogation. Knowing how to ask questions back also helps you better understand the company.

Usually, I ask internal company questions focused on these areas:

1. Is there automation? Many companies still manually SSH in to deploy by hand. This development practice can indirectly reflect company culture—such as tedious budget approval processes or turning a blind eye to things that could be automated.
2. How are bugs resolved? How bugs are handled reflects how the company prioritizes work. For instance, how are bugs reported? Who decides bug priorities? Usually, their answers reveal whether they have established guidelines for scheduling and prioritization.
3. Do requirements change often? The question of requirement changes can be approached from multiple angles: What constitutes “often”? When do changes occur? What is considered a change? This helps reveal whether the company has issues where they specify A during development, but expect B upon delivery.

From there, you can follow up based on their answers. Usually, by listening to how the interviewer answers, you can get a pretty clear picture of the company’s internal reality.