Why should you even listen to me?
I am a Frontend Architect with People Management Experience (So besides the technical experience I was happy to be working together with People Management, leading peers, building up interview processes etc.)
Amazon, Mercedes-Benz.io, JvM, nodus medical and many more gave me the opportunity to work for them (meaning: I got an actual offer). Besides those few mentioned there were innumerable amounts of other interviews I was allowed to be part of - both as candidate as well as interviewer. I don't like to have tunnel vision when it comes to jobs. I do like to check opportunities from time to time because that helps me understanding the options out there as well as helps me staying in the routine of interviews.
What this post is about
This post is not about which exact weird technical challenge you should prepare for (No you don't have to learn the Quicksort implementation in 10 languages by heart other than if you are applying for a company that's name is "Quicksort in 10 languages Inc"). This is about understanding what's behind the curtains of every good interview. I won't be talking about salary in this post because salary is just something so unique that it wouldn't fit the overall context of this post.
The CV and your application letter
I appreciate your effort but honestly no one is special enough for anyone to read a book load of pages about what you've been doing and what kind of food you eat at 5am in the morning.
Most of the companies love a one page CV, one page application letter. If you say "that doesn't fit on simply one page" then you are showing your incapability of prioritisation. I know you want to show everything but the company just doesn't have the time to read the story of your life.
So if you have worked with 30 different stacks and technologies then you are very much kicking yourself out of being even invited if you list all of those next to each other. Being a FE Developer you should be highlighting your primary FE Skills. If you have worked with Cloud Technologies and Backend then that's cool but keep it short e.g. "Also I have worked with a lot of cloud and backend technologies and I love getting my hands dirty at databases".
Also don't send the exact same letter for every single position. If the role you are applying for states "You will be working on an Angular 9 Product" then it is helping you a lot if you highlight that technology first. This can obviously lead to the fact that you should mention your cloud technologies if the role specifically states that this is beneficial - if not, leave it out.
Prepare
Prepare structurally
If you get invited to an interview and the interview process is professional then the responsible person is superhappy to tell you how the interview will be structured - if you ask for it. If you don't ask for it you will literally be expecting anything.
Send them a nice mail or call them and ask "Could you tell me how the interviewing process is structured? Will there be time for questions and will there be a live challenge?" etc.
There is nothing wrong with asking how the interview will be processed and what to expect - every client can be different so every interview can have different workflows.
Prepare contentual
I remember those times of "inform yourself about what the company does". IMO this is not necessary anymore. No one will reject to hire you because you didn't know that the company has 120 employees - so forget about that stuff.
But you should still prepare and inform yourself about the company to be able to ask proper questions and hence impressing with showing your underlying motivation.
This allows both of you to see if it is a fit or not. You don't necessarily have to "lie" that you "love" the products the company creates. It is sufficient if you like its process around the development part that is part of the products - on which you will work.
If you read on the roles description: "We are a high performing team" and you feel that this sounds like "we are doing a lot of over-hours" then write it down and prepare to ask if they can clarify what "high performing team" means.
But not just that. Ask what exactly you'd be doing. That is a completely valid question. As in "So I read you are working for multiple clients here, how does a typical Frontend Coders Day/Week look like in your company?".
Also ask about the culture which helps both of you identifying if this is what you are searching for / they are searching for.
But first and foremost: Don't start asking questions in the beginning like "Ok before we start I got some questions". I did that sometimes if I felt the urge of importance but I still do not recommend it as it can have an impression of being rude if you are not being very diplomatic. So rather don't and wait for the interviewer to give you space for questions.
If the interviewer does not give you space for questions it feel encouraged to say: "Thanks for this interviewing process so far. [...] May I ask some questions about the company and the job role?".
No question is a "dumb" question if stated friendly and with honest interest.
Let's talk about Interviewing
Coders be like "Oh shit, what if I can't answer this?". And then they might fall into a deep black hole if there was a question that they felt uncomfortable with and at that point I have seen many interviews failing.
The Problem is that many don't understand what the point of interviewing is. It is checking your capabilities of solving problems at the base of your current level given the expectations that you set. That means: I can ask the EXACT same questions in an interview to a senior as to a junior but I'd be expecting completely different outcomes and both could be hired respectively.
What's the trick? Act curious instead of being challenged. Try to imagine all of it less as a "test" and more like a "tell me more discussion". And not only that. Think and explain in pseudocode if you can't provide legit facts.
Literally the worst thing you can say is "I don't know". A few "I don't know"'s and you are out. And not because you didn't know but because you showed that you aren't even trying to solve the problem - not even slightly.
Scenarios
Scenario 1: Sorting Algorithm Question
Interviewer: "Do you know which is the fastest Sorting Algorithm?"
You: "Sorry, no" - Awkward silence 🙅🏽♀️😐
This is close to ending the meeting soon. Here is a proposal of being curious instead:
You: "I don't have that at hand but I would love to know where the answer to this would help within your products scope if I may. I'd be assuming that JS engines would to their best to have a fast sorting algorithm. If that wouldn't be enough I would make sure to research properly how to improve the performance if there is a need detected." - 🤗
Scenario 2: typeof null Question
Interviewer: "Do you happen to know what typeof null is?"
Even if you know the answer to this question (it is 'object') then be rest assured that this is not a key-value test. These questions normally come with a follow up question. There is always "context" around a question.
So say you didn't know that typeof null equals object. Then the worst thing you can do is random guessing. This is not playing lotto and the interviewer doesn't like to be played. They will notice.
If you have a really good guess or you slightly remember something then explain your guess and let the interviewer follow your thoughts: Think out loud! Nothing worse than awkward silence because you think you need to think silently.
If you have no clue then simply say something like: "I am pretty sure there is a good reason you asked this. Would you mind to tell me the solution and eventually have a follow-up question on this?"
Even though not knowing you are showing your willingness to go with further questions in this context after being told the solution. A very much follow-up question probably is: "Can you imagine this check being problematic?" - Now, same rules: Start to think loud. Speak up what you think - as if you were googling. Start one by one: "Okay so if typeof null is object then that implies that a nullish/falsy value can be seen as object if checked with typeof. That means that one shouldn't check for something being an object only with typeof because it could be also null." - You are literally explaining it to yourself AND to the interviewer and hence showing your skills to solve problems at hand.
Seniors, Seniors, Seniors
There is some addendum that is important for Senior Frontend Engineers. The huge difference between Juniors and Seniors is that a Senior actually should be able to answer most of the questions asked at the expert level they present themselves with. And by that I am not saying "They must know every single property / function by heart".
What does that mean?
With Juniors I mostly ask the same kind of questions. With Seniors that's different. I know you cannot keep up with every single technology but you must be extremely proficient in a specific technology and the basics (HTML, JS, CSS) so tldr: Your primary skill of the last project + Basics.
That is why I completely adapt interviews with Seniors on-demand. I do ask the Seniors beforehand about their proficiencies. If the person is being honest saying "I think I missed out one some CSS in the last 2 years but I am really good at XYZ" then I am happy to be gentle with CSS questions and focus more on XYZ (as stated above, it's hard to keep up with everything). If a senior tells me that the proficiency lies in Angular I will focus on asking Angular-specific questions. Even if it is a position as a React Developer. The reason is simple: If the Senior can deeply elaborate on my questions considering the provided proficiency on expert level then I have no doubt that this person has the capability of understanding the architecture of another framework.
And now comes the pitfall: Seniors often don't expect me to ask basic questions which is honestly shocking for me every single time. And with basic I don't mean "Which exact CSS property will let boxes to be aligned next to each other" - it is sufficient to know that display: flex exists and that you can do a lot of alignments whichever way with it. Details: Google.
But if a senior starts telling me that float: left is a good way nowadays to align boxes then it shows that that person must've ignored every single news on the internet in the last past years.
Also one of my favourite questions for seniors is to explain me the arrow function. And if a senior says "It's a function but with a different syntax" then this is a definite reason to be rejected. For good reason: The arrow function binds context - and it binds it in a way that is unchangeable. So even the functions .bind, .apply and .call cannot change that context. But they also wouldn't throw an error. So if a senior does not know that an arrow function changes context immutably then that Senior would've a hard time debugging if there was a legacy library that would be making use of older functions but now providing arrow functions leads to problems - without throwing errors.
In my experience Seniors often oversell. So if you are insecure about being Senior then rather sell as Intermediate and surprise with potential Senior knowledge than sell as Senior and surprise with disappointment. When I do ask "How would you rank your JS knowledge on a scale from 1 to 10" they often go to 8 or 9. Because they don't do much of self-reflection anymore. That backfires. And this happens in a lot of interviews. And this is something that really only happens with Seniors, rarely with Intermediates or Juniors. The problem is that seniors are often doing something very specific in a project. And more often than never they are solving the product needs with that specific solution and that might be perfectly fine and in a way that is senior'ish. The problem is that they forget that they are often "living in a technology tunnel" without learning new things and keeping up with how JS evolves. But they must make sure to keep up with the basics.
And not just that. They also must ensure to not forget the basics. Because if they need to dig deeper (not every 3d-party library is perfectly working) they might need to be working outside of the scope of the framework with pure JavaScript. And that shouldn't be a huge challenge for them.
My suggestion here is simple: Stay humble and at least subscribe to 1 JavaScript Newsletter. That should already be a good start.
Rejection Handling
Rejections are hard. As always in life. And you must prepare for being rejected. Expect to be rejected.
And if you get rejected then see it as just one step of a potentially large but definitely finite ladder. Because every single rejection can be seen as "a practice step for the next interview". This is hard but crucial for your mental wellbeing and for getting better.
Also don't just be mad. Answer all rejections with the question for feedback: "Thank you for having invited me. Although it wasn't a fit I would be extremely happy if you could provide me more insights and feedback that will allow me to improve". You'd be surprised how much feedback you will get - Sure, there's exceptions but the worst thing that can happen is that you don't get an answer.
Feedback gives you useful insights what exactly was wrong.
Many don't ask for feedback and simply lower their self-esteem with the implication of "simply not being good enough" instead of acknowledging that it's only a step of becoming better.
A last note
Try to be yourself. Yes it can happen to "struggle" oneself into a position but that doesn't come with a bunch of happiness.
Sometimes it just isn't a fit. Everyone's different, everyone's special. Just like Friends and Relationships: Not all people bond well together. That's fine.
Phew. That was a bunch of text. I hope it helps.
Top comments (0)