DEV Community

loading...

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

Collapse
pclundaahl profile image
Patrick Charles-Lundaahl

I feel like this is pretty fundamental, really. I've certainly brought these up in design discussions with my team at work before, and they're something I think about frequently in my hobby projects, as well.

Collapse
steelwolf180 profile image
Max Ong Zong Bao

Not really I think it's more of an opinion or best practices that the company might adopt. Which is similar to design patterns that might not be that common as well. Like you don't need it unless you are required to use it?

Thread Thread
pclundaahl profile image
Patrick Charles-Lundaahl

I mean, I suppose you're right in that you don't absolutely need them to write working software. But I think the same could be said about things like tests, or not littering magic numbers throughout your code. They aren't necessarily going to make your code work better now, but they've got a very high likelihood of making it more maintainable!

Anyway, I'm sorry you got stuck on that question! Regardless of the topic, getting stumped in interviews sucks.

Thread Thread
steelwolf180 profile image
Max Ong Zong Bao

Yeah I'm not against it for code maintainable sake. Which I will usually chuck it as a nice to have thing. Over something like clean code, pair programming and TDD.

In fact it lead me in reading it more in depth to explore design patterns and SOLID more. It just makes me more smarter in future interviews to ask questions.

What are they are expecting for me roughly in a interview before I go for another one to prevent myself being caught off guard.

Thread Thread
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

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.