• sugar_in_your_tea
    link
    fedilink
    English
    arrow-up
    31
    ·
    3 days ago

    We do two “code challenges”:

    1. Very simple, many are done in 5 min; this just weeds out the incompetent applicants, and 90% of the code is written (i.e. simulate working in an existing codebase)
    2. Ambiguous requirements, the point is to ask questions, and we actually have different branches depending on assumptions they made (to challenge their assumptions); i.e. simulate building a solution with product team

    The first is in the first round, the second is in the technical interview. Neither are difficult, and we provide any equations they’ll need.

    It’s much more important that they can reason about requirements than code something quick, because life won’t give you firm requirements, and we don’t want a ton of back and forth with product team if we can avoid it, so we need to catch most of that at the start.

    In short, we’re looking for actual software engineers, not code monkeys.

    • barsoap@lemm.ee
      link
      fedilink
      English
      arrow-up
      13
      ·
      edit-2
      3 days ago

      Those are good approaches, I would note that the “90% is written” one is mostly about code comprehension, not writing (as in: Actually architect something), and the requirement thing is a thing that you should, IMO, learn as a junior, it’s not a prerequisite. It needs a lot of experience, and often domain knowledge new candidates have no chance of having. But, then, throwing such stuff at them and then judging them by their approach, not end result, should be fair.

      The main question I ask myself, in general, is “can this person look at code from different angles”. Somewhat like rotating a cube in your mind’s eye if you get what I mean. And it might even be that they’re no good at it, but they demonstrate the ability when talking about coffee making. People who don’t get lost when you’re talking about cash registers having a common queue having better overall latency than cash registers with individual queues. Just as a carpenter would ask someone “do you like working with your hands”, the question is “do you like to rotate implication structures in your mind”.

      • sugar_in_your_tea
        link
        fedilink
        English
        arrow-up
        6
        ·
        3 days ago

        judging them by their approach, not end result, should be fair.

        Yup, that’s the approach. It’s okay if they don’t finish, I want to know how they approach the problem. We absolutely adjust our decision based on the role.

        If they can extend existing code and design a new system (with minimal new code) and ask the right questions, we can work with them.

        • r3g3n3x@lemmy.world
          link
          fedilink
          English
          arrow-up
          1
          ·
          2 days ago

          I’m just getting started on my third attempt at changing careers from sys-admining over to coding (starting with the Odin project this time). I’m not sure the questions you ask, while interesting, will be covered. Can you point to some resources or subject matter to research to get exposure to these questions? The non coding, coding questions are interesting to me and I’m curious if my experience will help or if it’s something I need to account for while learning.

          • sugar_in_your_tea
            link
            fedilink
            English
            arrow-up
            1
            ·
            2 days ago

            We stay away from riddles, and instead focus on CS concepts. We’ll rephrase to avoid jargon if you don’t have a formal education, or it has been a while. Here are a few categories:

            • OOP concepts like SOLID
            • concurrency vs parallelism, approaches for each (generators, threads, async,’ etc), and tradeoffs
            • typing (e.g. is a Python strongly or weakly typed? Java? JavaScript?), and practical implications
            • functional programming concepts like closures, partial application, etc
            • SQL knowledge
            • types of tests, and approaches/goals for each

            And some practical details like:

            • major implementation details of our stack (Python’s GIL, browser features like service workers, etc)
            • git and docker experience
            • build systems and other dev tools

            That covers most of it. We don’t expect every candidate to know everything, we just want to get an idea of the breadth and depth of their knowledge.

      • sugar_in_your_tea
        link
        fedilink
        English
        arrow-up
        2
        ·
        2 days ago

        We’re a somewhat big player in a niche industry that manufactures for a large industry. Yearly profits are in the hundreds of millions of dollars, market cap is a few billion, so low end of mid cap stocks. I don’t want to doxx myself, but think of something like producing drills for oil rigs and you won’t be far off.

        We have about 50 software developers across three time zones (7 or 8 scrum teams) and a pretty high requirement for correctness and very little emphasis on rapid delivery. It’s okay if it takes more time, as long as can plan around it, so we end up with estimates like 2-3 months for things that could have an MVP in under a month (in fact, we often build an MVP during estimation), with the extra time spent testing.

        So yeah, it’s a nice place to work. I very rarely stay late, and it’s never because a project is late, but because of a high severity bug in prod (e.g. a customer can’t complete a task).