I think the problem is not that there isn't enough if it (this may or may not be true) but more that it is very hard to figure out where it is. There are probably a good number of people who aren't presenting themselves well, despite having the talent, and get lost in the many applicants that don't seem to know how to program at all. Finding the right people is really hard.

I do think the need for technical talent is there, though - I've had a very different experience from what you describe.

To add some more detail, my experience was during the mortgage meltdown and fallout from that.

I agree with your perspective. I also think there are issues on the recruiting side. Sometimes it seems like they don't know what they need and they just list a ton of unnecessary stuff in the list of required skills.

I had a similar experience but during 2014-2016. It’s very common with new grads to spend 6+ months applying to get a job (even if you have internships or work experience). Almost no companies will take the risk due to whatever stigma.

It took me about 2 years after college until I got steady employment. I think I had sent over 750 apps and interviewed at over 100 companies. Most of the time they were trying to get a senior software engineer (5+ years xp) but considered me because I was probably one of the only people who had applied to their place. My interviewing skills were/are still garbage compared to the competition though.

> When I got out of college, I applied to about 250 jobs and only got 3 calls. Luckily one of those did pan out.

> I keep hearing how there's a war for technical talent. I guess I don't have any.

When I left academia, I struggled for 6 months to get a job. Then, 6 months into my first data scientist role, my company had to downscale and the whole data science team (me included) laid off.

I got three offers in two weeks following that, even though I was more or less the same candidate as 6 months earlier. That one line on my CV of having a modicum of commercial experience made such a big difference.

This is the reality. Having any work experience at all is huge. I thankfully/sometimes-by-accident worked 5 internships during my 4.5 years in my upper-middling college, and had no problem picking a place to work afterwards.

I had many friends who over-indexed on grades and had 0-2 internships. Many of them were really smart, but couldn't get the foot in the door for an interview.

Experience (including internships at legitimate companies) will get you past the the resume screen and recruiter call. From that point on, it's your interviewing skill that counts most.

True. The only experience I had was as a freelance web and android dev.

There isn't. If there were, they wouldn't put experienced candidates through all day interviews and fail them if they don't solve every leetcode question thrown at them.

Out of hundreds of applicants I screen, very few even have the skill to implement a standard algorithm with recursion in a language of their choice that I explain meticulously.

If it's really that standard, then wouldn't we just use a library for it to cut out a large portion of the development, testing, and maintenance?

If you can't do the curriculum standard, how will you build the non-standard? CS is very much an on-the-shoulder-of-giants field.

Then this still wouldn't be a great test. A person can use rote learning to memorize the standard portion but then be terrible when they are left to think for themself to create the non-standard.

I actually like fizz-bang interviews - just don't expect me to have algorithms memorized in a formal way. They give an interviewer the ability to see how the candidate translates the requirements into code, what their process is, how they think about the subject matter.

I agree about the shoulders-of-giants statement. That's sort of what I'm was getting at with my comment about using standard libraries. If I'm using pandas dataframes, there's no reason for me to build an algorithm/code to join multiple dataframes. If I were the interviewer, I would certainly view a candidate in a better light if they bring up this point rather than just jump into coding duplicate functionality.

Hip(n) {

If n == 0

  Return

Log(“std rec ex ” + n)

n -= 1

Hip(n)

}

On phone (so untested pseudo code), but this is my standard way of thinking about it. I think implementing bfs and dfs also helps to get it a bit more.

And I have needed to do recursion on web dev, because it’s the easiest way to deal with trees on your own.

But is that a skill that is required for lots of positions?

Recursion is a fundemntal part of programming, beyond the self-taught junior yes I would absolutely expect every programmer to be able to do it.

You learn it in highschool level programming classes & first semester intro to CS college courses.

Even if they won't specifically need to use recursion in their next job it marks them as someone not serious or about programming.

I'd argue that not being able to program in C marks someone as not serious about programming, but that's mostly because I know and like C.

I didn't say it was the only criteria, just that it is one.

My point is that these criteria are largely meaningless. It all depends on what you're working on. In some jobs, you'll occasionally need to write a recursive function. In others, it's probably a benefit if you can't.

I never personally used it in an interview (that's generally not how I do interviewing) but for someone experienced having not heard of recursion (and it's not such a complicated subject, you wouldn't need much "experience using recursion" to be able to understand it) would mean they haven't really dug into the art & craft of programming.

Just like I'd expect a moderately senior developer to be able to program in procedural, object oriented & functional styles even if they strongly prefer one to the others (and how would they know if they haven't tried all of them?).

Honestly I think recursion is overrated. Does anyone here really write recursive functions in production? I mean it takes up stack space (which on some systems is a systemparameter), creates functioncall overhead and has rarely advantages. Trees have more natural recursive structures, but then you basically always have cache misses making your program orders of magnitude slower than if you can fit the data in a linear structure.

I mean, I would be worried if a candidate is not shy to use recursion that this will blow up software perfomance. (But then probably after hire the senior will tell: dont use recursion here)

I think I've used it twice in production code over the last 20 years. The first was to traverse a directory tree. I wouldn't write it that way now since there is now a standard library to do what I was doing then. The second was to traverse an object's children logging certain pieces of data from the sub-objects. I didn't design that one, I just wrote it so I don't know if there was a library that would have done it for me. Fun to write though.

Generally, developer interviews are just stand-ins for IQ tests since it is illegal to give a candidate an IQ test. Seeing if someone can easily write a recursive function is a pretty good IQ test.

I guess it also weeds out the smart-asses like me who would question why I need to reinvent the wheel.

Finally it all makes sense. I was wondering about it and it also explains how the 'brain teaser question' like how many google engineers do you need to change a lightbulb or were there different questions, anyway, came about.

If you can take a problem where I'm thinking of a recursive solution as the interviewer, but you can come up with an iterative solution and explain why you think it's better, I would give you full marks.

Tell me, how many recursive functions are in your companies code base. (Or course you might not be allowed to tell; but do you know the number?)

No idea, I know I've written a few.

Thanks. How did you take tje stack size into consideration?

I would guess they'd try to use tail call recursion: https://en.wikipedia.org/wiki/Tail_call

I don't know what goes on in the minds of interviewers, but if I had to guess, they use recursion to test the interviewee's ability to reason inductively --- which, of course, is necessary for writing even simple loops. Maybe a question about loop invariants might be a good replacement.

Regardless, yes, I doubt many people write a lot of recursive functions, since the data structures people use tend to either be flat, based on arrays, or neatly hidden away in libraries.

The data structures people use are choosen by people. So it is a choice to have flat datastructures (probably by people how see the diadvantages of recursion)

If you are slapping together web templates with a Python back-end, then maybe not, but if you are automating industrial processes, build tools to improve data handling or work on any technical computational stuff, then absolutely yes. I expect someone to be able to reason abstractly.

There are still plenty of jobs that require excellent technical skills.

I learned recursive programming decades ago in high school.

(Solve the Towers of Babylon with recursive algo).

So, yes. Somebody calling himself a programmer or engineer should be able to produce this.

Someone calling themselves a programmer or engineer really only needs to be able to take the requirements they're asked to implement by their employer and implement them in an agreeable timeframe.

No more, no less. Doing so will get you paid for the activity of programming.

Along the way if you don't know anything, because you can't know or remember everything, you just look it up.

The end.

To me this seems similiar to if you want to call yourself a physician, you need to be able to speak latin. Its true (at least need to pass an exam), but it is only signaling, and no just having a few latin derived labels.