DEV Community


Discussion on: What is the worst question you have ever been asked in a job interview?

pclundaahl profile image
Patrick Charles-Lundaahl

Hm. I feel like there are probably a pretty huge range of answers there, depending on who the interviewer is, what company they work for, and what department they work for (could be HR, a technical person from the prospective team, a technical person from a different team, a recruiter, etc.). I'm also not sure that I'm really the right person to answer - my interview experience is pretty limited. I have opinions on things like SOLID because I spend a lot of time thinking about, reading about, and practicing software engineering, both at work and in my free time. I've also worked in some pretty gross codebases, and I've seen what happens when people don't keep things organized and adhere to things like SRP.

My (limited) understanding is that interviewers are usually trying to gauge you on at least two axies:

  • Technical fit
  • Team/culture fit

Both of those have a pretty huge impact on how much value you're likely add to the organization.

I would also say that, if they're thoughtful about it, they're probably also trying to gauge your fit for the industry or domain you'll be working in: an engineer with an interest in ecommerce is going to be more valuable to an ecommerce company than one who is interested in game development, simply because they have spent more hours thinking about the domain. When they are given a problem to solve, they'll have more context that they cam draw on.

As for not getting caught off guard, I'm inclined to say there are probably two aspects to focus on: 1) building your knowledge in the relevant areas, 2) your ability to handle being caught off guard when it does happen.

Point 1 is something you can solve through Google, reading, practice, and just being generally curious about your craft. Generally, I would say be curious about the fundamentals.

Point 2 is equally important, though - you're going to get caught off guard, evem after years of experience, so being prepared for it and having a plan for how to recover is really crucial, I think. A lot of the time, interviewers are explicitly trying to test the boundaries of your knowledge. It lets them find out what you really know, and also how you handle not knowing.

For concrete areas, I'd be inclined to focus on things such as:

  • SOLID principles
  • Core design patterns (the problems they solve, what the costs of using them are, possible alternatives)
  • Requirements gathering and analysis, critical thinking
  • Underlying tech (HTTP, CORS, etc.)
  • Different solutions in your problem space and their tradeoffs (e.g., for web developers, what are the benefits, costs, risks, tradeoffs, etc., of using server-side rendering as opposed to SPAs or SSGs?)

Again, these are just bits and pieces I've concluded from my limited experience. Please take anything I say with a fairly hefty dose of salt!

Thread Thread
steelwolf180 profile image
Max Ong Zong Bao • Edited

It's a extensive list :) we all have our preferences and in the way we do things in the type of jobs, we are of interested in or has inclination with.

I just chuck it as experience and seek for other pastures. As startup has always been about culture fit. Which I just guess I do not fit them and its alright. Since there is tons of companies or jobs out there.

For me, I'm more of scrappy person to get stuff done. Even if I'm bad at it for the start. I will figure out a way to do it.

Which is why I'm not really that opinionated or dogmatic in my way. Sure sometimes I wish there will be certain expectations I see in others. but I won't be bothered with they are not having clean code, good test cases and easy to understand documentation. I just figure it out to deal with it along which sadly can not be verified through a short interview.

Besides I feel we should be a voracious learner to take on multiple mental models to solve a problem. Combine with interest in learning soft skills needed for us to be better communicator & developer, leading a team and dealing with people who might be less technical inclined to get something done.