Having been on both ends it's also very true that there's a difference between "skills needed to pass interview" and "skills needed to do the job." The gap in the former is arbitrary depending on how pedantically silly the interview is made and it does not necessarily correlate to an equal gap in the latter.

Very true.

That said, sometimes they're basic skills. In one job a few back, I did a lot of resume-reading and phone screening. I used basic questions. A solid 50% of screenees failed FizzBuzz.

Now, it's absolutely possible that many of these were just nerves. Not everyone handled interview tension well! But it strains credulity for me to accept that being nervous makes half of software engineers forget how to do a loop, conditional, and modulo.

As a note, that doesn't mean 50% of engineers lack the skill. Those lacking skills will interview the most so for any position the distribution will be biased towards them. For example, if 10% of people on the market lack skills but they interview at 9 times as many places (failing at each) then each company will see 50% of applicants lacking skills.

Also true!

That said, it continues to strain credulity that 50% of interviewees for engineering jobs suffer from forgetting the most fundamental of tools in the face of an interview.

So I am led inescapably to the conclusion that there are indeed many people out there who only have skills on paper.

> that 50% of interviewees for engineering jobs...

that in 50% of interviews for engineering jobs, the interviewees...

Fixed to be more precise.

> But it strains credulity for me to accept that being nervous makes half of software engineers forget how to do a loop, conditional, and modulo.

Which is more improbable, that programmers who tend to be socially awkward and work alone in front of a computer and are not stage performers get "stage fright" during interviews, or that people with many years of experience getting paid as a programmer can't do anything? To me, the latter strains credulity.

Wasn't there a recent study that found that the main things modern interviews test for is lack of anxiety?

And when you're told that your career rests on how perfectly you do in this interview and that any deviations from perfection will make you fail, is it any wonder people get anxious?

I once almost failed the most common leetcode easy problem because my mind blanked and I implemented the wrong solution at first. Interviewer probably labeled me as someone with fake credentials as I didn't have time for their second problem as a result.

I've worked with enough people in both groups to have little difficulty believing either. More than once I've had an engineer on my team that we worked with by confining their work to somewhere where they couldn't do much damage.

Where are you located? I've worked for over half a dozen software companies in the bay area and we never had problems finding highly qualified candidates.

I was part of the hiring process durring a period of rapid growth. I noticed that difficulties in hiring had more to do with our own ineptitude in hiring people rather than short comings of the candidates. Simply put: engineers suck at interviewing other engineers. Often times, engineers would ask unreasonable questions or questions that had nothing to do with the job, etc. And it's not just engineers, even engineering managers and engineering leads often don't know what they're doing in interviewing until they get some experience with it. And even then, some of them insist on passing on highly talented people just so they can build up their own ego.

My advice to any company who thinks there's a "skills gap" is take a look at those so called skills and make sure you're asking the right questions. For each tech question you ask, first ask yourself whether that skill/knowledge is used on the job, if so it's a fair question. It's amazing to me how many times engineers will pass on candidates who have over 5-10 years of experience doing essentially the job for which their applying for, just because they don't remember some esoteric thing like linked lists which has little to do with modern software engineering, etc.

You be surprised at how many people would fail their own interviews. I think if companies ACTUALLY cared about hiring the right people for the job they would focus on adjusting their interview and recruiting process. Put your own people through the same interviews you're about to give candidates. If not every single person who's doing the same job can pass, it's a bad process, or you have bad people, but it can't be both.

I've asked in an interview for people to implement a multiply function using just addition, and a surprising number of candidates struggled with that one.

Of course if they struggled with that one, there was likely no way the would get the question where we asked them to write a function that takes an integer and return an integer that is the result of each of it's digits being squared.

I logged in purely to say those are pretty ridiculous interview questions. At least the second question is ridiculous. Idk why people think riddles are a good evaluation for the actual job.

It's not a riddle. We usually give a very detailed explanation on the whiteboard. Here are some example inputs and outputs. 45 -> 1625 36 -> 936 10 -> 10

