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, tiring 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️⃣
| Size | < 20 |
| Domain | work management tool |
| Position | front-end developer |
| Process |
|
| Experience | good! 👍🏼 |
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️⃣
| Size | > 3000 |
| Domain | technical tools for developers |
| Position | front-end engineer |
| Process |
|
| Experience | bad 😒 |
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️⃣
| Size | ~ 300 |
| Domain | payments |
| Position | Senior front-end engineer |
| Process |
|
| Experience | very good! ❤️ |
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 doors 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️⃣
| Size | < 20 |
| Domain | logistics |
| Position | software engineer |
| Process |
|
| Experience | regular 😕 |
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️⃣
| Size | ~ 150 |
| Domain | Finance |
| Position | Senior front-end engineer |
| Process |
|
| Experience | great 1st impression, bad ending 💔 |
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. I was sad they dropped me, but the fact that they've ghosted me for feedback makes me feel they weren't as cool as they presented themselves.
Company 6️⃣
| Size | ~ 150 |
| Domain | Open source messaging |
| Position | Front-end engineer |
| Process |
|
| Experience | good! 👍🏼 |
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️⃣
| Size | ~ 300 |
| Domain | Payments |
| Position | Software engineer |
| Process |
|
| Experience | good! 👍🏼 |
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, since it'll have the most impact on you while at the job.
- 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.
- Be as honest or ellusive as you want. None of this should affect your chances of getting an offer. Just don't give them names
Ask questions, give feedback
- Everyone knows you're supposed to bring questions to every interview. If you didn't, now 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 candidate's 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 before 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!
Top comments (15)
Thanks for sharing your experiences in such detail. I recently went through a similar recruiting process as the one from the company that you finally chose. Although I had multiple first talks with recruiters that probably would have lead to real interviews I rather chose to go with only one. The one that looked the most promising and concentrated on it (I still had a full time job and family next to it). Bringing your own work was new for me and felt a bit like cheeting to be honest. You know the code and usually can talk about it with ease. I did enjoy the technical talk as it made clear that they know about the topics and the questions made sense (I could not answer all of them but did explained why which was probably ok). What I wished I had done like you was to ask if I could meet the team as this is indeed the most important factor (for me). I did accept the offer (I can't yet say if it was a good choice as it starts early next year. Regarding your choice, I hope you will enjoy working for the company. Personally I would have been cautious regarding the fact that the pair programmer wasn't very skilled (at react) and that you are the frontend reference but as you said that you can gain knowledge about backend that might make for it. The main reason for me to quit a job is if I feel that I won't learn much from my colleagues (anymore). Anyway, good luck and have fun.
Thank you!
It shouldn't feel like cheating, imo. On your every day job you're rarely asked to work with code you know very little about and I think there's much more to learn from discussing something that's well thought through!
I am a bit scared about the BE challenge and being the only FE-experienced person in my team. But I trust this type of work methodology enough to know it's the best scenario for a situation like that!
I'm starting early next year too! Thanks for the good wishes and good luck to you too!
Thank you for the amazing reading! I wish I had read that in 2020 when I was looking for my first job as FE dev. In my experience from that time the very small companies are very lost/or very outdated in how they interview and look for people. The company that ended up hiring me was definitely not clear of what they expected from me and the way they worked (nor their current stack), they just said "We are looking for a React or Angular developer". It was also the only one to conduct in person interviews in a pandemic year. What I really did the past year was: 2/3 of my time writing dotNet for BE and the rest developing from the ground a new design system (with a fellow designer) for the React FE.
It's being challenging and a great learning opportunity, but I wish I knew what to ask beforehand to fill the gaps in their lack of infos. So thanks again for the great tips 🎉 I'll definitely keep them in mind for my next job hunting.
** Don't get me wrong, I'm very glad for the opportunity they gave me. They took a chance on someone over 30yo that didn't have a CS degree nor working experience in the field. And as I understand I was the only one that actually delivered the homework assignment that has an API not properly configured for CORS and not documented at all....
Anabella,
A really excellent article. Thank you for sharing!
😍
I'm always surprised that more companies don't train people to be interviewers. I used to work for a multinational tech company, and they had us take a 1-day Behavioural Interviewing class. It was so useful, and something I still draw on now, many years later. Your point about interviewers being the UI for the company at that point is bang on. And the clarity about what the team is looking for and how they are going to fairly and accurately compare different candidates. Plus, there are - in most legal jurisdictions - questions you just can't ask a candidate for legal could-get-the-company-sued reasons!
Thank you!
I know from my own experience I can sometimes feel weird and even nervous when interviewing a candidate, and I'd love to get real training in that. Most companies have many employees and candidates will only meet ~5 of them while at interviews. You need to make them count!
I liked your point about being clear on how they evaluate and compare candidates. I've gotten that from external recruiters prep'ing me up, but almost nothing from companies.
The most common deal breaker last month for me was unclear/unexciting projects, bad vibes from leadership or them just seeming inexperienced. I think there might be a curve in which for the first half of the process it's mostly the company evaluating a candidate, but the 2nd half it's much more mutual, and it's definitely the candidates choice on the last sprint. I think companies fail to make a timely switch to become more attractive and stand out in time, maybe?
Anyway thanks for reading and for your comments!
Thank you so much for sharing this feedback. Being the recruiter for my very small company when it's needed, I'm always struggling between building a saavy process and not making it too cumbersome for candidates to avoid making them lose their time for nothing. A lot of your feedback will be actionable for us and our candidates.
Something I like to do, but don't see a lot in interviews: instead of doing a live coding session (which I think can lead to too much stress, and is not realistic, just like when at school they ask you to write code without Internet access), I ask candidates to write a LOGBOOK.md in which they explain what they are doing, explain their choices and blockers, and even tell us about their mindset and feelings at the moment.
This gives an opportunity to also test their written communication skills - useful when they will communicate with a client, a stakeholder or write documentation - but also, they can explain why something we asked wasn't done, so we can judge how they think instead of their skills. Very useful for more junior profiles.
The real pair-programming session is a great idea though ; the "Bring-your-own coding challenge" too. Will definitely include those in our next recruitment process !
Thanks again and wish you the best at your new job and your personal life ;)
Definitely one of the better ways to start 2022 on DEV with this article! Thanks for sharing the process and your thoughts with us. This is all an immense value for those who want to get a front-end job. 🤩
Thank you! and good luck!!
Sounds like you dodged a bullet with company #4 -- lots of red flags coming from the CTO.
Yeah, I mean, he's probably wel intentioned and not aware of it, but the moment I felt like I was avoiding having calls with him I knew it wasn't a good match, being such a small team.
Very helpful!
Thank you! 💖
very helpful