1. 7

    If the candidate spends too little time on the requirements, it means they are less senior than you expected.

    This is the kind of stuff that I’m not a fan of when it comes to interviews. Maybe instead of someone not being senior, they just recently had an interview where they tried to find out more requirements and were marked down for it because it seemed like they didn’t understand. Or maybe, they think they are getting a signal from the interviewer that they should move on. Or maybe, they just solve problems in a different way from you. Maybe they like to start sketching things out and asking questions along the way.

    I’ve had job interviews (even ones I ultimately got, at the level I wanted) where people used exactly these sorts of things to decide that I wasn’t as senior as they wanted. I’ve seen it happen to others as well. Interviews are complex, nerve-racking social endeavors. Processes that assume all qualified candidates ought to do things the same way or that there are definitive signs that a candidate is less senior are going to miss out on many good candidates and instead select for people who think like the interviewer.

    In general, I think it is much better to look to understand the person you are interviewing, not grade them. See how they approach things. See what things they like and what things they don’t. Find out how they approach software development and learn from it. There is no one size fits all evaluation criteria.

    1. 1

      You make some valid points, thanks for the thoughtful response :)

      Taking a single sentence out of context makes it look like there is a recipe that needs to be followed to the letter - that wasn’t what the post was trying to convey. But, I can see how the way some sentences were phrased could have given that impression.

      In my opinion, if you are asked to solve a vague problem, asking clarifying questions is a sign of maturity. That doesn’t mean that the questions need to be asked right after hearing the problem, or that you can’t sketch something from the start.

      There is no universal recipe, and most importantly, there are no grades. The goal is to get a sense of the candidate’s experience and problem-solving skills while working with them like you would with a coworker.

      1. 1

        I’m glad to hear that you don’t feel there is a recipe. :) I have met many people who do feel that. I will say that I can’t help be see that in your article.

        It’s a positive sign if they also do some back of the envelope estimations to get a feeling of the scale required.

        You can tell a lot about a candidate’s experience by how quickly they can spot failure modes and come up with elegant ways to solve them.

        You might not even have to ask much as an experienced candidate will highlight failure modes as they go, and find ways to mitigate them

        A seasoned engineer should know the core building blocks like the back of their hands.

        I know these may seem trivial. In fact, they may seem like just obvious things that more senior candidates ought to do. But I think they focus on how we ourselves solve problems and don’t think about others approaches. Take the first one, I never do back of the envelope estimations in an interview. So while of course that won’t be the end of anything, I won’t get those positive marks. Why don’t I do them in an interview? I have dyslexia and in stressful situations I switch numbers quite a lot, so I avoid doing that.

        I am perhaps harping on nothing and I admit as much. You’ve already said you don’t feel that there is a one sizes fits all solution. I just have seen so many talented engineers turned aside because their approach was different. I worry that sometimes we don’t even realize we are doing these things.

        Maybe they aren’t quick to highlight failure modes. Maybe they ruminate on things for a while. Maybe they have a bad memory for terms but are great at concepts. So when you start discussing dns or consistency models in the interview they sound like they aren’t familiar with them, but do actually understand them when applied. Or maybe you just asked the question in a way they weren’t familiar with and they are now just confused.

        I will say, I think you do capture the sort of thing I’m getting at very well in this sentence.

        Take the time to understand whether that’s really the case, or whether they instinctively skipped over a basic small-scale design and went straight to the point.

        This is exactly the sort of thinking I think is important. Understanding how this person thinks and how they approach problems in a way that can help you as a team/company. I personally don’t think that there is anyway at the end of an interview that you can answer the four questions you start the post with. This is what I mean by grading them. We can change from grade to the word you use, assess. I don’t think an interview should be an assessment. I think it is about coming to understand that engineer, understand what things they care about, what things they are passionate about, what things they like and don’t like, what sort of systems they’ve worked on, what sorts of problems do they enjoy, what sorts of values do they have the code they write.

        I think understanding these things is much more important and much more valuable than assessing how senior they are.

    1. 6

      This is very pleasing.

      Unfortunately, it’s also a bug in “inspect” (for me, Developer Tools in FF). Because I don’t want random web pages knowing whether or not I’m using dev tools, right? (I don’t want a cryptominer page to delete itself when I open dev tools.)

      Yep, detecting dev tools is a thing, according to StackOverflow and Github. From the discussion, it appears that browser vendors consider this a hole and try to close it, but there is an arms race.

      1. 3

        While that seems like a valid concern, it looks like the page doesn’t detect whether your dev tools are open.

        1. 2

          I’m no JS expert! I tried to play the game “blind” without the dev tools open (just click the snake and start using the arrow keys) and the game didn’t start.

          1. 1
            1. close all snake tabs
            2. open a new tab (about:blank) and inspect that. Pop dev tools out into a standalone window.
            3. visit the snake in that tab.
            4. try clicking it. For me, the game does NOT start.
            5. click into the dev tools window. Click back onto the snake.
            6. game starts.
            1. 6

              You can see in the source that it just looks for window blur. I did your steps above but instead of 5 just clicked on a another window, then the game played.

              window.addEventListener('blur', () => {
                  document.getElementsByTagName('style')[0].innerHTML += 'div:first-of-type {cursor: pointer;}';
                  snakeElement.addEventListener('click', startGame);
              });
              
              1. 1

                Ah, I missed the on-blur when I looked at the source! Good catch.

        2. 1

          In my opinion is should be a thing, but like with the notifications API, it should pop up a notification of the like “this website is detecting your using developer tools, is that okay?” Not that I can actually think of a valid reason beyond being part of cheat detection in the eLearning that I work on.

        1. 2

          I think this can be good advice for people. Expecting to learn a ton of things quickly and being unable to can be discouraging.

          But at the same time, I’m glad I wasn’t given this advice early on. Learning lots of different technologies made me become more and more interested in diving deeper. Seeing the differences between various things (javascript vs python vs java vs php) compelled me to explore further and led me things outside the mainstream.

          The author of this posts knows the person in question and so is in a much better position to give them advice. But for other people I think learning lots of technologies can be really beneficial, especially learning things that are very different from what you already know. Programming is fun, playing with technology is fun. Sometimes it is much more fun to dabble in lots of things than becoming an expert at one.

          So my advice is don’t over burden yourself by feeling like you have to know everything at the beginning. But have fun, explore, and be open to new ways of doing things.

          1. 21

            That’s a good question! Here is a quick braindump, happy to provide more information on all of these points.

            Basic physical needs

            IQ and focus are affected by these things:

            • get enough (~8h) sleep every day
            • stay hydrated
            • exercise cores / cardio a bit
            • (personal) meditation to improve focus / self awareness
            • (if possible) find a good work environment
            Disciplin

            creating good automatism allows to go faster and not break out of the flow

            • comfortable dev environment, that’s very personal
            • logical git commit
            • do one thing after the other. multi-tasking gives the impression of work but is very inefficient.
            • use a binary search approach for debugging
            • learn to say no nicely (some people try to push their work onto you)
            • learn to create focus times in the day with no interruptions
            Knowledge

            Learn how things work to be able to think on first principles. StackOverflow doesn’t have answers for everything.

            1. 5

              This is a great post and the advice here is greatly underrated in our industry. The difference in my quality of work on a day where I’ve had 8 hours of restful sleep vs. a day where I had 6 hours of sleep and am dehydrated, or have a lingering cold, or something similar is dramatically more than you’d expect. Everyone sort of accepts that if you have a migraine, or the flu, your work will suffer. But even the littler things make a big difference when you get to the (for me anyway) very high-level intellectual utilization that programming demands.

              As a process thing, whenever possible I like to create a personal branch and make a series of small commits as I go, knowing that I will squash them into more logical groupings before merging my work. This lets me experiment with a direction reversibly without forcing my peers to see 25 commits over a single workday.

              I’m also a big fan of carving out uninterrupted blocks of time (no meetings, chitchat, chores, etc.) but as I work fully remote this is likely both easier for me as well as more desirable to me, assuming people to some extent self-select into fully remote work.

              1. 1

                Thanks! If only I could post this to myself 10 years ago :)

              2. 2

                use a binary search approach for debugging

                What does this mean?

                1. 5

                  I assume somewhat like git bisect, e.g. we know that version/commit 30 has a bug, we know that version 10 didn’t. Rather than checking version 29, then 28, etc. instead check version 20 (preferably automatically, with a regression test). If it works, check version 25, and so on. This can make narrowing down issues much easier, especially when (a) every commit can be checked (e.g. it always compiles successfully, doesn’t crash during initialisation, etc.; this can be enforced with things like pre-commit hooks) and (b) the commit history has lots of small commits, rather than e.g. squashing large changesets into a single diff.

                  Note that the same approach can be taken when printf debugging, or stepping in a debugger: check the state near the start/input part of the code, check the state near the end/output part, and check the state roughly half way through the processing. This narrows down the problem to one half of the program/trace. Add checks roughly half way through the dodgy half, and iterate until the problematic step is found. This can be more efficient than e.g. stepping through each statement one after another; or reading page after page of logs.

                  1. 4

                    I assume somewhat like git bisect

                    Ah, I wouldn’t exactly call that debugging. Debugging, to me, is the step that comes after finding the problem commit, if there is such a thing.

                    Note that the same approach can be taken when printf debugging, or stepping in a debugger

                    Mmm-hmm. All fine until it’s race conditions you’re debugging. My week at work..

                    1. 3

                      Mmm-hmm. All fine until it’s race conditions you’re debugging. My week at work..

                      Yeah, consistently reproducing an error is an important prerequisite, but sometimes the most difficult part!

                      1. 1

                        Ah, I wouldn’t exactly call that debugging. Debugging, to me, is the step that comes after finding the problem commit, if there is such a thing.

                        In that case, you might still not “get” what’s happening. In that case, if you can figure out your input, the expected output, and what the output actually is, you have a good starting point.

                        From there, if you are judicious about choosing what part of the input to vary, you can quickly eliminate classes of problems. “Oh, the username probably doesn’t matter here because this shows up all the time”, “ah turns out that it’s this inner function that is returning problematic data, so stuff after it might not be the cause”

                        Draw a circle around the entire state of your commit, and then find ways to cut off huge chunks of it until you’re certain that the bug is in what’s left. If you’re not rigorous about this it doesn’t work well, but if you figure out “logical certainties” you’ll likely quickly isolate the bug

                        (This is part of why TDD works well in debugging. You found a snippet of code that is misbehaving. You dig deeper until you find a minimal problematic snippet. A quick refactor to place that snippet in its own function, and now you have a test case!)

                        1. 1

                          Yeah, I keep thinking race conditions. Where you could draw multiple circles that all converge at different points, all points being code that is obviously correct. The commit is right, it’s just probabilistically exposing the presence of a bug somewhere else in the code base. And that’s why TDD doesn’t work, because the bug isn’t in the minimal problematic snippet.

                          1. 1

                            I’m not real sure what your race conditions looked like, but you could maybe synchronize everything in a program (wrap mutex, log access, &c), or synchronize nothing, or something in between. That would be sort of binary searchable, or at least div-&-conquerable.

                            You’re not writing Go, by chance, are you?

                            1. 1

                              C

                    2. 5

                      Not sure this is what OP mean, but it reminds me of the approach I take to debugging. Your goal is to come up with a hypothesis that cuts the search space in half. Think through what could be causing this bug and try to falsify each possibility. This talk by Stuart Halloway does a good job explaining the approach. https://www.youtube.com/watch?v=FihU5JxmnBg

                      1. 2

                        Binary search is an algorithm that allows to find the solution in O(log(N)) attempts. It’s the same algorithm used by git-bisect but it can be used in the real world as well.

                        It’s part of the discipline because it forces to make assumptions and probe the extremities first instead of trying things randomly. Usually it’s possible to make assumptions about the bug location. Split in the middle with some debug statement, find which side is broken. Loop.