Honestly this one is really to help us look at a person's thought process because there are multiple approaches to solve it. Usually people either go some variation of math route or a string manipulation route.

Examples of Programming Riddles I have seen first hand: How to invert a binary tree. Implement a binary search algorithm. Design an app that generates all possible phone numbers that a knight chess piece could create by moving across the dial-pad.

Those are riddles. This is not.

"on the whiteboard"

In real work there is a whiteboard, but everyone in the room is part of the discussion. You're set in the context of the work being done. You are aware of the end goals. You look up things on the internet. You experiment and write tiny programs at a repl. You think about the work being done both actively and while sleeping subconsciously maybe even during your commute. You have conversations with coworkers - stress free. When people say "it took me only 15 minutes to solve this at work" they forget the prior 2 years of context setting.

Your question is on par with a math problem. If they don't immediately think about string manipulation. I would rather see a candidate walk through some of their code on Github as better example of their skillset or having a candidate do a PR review over existing code shows much more insight. Reading code is harder than writing code, especially without context. Both activities highlight communication.

One of the best interviews I ever had was doing pair programming on a real computer. The interviewer was driving (removing typing gitters, editor issues) TDD style. Write a test. How do we get that test to pass? Is there a chance to refactor? Everything that appeared on that screen had to be communicated. That was by far the most fun I've ever had in an interview.

We've done some of the same pairing type activities during our interviews. And I could tell within 2 minutes if the person was used to pairing. When a negative review would come back a lot of the time it was because "their communication could be better". Vibe is a thing and pairing is a skill.

At the end of the day interviewing is about playing games and the employer makes the rules.

Binary search is not a riddle... it's pretty basic algorithms knowledge. Had to look up inverting binary tree. Apparently it's just reversing the ordering, which is also very basic as you learn about binary trees in your 1st year, 3rd at the latest. The knight thing, sure. Idk, I feel like programmers should know these things. It's like knowing calculus as an electrical engineer.

What's the elegant mathematical way to do this? I learned engineering school programming (read: programming with no standards or formal theory whatsoever) and the only thing that's coming to mind is num2str/split/multiply/concatenate/str2num, but that seems too easy for a real programming interview.

If you want to be tricky about it, you can do it in one line in Python. Let d be your original integer. Then

    [(d%10**(n+1) - d%10**n) / 10**n for n in reversed(xrange(int(log10(d)+1)))]

will be a list containing the base 10 digits of d as integers.

Technically, you need to do

    from math import log10

to make this work, but you can fit that on the same line with a little hacking around using __import__, such as this quick and very dirty attempt:

    [ [(d%10**(n+1) - d%10**n) / 10**n for n in reversed(xrange(int(log10(d)+1)))] for log10 in [__import__("math", fromlist=["log10"]).log10]][0]

Edit:

Just to carry this a little further, if we interpret "a new integer that's the result of each of the original integer's digits squared" as doing something like this:

    129 -> 1481

(i.e. 9 gets replaced with 81), then we can do it in one line like this:

     int(''.join([str(x**2) for x in [(d%10**(n+1) - d%10**n) / 10**n for n in reversed(xrange(int(log10(d)+1)))]]))

Ooh, nice.

You can detect each digit like this:

For example, take 999 (N). Using only math, how can I determine the value of each digit?

(be sure to take abs(N) and record value of N/abs(N) for later)

res = N - (N - 1). Digit = res + 1; If Digit == 10, Digit = 0.

So, given that function to find each digit, you can build a loop using 10^i to detect each digit (subtracting the sum of all preceding digits and dividing by 10^i to trim the lower order digits you've already resolved).

We'll need a place to store each digit, such as an array.

Of course, this assumes integers in base 10. If they are another base (8, 16), replace the 10^i above with the base.

It's also ambiguous as to if the function should just return a concatenated version of the results or some possibly a sum.

In any case, using a cast to string would be way easier.

Thanks!

Well the mathematical way of doing this involves doing a Mod 10 to pull off a digit and then incrementing a number that multiples the mod 10.

I've also seen incrementing an exponent. And I hear from more math oriented people that there are other ways.