About Technicial Interviews

If you’ve been in the tech industry for a while, you’ve likely encountered your fair share of terrible interviews. Even the best tech companies can’t always guarantee a flawless interview experience.

Bad interviews often happen due to a lack of communication, an unpleasant tone, and unrealistic expectations. Speaking from my own experiences, unrealistic expectations can be the worst. This is why I firmly believe that junior developers shouldn’t be put in charge of conducting interviews. They tend to ask obscure, highly specialized questions that have little relevance to the actual job requirements. It’s as if they’re trying to stump you rather than assess your practical skills and problem-solving abilities.

I have a personal pet peeve when it comes to CSS questions during interviews. Don’t get me wrong, I love CSS – it’s my favorite language! 😅 But when you’re interviewing for a senior position, asking detailed questions about CSS, like the box-model or absolute position, doesn’t quite hit the mark. After all, CSS isn’t a programming language. It would be much more meaningful to inquire about how a candidate uses CSS features like Flexbox or Grid-Template in real-world scenarios.

There are certain JavaScript interview questions are stupid as well, such as distinguishing between var, let, and const,' or explaining concepts like closures or Higher Order Functions (HOC). Asking questions like these seems like seeking entertainment rather than assessing a candidate's JavaScript proficiency, leading to time wasted for both parties involved.If a company is looking for a good JavaScript engineer, it would be more productive to ask questions related to essential topics like the event loop or the Chrome rendering mechanism. These concepts are fundamentally important and can be very very challenging to answer right. Furthermore, it's advisable to avoid questions centered on specific frameworks. Why? Because frameworks frequently undergo updates, and certain features or usage patterns may be challenging to apply in the current version but easily resolved in the next update. As an example, not too long ago, many developers found configuring Webpack to be complex. However, with the advent of the latest frameworks, they all come with their own simplified 'webpack' equivalents, making it much more accessible. In summary, the point here is that instead of asking framework-specific questions, it's more beneficial to focus on in-depth JavaScript questions, as they have lasting value. Understanding concepts like the event loop and rendering mechanisms is not only about grasping the fundamentals but also about comprehending how frameworks emerged in the first place.

Given the choice between answering leetcode questions and tackling those CSS and JavaScript questions, I wouldn’t hesitate for a moment – I’d go with leetcode, no doubt about it.

Sometimes, you’ve got to stand up for yourself. Believe it or not, I once confronted the interviewers and told them their detailed and convoluted questions were pointless. It felt audacious, but I ended up getting the job.

Here’s a suggestion: Companies should provide a guide before the interview. This guide should include details about the interview’s content, how long it will last, and where the focus will be – whether on leetcode problems or experience-based questions.

And if you’re running short on time to prepare all this, there’s a simple solution: Use the first interview round to get to know the candidate better. It’s as easy as that, isn’t it?