7 front-end interview processes I did in December 2021

This content originally appeared on DEV Community and was authored by anabella

I recently went through the task of getting myself a new job and, to do this, I took part of 7 simultaneous interviewing processes for front-end roles with React and Typescript.

I learned a lot as days, weeks, and interviews went by. I learned about myself and about the way companies evaluate candidates. I think this knowledge, paired with a real view into how front-end interviewing looks like today could be really useful for other people in search of a new job and teams who are looking to hire (to get interview ideas!).

In this article I'll go through each of the companies I interviewed with (without giving names, sorry papparazzi! 📸), I'll outline the process and its stages and try to give my view on the pros and cons of each approach.

Disclaimer

To be completely honest, doing 5-6 interviews per week wasn't such a wonderful idea.

It was stressful, tyring and came with a constant state of context switching. Interviewing is, in a way, a performance and you have to be at the top of your game on every call, 'cause it won't matter how well it went with the other company you spoke earlier in the day.

I'd recommend job seekers to focus your energy in 2, max 3 processes at the same time. Job hunting really is a full time job, and limiting your options will help you focus on the ones you're really interested in.

Company 1️⃣

My take on it

The good 😇

• Fair and easy going process
• Show and tell of a project is one of the best ways to evaluate a candidate's tech skill without going through the dreaded "live coding" or the tedious "take home test"
• "No wrong answers" approach to tech talks
• Talks with C-level people (founders) were very interesting and layed back

The bad 😈

• The talk with the front-end lead was confusing. They seemed undecisive and sloppy and not a "leader type". This had a big influence in my decision to drop out

The ugly 👹

• They were trying to hire remotely but hadn't figured out anything about how to do it

Conclusion

I dropped out before they made an offer (they said they were ready to do so). I realized I wanted to join a bigger engineering organization.

Company 2️⃣

My take on it:

The good 😇

• Clearly structured process
• They provided study material for the algorithms test
• They provided thorough feedback after dropping me
• They sent an anonymous Greenhouse survey about my experience

The bad 😈

