Anyone who's interviewed software engineers for a tech company knows there's a skills gap, and it's very real
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.
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 in 50% of interviews for engineering jobs, the interviewees...
Fixed to be more precise.
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.
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 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.
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.
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.
[(d%10**(n+1) - d%10**n) / 10**n for n in reversed(xrange(int(log10(d)+1)))]
Technically, you need to do
from math import log10
[ [(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]
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
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)))]]))I've also seen incrementing an exponent. And I hear from more math oriented people that there are other ways.
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.
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.