Technical Screens

Being Correct More Quickly

I was talking to someone recently about getting "faster" at technical screens. The summary of my advice is that "slow is smooth and smooth is fast". There are so many emotions for me on this topic I wrote a separate post about hiring processes altogether. There are some more specific aspects to coping with the emotional challenges brought about by coding screens which I'll talk about here from my own life and try to provide some helpful strategies. If you don't want to read my opinions or talk about feelings, feel free to skip to the bottom for tips.

My Newfound Approval Of Technical Screening

I used to hate technical screens. Now I don't. Why? Consistency, fairness, and rigor. 

There are a few main arguments about these tests:

• They're unrealistic or select for candidates who can pass interviews

• They're biased gatekeeping mechanisms

I will deal with the idea that they are unrealistic first. My first argument is that, for the companies that pioneered these techniques, it actually is fairly realistic that you will focus on a narrow area of critical code where correctness and efficiency is paramount. On the flip side, I have seen many "easy going" or "realistic" interviews where the expectations were unconventional and unclear. As a result, I have come to love the classic challenge problems. 

The classic challenge problems are classic because they emphasize a combination of computer science trivia, algorithmic thinking, and problem solving. "Realistic" problems on the other hand, are closer to popularity contests. Yes, of course you wrote the code. It was an easy problem. But, you don't write SQL like I do, so you're a "weak no-hire". Companies that "go easy" on candidates are often just replacing rigor and clarity with bias. If you want to evaluate a candidate's communication or collaboration skills in a technical context, you should do so rigorously.

Getting better at technical screens helps you get more job offers. Period. That's plenty of reason. You may not like working at companies with this kind of interview but you might also not like working for others. Pay is a major factor for many people and I believe that, while it's not everything, it can make a big difference in your life, even if just for a few years. 

As for gatekeeping, these questions are definitely easier for those with computer science degrees. But so are most programming tasks. Addressing bias can happen in many places outside a technical screen from recruiting, to resume selection, to face to face interactions. If you feel that your technical screen introduces unnecessary bias, then I ask, why do you have one? The fact is, technical screens require technical skills and they only become gatekeeping mechanisms when they're not relevant to the job. To be sure, every step of hiring is a "gate" of some kind and the question is about what kind of bias it introduces. Technical screens are one of the easiest places to enforce fairness during the process. The real question is why so many companies use them if they don't need them.

Now, Let's Talk About Feelings (Specifically, Mine)

Here's how I feel when I bomb a technical screen:

• "I am taking so long. I need to start coding because I'll run out of time. [Fifteen minutes later] Why do I have all of these weird bugs, I must be careless."

• "I am angry because I am a great programmer and great programmers don't fail coding interviews. It must be someone's fault."

• "I am sad because I failed a coding interview and great programmers don't fail coding interviews so I must not be a great programmer... also my live's work has been a waste and failure."

So, basically, anxiety, frustration, depression ... the works. It's a rollercoaster. Also, it's full of cognitive dissonance, logical inconsistencies and blowing things out of proportion, mostly centered around my self-image.

For the "unbelievers"

Before I address those challenges, I want to talk to those folks who tend not to view the world through emotional coping mechanisms. I understand that emotions are messy and that being overly emotional can get in the way in the workplace or in your career. I don't have any issue with that except in one specific case: privilege. 

If you were raised with the support required to go to a great school and constantly learn to the point where you aren't challenged emotionally during a job interview or the impact of not getting the job doesn't cause financial stress, that is an immense privilege, no matter how hard you have worked.

Facing Reality

The harsh truth about technical screens is that if you feel like going slow will take you hours, you probably just won't pass the test. If you run out of "thinking" time and need to start "coding" time, you're coding time will likely not help you identify what you did not complete in thinking time. It's tempting to just try to force yourself to "go faster", whatever that means, so that you don't have to deal with this difficult truth that you're not getting the job and you're not as strong as you thought you were. This is the "trough of disillusionment" but instead of a hobby project, it's your livelihood and life's work. Ouch.

I should say something uplifting now. This is empowering. This has a solution. The explosion of bad feelings is predictable and addressable. 

So, my advice is to use this as a way to set more realistic expectations and goals. Note, this does not mean abandoning your goals or dreams, just adjusting the timeframe or intermediate goals accordingly. In the mean time, make practice more deliberate. 

Tips For More Deliberate Practice

• Steady daily or at least weekly practice

• Focus on learning, not completion

• Do a recap on each session and think "meta":

  • What "subproblems" are you struggling with? (search, sort, mathematics, time complexity)

  • What mental tasks are especially tasking or unnatural to you? (binary operations, recursion, tracking pointers)

  • How can you improve in that area?

  • What hints would you give someone struggling in the same way?

• Cheating the problem is cheating yourself

  • Seek new techniques or strategies before seeking answers

  • Consume the fewest and most vague hints possible

  • When you're ready to give up and check the answer, stop yourself at least once

  • Whether you succeed or not, review the answers

    • Try to understand what's fundamentally different

    • Try to reimplement them from your understanding alone

• Lean in on computer science lingo in problems

  • It's hard at first and gets easier

  • It's a good proxy for a well-defined problem

  • You'll spend more time solving problems

  • HackerRank seems to have more than LeetCode

• Understand the signature of a misleading question

  • It's difficulty rating is higher than you would expect

  • Lots of simple, clear rules or procedures that you can easily code

  • Hard to impossible to quantify the time complexity

  • The output is potentially achievable without actually executing the process