I felt it very important to log this down because I tend to forget things easily. There was definitely a lot to learn from through the experience of this round of interviews. 2021 hasn't been great with the pandemic around, but really glad I summoned up the courage to take this step out.
Navigation
Start of the Journey
It’s been over 3 years since I joined my current company after graduation. I thought it was time and an opportunity to see if I was still competitive in the job market. Hence, the start of my interviewing journey.
Background
I would probably fall in the "made a transition" category due to my non-CS background. Below is a brief background information:
- Majored in Marketing and Biotechnology (Biomedical Engineering)
- 3-4 years of experience
- 70% front end / 30% back end & other stuff
- Built products with over a million users
- Built web applications from 0 to 1
- Deployed and maintained existing applications
- Front End Stack: JavaScript, HTML, CSS, React, Vue.js
Senior Front End Engineer
After gaining some real-world experience, I decided to take on the challenge and apply for senior positions. Unfortunately, as the title states, I didn't get the offer I was aiming for. On the other hand, I got the chance to face up and see where my weak spots were.
Let's see how far I survived!
Preparation
End.
I admit I was lazy. Well, I still had a decent job in case all fails. There's nothing to lose, right?
My first interview was a disaster. In addition to my laziness, the past 3 months before interviewing, I was doing 90% DevOps and barely wrote any React for half a year. So believe me, when I say disaster, I mean it literally!
Getting back to the topic of preparation, I took notes right after each interview when the awfulness was still vivid and looked up everything immediately. Believe it or not, the same questions get asked over and over again.
I definitely suggest reading articles on interviewing including the one you're reading right now.😊
The Interview Journey
Here we go!
No company names will be mentioned here since I'd appreciate some anonymity.
Resume & Cover Letter
After all, I only prepared my resume and cover letter, this was the part I am the most confident. 80% of my applications got a chance to move to the next stage of the interview. All except one were applied without a referral, so a well-crafted resume and cover letter can go a long way. Let's not forget that moving forward to the initial interview turns the odds of getting an offer from impossible to possible.
This was probably the only thing I did right this time around.
Assignments
Assignments were super common for the front end interviews that I've gone through. Assignments have always been quite a controversial aspect of the interview process. I'm not going to deny the fact that assignments consume (waste) a lot of time and you had to put that much in while still far away from an offer. However, it offers a way of evaluating the candidate more thoroughly in my opinion.
I spent around 6-12 hours on each assignment, trying my best to make a good impression. After turning in the assignment, there would be a one-hour call to discuss it. The majority of the 1-hour call would be around these aspects:
- Architecture
- Why is your code structured this way?
- Why did you choose method A and not method B?
- What are your criteria for splitting components?
- Object-oriented programming (OOP) principles
- Testing
The feedback I received before we started the one-hour call were:
Project has good architecture and structure.
Code is very easy to understand and get around.
Wow! That's the good impression I was aiming for!
But! But! But!
I did a poor job at talking about my architecture and design decisions which probably threw me out of the "senior" window. In retrospect, I relied on my guts when making these decisions. If I couldn't even persuade myself why structuring code this way would be easier to maintain and test, there's no reason that other people should be convinced, right?
Despite my weak performance, I got lucky and moved forward for every assignment I had done. Huge relief since I spent an enormous amount of time doing it!
Be prepared to have your thought process laid out and convey your architecture designs clearly to the interviewer.
Technical Interview
Since this is the most prevailing part of the interview process, here's the list of the most common stuff that I was asked about:
JavaScript
- Asynchronous
- Closure
- Event loop
- Promise
- Hoisting
- When choosing a library / tool to use, how do you evaluate it?
React
- Why React hooks? What benefit does it bring?
- Performance:
useMemo vs. useCallback
- Reconciliation
- Class components / Functional components
CSS
- Centering elements
- Styled-components
Web
Live Coding / Whiteboarding
As for the dreaded coding test, I faced it only twice. Definitely less than I expected. One was to implement a debounce function and the other was a LeetCode medium problem.
The two surviving tactics for live coding or whiteboarding are to ask clarification questions and think out loud. By applying them, I got to know right away whether I was in the right direction by observing the reactions of the interviewer. Also, it became an excellent chance to demonstrate my communication skills.
There were no twists and turns for the questions during the technical interviews. They were not hard and preparation will pay off big time! I paid the price for not preparing by ruining the first two interviews and got better eventually.
Common interview questions aren't called common for no reason!
Good reads on Hashnode for JavaScript:
🎯 JS Interview Checklist - Part 2 (Advanced)
Tricky Javascript Code Snippets Asked In the Interview
Meeting the Team / Behavioral Interview
Yay! The most non-technical part of the interview!
After going through it a couple of times, here's the list of "common" questions.
Collaboration / Communication
- You would like to introduce a new library / framework into the project / company, how would you communicate with the team about it?
- What would you do if you disagree with the designer?
- If given a task you've never done before, how would you approach it? How will you be confident that you can come up with a solution?
Personal / Motivation / Goals
- Received an assignment to learn an unfamiliar skill and give output about it in 30 minutes.
- What is your career goal / personal goal?
- What motivates you during work?
- Why do you want to join us?
- Why do you want to leave your current company?
- How do you see yourself in 3 years?
Some of these questions were answered while crafting my resume, so I guess I somehow prepared for it.
Receiving the Mid-level Badge
I didn't get that senior front end role as mentioned from the title, so here's what happened in the end. I received the mid-level badge from multiple parties.
All of the companies that I interviewed with replied that they would still move me forward if I could accept a mid-level position.
One company that rejected me before also reached out after a month, saying that there was a new position opened for mid-level engineers. They said that if I was still interested, I could keep going with the interview process without starting all over.
All in all, it wasn't as bad as I thought and there were no hard rejections.
Thoughts on Junior, Mid-level, and Senior
Instead of mentioning how many years of experience is expected like a typical job description, here are my two cents of their differences.
Note: This is only my point of view that I wanted to log down for reference so please don't view this as a standard.
Junior
I started coding to solve problems and it just works. Period. At this stage, I could implement features for our projects, but sometimes I get really stuck and need help from more senior members.
- Build stuff that works and fulfills given tasks
- Might not have a good understanding of why it works
Mid-level (I’m here 👋)
It's a bit awkward to get stuck somewhere in the middle, but here I am.
Implementing features independently usually isn't a problem, unless it involves complicated algorithms and math calculations. It is the how to implement it to make life easier for the team as a whole that bothers me. Reaching more into the fundamentals will definitely help with the process.
On the other hand, I started to mentor junior members as well as pay more attention to code reviews (but did an awful job looking back). As the codebase grows, I experienced how testing became a "must to have" instead of a "nice to have". Situations such as code changes meant to fix B accidentally break A started to happen a lot more frequently. Also, I discovered how crucial architecture and structure became because it encouraged coding style and practices for newcomers, no matter their seniority.
In short, the need to collaborate forced me to care about aspects beyond making things work.
- Build stuff and fulfills tasks efficiently
- Better understanding of why it works
- Code in a more collaborative sense
- Architecture
- Testing
- Mentoring
- Code review
Senior
I'm not here yet, so this is what I'm hoping to achieve for the next milestone.
The ultimate goal is to be able to accelerate collaboration and be a multiplier for the team.
- Expertise in the fundamentals
- Architect and enforce coding standards
- Identify the trade-offs for decisions
- Confidence for code quality
- Mentor and encourage a positive culture
- Cross-team collaboration
As for going beyond the senior level, I imagine the actual time spent in writing code will become less and less evident. The focus would be switching to communication, planning, and architecting the project with reference to past experiences and the ability to draw thoughts from others. It's kind of like how CEOs don't really do much of the daily work, but everything that they do will have an enormous impact compared to us.
These are just my thoughts for now. I’m still learning along with my career and would love to know your thoughts on the different levels too!
To Be Continued
I wanted to write this down as a reference for my future self because this time around I didn’t take up a front end job. If you ask me what happened? Well, that’s another story.
All in all, I do see myself staying in the field for the long run (let's say at least 10 years), so there definitely will be new chapters written. After this experience, I believe putting yourself into the job market every 1 to 2 years is a healthy thing to do. Not only do we get to know if we're still competitive, but it is also a great opportunity to see how are we growing in our career with a totally different set of eyes. We don't actually need to be "looking for a job" to do it.
That's the end of my first post on Hashnode? It was supposed to be the first post until the HarperDB Hackathon came along and snagged my priorities! Shameless plug here for MoodPraiser, the project I built for the hackathon.
What's your interview story? Please share in the comments and I'd be more than happy to read about it!
