4
melakite
230d

Question: How would you reimagine the dev interview process, trying to make it efficient to find ingenious freshers?

I'm gonna be hiring full MERN stack dev freshers soon. I hate coding interviews, and I just want to test their ingenuity and problem solving, not if they can code a textbook algorithm.

Plan so far was to ask them questions like: "What happens when you like a link in the browser" to gauge how deep they could track a request and understand the internet infrastructure.

And make them audit gpt generated react code, and optimize it.

What're your thoughts, folks?

Comments
  • 1
    1. it's a vague question that will make the candidate wonder what you're asking for. "some JS on Facebook.com captures the event and sends an ajax request to their server which probably calls a service that stores the like in a DB" is that an OK answer?

    2. optimizing a tiny piece of code often doesn't feel meaningful as it would have no practical impact unless you had 10.000 items - unless the original code is horribly convoluted. I mean...sure a great react dev could probably detect what's not perfect about some hook but some seniors could say "šŸ¤· premature optimization? really? works fine for all real world applications. barely worth the time to optimize it"
  • 4
    If you focus on specific questions for a specific framework, you will filter out everyone who didn't do that framework. That includes everyone who could easily do it but had no opportunity yet.

    If you ask vague questions, you filter by the ability to extract the neccessary information from an uncooperative client. That might be an important skill for the position to fill or not (normally it isn't for a junior).

    I would expect ingenious freshers to not have experience and skills in the fields you want them to do. But i also would expect them to be able to gain that experience and skill reasonabley fast. So don't test for existing skills and knowledge but for the ability to aquire both as needed.

    Maybe let em actually work on a part of your actual codebase and fix one or two beginner/starter bugs on a dev machine. Or just go for the required softskills and use the probation period to separate the code monkeys from the devs.
  • 5
    I find conversations way better than writing specific code. "how would you approach this" is way better than "write this code". But then the results are subjective and the corporate world hates that
  • 2
    Plenty of good answers here.

    @Oktokolo 's is definitely a very interesting one.

    I would probably, (no doubt dictated by what I'd like to be asked in an interview) ask questions related to general reasoning (kind of like fang questions).

    It doesn't matter if they get it right or not. The point is seeing their reaction to something they can not anticipate, as I believe that's a much bigger asset unless the position is very very specialized (which I don't think is the case).

    Ideally, they should show not memorized knowledge, but willingness to learn, openness to discussion, and, dare say, some shyness. (Helps in weeding out wannabe rockstars).

    Then again, it's not exactly common to find candidates that are good at this, so please don't be jerks, and don't low-ball them like mad.

    Believe me, those are rare, and huge assets. Treat them with the respect they deserve.
  • 0
    @iceb totally agree bc it tests not only tech skills but communication skills and is a way to gauge personality. Leetcode is straight garbage and should only be used to filter out a huge pile of resumes that giant companies get, not some small place in Arizona
  • 2
    I think the goal is to make sure they know you are a trustworthy individual and that you and the company can provide them worth. Get a sense of their goals and how they breakdown situations, then think about the stuff you guys work on and try to relate and converse from there. Then during that, you can test out if they are bullshitting or not because you get into similar wavelengths. You can start to ask more general architecty questions and fine grain questions without demanding it.
  • 1
    I talk about code and projects they’ve done. It’s not hard. Trivia questions are useless.
  • 1
    Ask them to show you a project of theirs. How do they talk about it? Are they passionate? Are they happy that they learned things? Suggest a correction. How do they react? Do they thank you or are they offended? Do they understand their limitations or are they affected by dunning-kruger.
Add Comment