• Too many technical tests, all of them stressful
• Slow (~weekly) communication
• Unclear live coding test (they didn't say there were 2 problems so I took too much time on the first and simpler one)
• Untrained technical interviewers reading questions from a script

The ugly 👹

• Dropping an experienced candidate based on their ability to solve basic algorithms while under peer and time pressure 🚩 (personally, that's not a company I want to work for)
• During the algorithms call they either gave me false tips (leaning me into the wrong approach) or were too ambiguous with their words (I really really hope it's the latter)

Conclusion
They dropped me so I might be a bit bitter about it but: cracking long-solved, highly googleable problems or implementing existing algorithms is very far from the value I can bring to a product team. If that's the first thing they care about, then that's not a company for me.

Company 3️⃣

Note: The in-house recruiter was in touch with me at every stage, we had face to face conversations after each interview and he kept me up to date and shared feedback constantly. It helped build a relationship between me and the company.

My take on it:

The good 😇

• All kind and nice people, all around
• The in-house recruiter took the time to speak with me after every interview, this built a friendly bond
• (Almost) no live coding, no whiteboarding, no take home tests
• Favorite interview (of them all!): FE system's design
  • No whiteboarding
  • Look at app screen designs, break them down, find problems, think of implementation, evaluate options and their pros and cons.
  • 👆🏻 Literally one of the things you'll do the most while at the job (aside from writing/reviewing code).
  • Finally, a small algorithms coding challenge (bit of a surprise :/ ) but I was already warmed up and confident and it went well :)

The bad 😈

• The live coding part of that interview came as a surprise, which is usually seen as a bad practice. Candidates should know about every part of the interview right when it starts. It gives them the chance to manage time and energy accordingly.
• I spoke to the team lead and a teammate of my potential team. They weren't ready to pitch an interesting challenge for my position, which in the end resulted in my loss of interest.

The ugly 👹

• Managers need to be trained in diversity matters
  • When I asked the manager I spoke to about how they were giving a voice to underrepresented people in the company he said "we have an open door policy, anyone can talk to anyone, no matter their rank"
  • For the record, "open doors" is not enough for underrepresented folks, as most of us won't feel entitled to speak our minds openly
  • Humble advice: put underrepresented people in situations where they are expected to speak their minds

Conclusion
They made an offer which was tough to say no to (no pun 🐴). But I felt like the work I'd be doing wasn't very clear and the team lead fell really short in pitching the project, so with a heavy heart I went a different way.

Company 4️⃣

My take on it:

The good 😇

• They were very clear about their intention to make me an offer almost from the Start

The bad 😈

• The take home test was really low quality.
  • They gave me a boilerplate project and some designs to implement. There were no specs or acceptance criteria, icons couldn't be exported, entities were inconsistently named, and it was hard to match the data coming back from the API with the designs.

The ugly 👹

• Bad manners from a C-level interviewer
  • During the review of my solution the CTO questioned the file structure of the project (wut?) and seemed to be trying to find things I "did wrong".
  • Later on, when I was verbosely and carefuly refactoring my code to introduce a new feature he interrupted me because he didn't "understand what I was doing".
  • After I was done with a working and clean implementation he said "there was an easier and faster way to get to the same result".
  • All of this was inconsistent with the external recruiter's claims that they were incredibly excited for me to join.
• In a later call with the CTO he asked me to name which other companies I was interviewing with and even though this made me really uncomfortable I told him. I wish I had stood my ground and refused to share that info.

Conclusion
They made a 3-folded offer (different distribution of salary and stock) which I declined.

Company 5️⃣

My take on it:

This was the company I was most excited about, and the one which broke my heart when they dropped me.

The good 😇

• They have public salary bands and career paths
• The process was short and focused
• They shared a highly realistic project (with tickets) in advance, which I'd have to work on during the live coding

The bad 😈

• We spent a lot of time during the live coding debugging accessory things which they suggested but then weren't sure how to implement.

The ugly 👹

• 2 weeks have past and they still haven't provided any feedback about what made them drop me after the live coding. I've requested it twice, no answer 🚩

Conclusion
No matter how cool a company can look, they need to walk the walk and treat their candidates with respect.

Company 6️⃣

My take on it:

The good 😇

• All interesting, respectful, and kind people
• Fun and simple take home test, actually doable in 2-3hs (although I spent more 'cause I wanted to get it just right, that's just me)
• The pair progamming interview was actually a pair programming exercise (not live coding in disguise).

The bad 😈

• A bit of a long process, too many technical tests for my taste. The one focused on React was very outdated (class components, no Typescript). It didn't reflect the actual state of the app I'd be working on.

The ugly 👹

• The person to whom I spoke when I requested a talk with a team member wasn't really prepared to pitch the project and that had the biggest impact in my decision.

Conclusion
They made an offer, which I declined in favor of another one (read below!). But they said the terms of the offer would stand for about 6 months! How nice! 😍

Company 7️⃣

My take on it

The good 😇

• Short and fast paced process
• Every interviewer feedback at the end of each interview (including if I passed!)
• Pair programming was actually pair programming (not live coding in disguise)
• Bring-your-own coding challenge felt like I was in control of how I'd be evaluated
• They arranged 2 calls to meet my potential team
• All the talks gave me a clear sense of what it's like to work with them

The bad 😈

• I was a bit confused / annoyed to have to "put in work" preparing a challenge to bring before I even spoke to anyone in the company. That might have been different if I had been contacted by an in-house recruiter and learned more about them first.

The ugly 👹

• The person doing the pair programming with me had very little knowledge about React, this was beneficial to me because I love explaining React to people, but we might have gotten more done if they had been front-end focused.

Conclusion
They made an offer and I accepted it! 🎉

The biggest selling point for me was the ways of working (XP/Lean, pair programming by default) combined with the fact that I'd be way out of my comfort zone working a lot on backend projects and being the person-of-reference for front-end and React matters.

My overall learnings 🧠

For candidates 👩🏻‍💻

Show and tell interview

• Bring something you're really excited or proud of
• It can be something small, you can even build it specifically for the interview (that way it'll show your most up-to-date skills!)
• Start with why you wanted to build that
• Think in advance about how you're going to walk through it, the reasons for your decisions and things you'd like to add or improve on

Live coding

• Make sure you know how many exercises you'll have to go through
• You can even ask how much time they think they should take. That way you can adapt your rhythm.

Helping your decision

• If you have doubts about joining a company, or if are trying to decide between competing offers, requesting a call with potential teammates can help a lot in picturing how the day-to-day work will feel like. To me that was a dealmaker because:
  • I'll be working with a certain group of people
  • In certain projects
  • And with a certain dynamic
  • 👆🏻 that should have more weight in my decision than anything else.
• In my experience companies and recruiters will be more than happy to arrange a call with the team for you at a final stage of the process

Decide how much you want to share

• You'll probably get asked about other processes you're taking part in.
• Companies often ask this to make sure they're not lagging behind timewise.
• They might ask you about "where they stand" in your preference list.
• They might ask you for details of other companies, size, domain. Don't give them names
• Be as honest or ellusive as you want. None of this should affect your chances of getting an offer.

Ask questions, give feedback

• Everyone knows you're supposed to bring questions to every interview. If you didn't, know you do!
• Ask about things you care about, anything that'll help you picture yourself working with them or make up your mind about joining.
• Take the opportunity to give feedback to companies and interviewers after each call.
  • Include what you liked about it and what could be improved
  • This, if done right, could make you stand out as a candidate!

For hiring teams 🏢

Show and tell interview

• This is a great way of evaluating a candidates experience and skill without putting them on the spot!
• Instead, it puts them in control of the situation and you'll get to see a lot more of how it's like to work with them on a daily basis.
• You won't see much of that 👆🏻 with a coding kata or an over-simplified feature development exercise.

Train people on how to interview candidates

• Especially for bigger organizations: train your interviewers in conducting conversational and technical interviews. They're the face of the company to potential employees.

Live coding interviews

• Especially for kata style ones, make sure the candidate is aware of how many problems they'll go through during the call and give them an estimate of time budget for each one.
• Mention if they're going overtime with one problem and give the option to move one to the next or work on solving the current one.

Pitching the project

• When reaching the final stages of interviewing, especially if you're a small/medium company, prepare your interviewers in pitching the team and the company to candidates
• Those final conversations usually make or break the deal for people trying to decide between more than one offer.
• If you have all positive feedback across the board about a candidate, make sure you can give them an offer that's interesting to them.
  • By this I don't mean money: most experienced candidates will get similar offers and you can probably match whatever they're getting somewhere else.
  • Pitch them a position and a project that they'll feel excited about, and it might even be worth not going for the highest paying offer!

Give feedback to candidates

• This can be before the interview ends
• It can be in "catch up" talks with the recruiter
• It can be as a warm up for making an offer
• And it should definitely be there if the company drops a candidate, especially after the candidate requests it.
• Idea 💡: ask candidates for feedback of each interview!

That's it, thanks for reading this far, please leave comments about your own experiences interviewing and being interviewed.

I hope some of this is useful for you in 2022!

This content originally appeared on DEV Community and was authored by anabella