I can sympathize, but I suggest long term you figure out a way to get over this sentiment. If you plan to work in the industry for any length of time you absolutely must study to stay employable.

With few exceptions almost every segment of the industry changes how it does things about every six years. What you do now will be pretty out of date in mid 2020. I've been working as a programmer since the late 80s. If I step back in six year increments and look at the technologies I was using, here's what I get:

2011: Python, Django, MySQL, Jquery, Mercurial (not Git).

2005: PHP, CakePHP, MySQL.

1999: AIX, PowerBuiler, VB6, FoxPro, Access

1993: DBase 3, 8 bit embedded systems (68HC11)

At every stage of my career people I've known said there was no need to go learn new stuff. What they're doing will always be in demand. I'm talking about people doing things like ANSI 77 COBOL, RPG/3, and system 36 assembler. They were probably right, I'm guessing there's some orgs out there still using that stuff. But the options get smaller every year.

If you want to have your pick of the best opportunities available and be in control of your own destiny, and want to work in the industry more than 5 years, you're going to have to train yourself.

It'll help if you figure out a way to enjoy the experience and have fun with it.

IMO all but the most serious of side projects tend to not build enough experience to pass an interview for Technology XYZ anyways so unless a company is willing to deal with a newbie, and many are, it doesn't matter that much.

Unless you like to be immersed in that world 24/7, something has got to give.

Recent example I can think of was using GLPK to implement a dynamic allocation strategy for some spot instances for a pool of heterogeneous servers. I did not implement my own solver for the integer linear constraints but just knowing that allocation problems can be expressed as integer linear programs helped me tackle the problem in a way that others did not think of.

So I don't really buy the argument that knowing merge sort is useless knowledge because you never get to implement it. The value goes beyond just knowing the implementation. Same goes for other kinds of fundamental and timeless concepts and results.

When in doubt just remember this Feynman quote

“Right. I don’t believe in the idea that there are a few peculiar people capable of understanding math, and the rest of the world is normal. Math is a human discovery, and it’s no more complicated than humans can understand. I had a calculus book once that said, ‘What one fool can do, another can.’ What we’ve been able to work out about nature may look abstract and threatening to someone who hasn’t studied it, but it was fools who did it, and in the next generation, all the fools will understand it. There’s a tendency to pomposity in all this, to make it deep and profound.” – Richard Feynman, Omni 1979

There's a heavy bias towards the belief that CS, as it is currently taught, provides the "fundamentals" of software development and design. It does not, at least not as completely as the common belief seems to be. This can be reinforced by the current state of our interview processes. One has to re-prove one's understanding of such fundamental concepts, when the degree should, in theory, be enough, as it is in many other professions.

Conversely, a failure to understand fundamental CS concepts (invert a binary tree) doesn't preclude someone from being a successful software engineer (create homebrew).

I won't name names, but at least one large tech company in the bay actually runs evening classes for people interviewing (classes that are run by somebody very well known in the interview prep field: these aren't cheap sessions run by somebody internal).

When I found this out I could only laugh: I assume the HR department looked at the number of people flaming out of the interviews and thought "what could we do about this?"...and rather than treating the symptom (changing the way that they interview) they treated the problem instead (even more prep).

The company is Google and the interview prep person is Gayle from cracking the code interview.

Maybe if you are a college grad with 0 real life experience then maybe interview prep is necessary... don't know. I could be biased though. The last place I interviewed at they knew who I was, something about my software, and some of my online controversies before I even walked in the door.

The best preparation for interviewing at large companies is having a second part-time job somewhere in management. I held my first management position in a part-time job at age 24 and was once a director. I have never held a management position in the primary full-time career, which is a weird inverse of power-distance in some work meetings. Being a parent is also good experience for dealing with people.

What they need to provide education on isn't dominating the interview process... but drilling down on the proper information necessary for new candidate retention.

I have worked at places that are awesome and really work hard to ensure you are happy and constantly engaged in the work. I have also worked at places that completely suck full of benchwarmers with a million layers of abstractions so that code monkeys can feel a bit more confident. It is helpful to know if you are going to be miserable in the organization.

The candidate really does share some of the burden of figuring out if they will be a good fit for the organization, but this is often really hard to interrogate out of the interviewers even for experienced people.

Yes, this is bias. Most candidates aren't being hunted by employers. It's the other way around.

It's quite the opposite of "simple." It's a soul-crushing experience of being denied at every interview because you can't think out loud or do whiteboard coding and don't have a social media portfolio presence to fall back on. The only simple part is how simple it is to reject a candidate based on the personal prejudices of just one of the five different interviewers you have to meet with.

I call this the talent gap. When you are a newb or completely lack either experience or confidence in your skills life is harder. You have massively increased competition for lower paying jobs filled with more menial tasks. I have been there too. If a candidate doesn't want to be there they will invest in themselves outside the office. I spent as much time as I could writing open source software and language parsers while on military deployments.

Most developers I know are frequently hounded by recruiters because the demand for senior developers is stupid ridiculous.

Maybe in your bubble. My experience is that very few recruiters are hounding me, because most of them don't know I exist. I don't live or work in a tech hub, I don't work for a famous company, and I haven't published anything. I don't think that's a particularly unusual position to be in.

It's absolutely nothing to do with talent or experience, though.

Yes, but the next step is actually interviewing at companies. It's obviously the best strategy to coax an employer into being interested in you, rather than the other way around. But most employers typically have an interview funnel, which I think is what people are talking about here. It sounds like you're referring to an employer actively seeking out a specific candidate that they're interested in. While that does happen, it's probably not the typical interview experience.

Just be honest (immediately so), be humble, and have confidence that you will do your very best. What ever happens after that you don't really control. It is okay to be nervous, but keep it in context. Nobody is shooting at you. You aren't drowning. Your housing isn't burning down. It is just a conversation.

That might be an unfair characterization. But only just.

But really, if someone can describe the detailed psuedocode for an algorithm and explain its runtime characteristics, are you going to make them write out what they have just said?

Personally, I think the talking is a lot more valuable than the whiteboard. I rarely have to hand-write complete algorithm on a whiteboard, but I regularly need to communicate technical ideas accurately and succinctly. That's what I'm really trying to demonstrate anyways: of course I can code, but I can also organize my thoughts well and communicate them clearly to others.

Honestly, in my experience, most application problems can be reasonably talked through without writing any code.

I share your experience that most problems can be reasonably talked through without writing code, but most people here are talking about a specific kind of interview that does not work that way.

That would be a nice improvement as a first filter, IMO, but this isn't always the case. For Google, for instance, the very first step might be a 45-minute phone conversation with a bored engineer who just wants you to code up whatever tree-based structure and methods tickle their fancy. They might not even tell you what team they work on, or what they do. They have a script, and they run it from memory, and your experience and past accomplishments are out the window.

Now I know there are a lot of weak and timid personalities in the world of development, but once you put that blood into the water usually it doesn't take the sharks long to swarm on it. I have never walked away from an interview feeling dejected for asking the interviewer reasonable questions or attempting to qualify their assertions.

My reaction was the same as yours.

In addition how do you deal with resource mapping and best fit during allocation?

I think the multi-level allocation model works better than anything anyone else has suggested.

There's "need" and there's "need". The person without the solid computer science background may very well be able to solve all the problems at hand, but the person with the solid CS background is far more likely to come up with the fast elegant solution that doesn't fall over in obscure corner cases.

To use a concrete example for early in my career; I spent days and days trying to solve a problem by building a bigger and bigger pile regexps and if-else statements. Then my project manager (who had a PhD in CS) came along a just wrote a custom parser that solved the whole thing.

I know the plural of anecdote is not data, but I'd say that the typical PhD that I have interviewed has generally poorer useful coding skills than the person from a similar background who stopped at a masters or even BS and then wrote a lot of high quality code during the time the PhD was doing a whole bunch of theoretical work.

>To use a concrete example for early in my career; I spent days and days trying to solve a problem by building a bigger and bigger pile regexps and if-else statements. Then my project manager (who had a PhD in CS) came along a just wrote a custom parser that solved the whole thing.

It's MUCH easier to come along after someone has already spent days exploring the problem and can demonstrate the dead ends, then say "oh, you need a custom parser" than to start at the beginning and do the same thing. USUALLY writing a custom parser is overkill and it takes a decent amount of digging into a system to know when it's not. If you start out writing one every time something looks like it can be solved by an "if" statement, you'd never get anything useful built.

This can go both ways, though. Sometimes the fast elegant solution is too elegant for the nasty corner cases and a much bigger, uglier, but ultimately straightforward procedural block of crap is better.

The examples I've seen are from established businesses that occasionally slipped up in refactoring out hacks that were introduced to support deadline-driven requirements. A year or two later, that hack is powering the reporting for a huge portion of the traffic, and you have to be able to balance between (a) writing maintainable code that supports the hack for the short term and (b) working with the rest of the business to clean up the requirements so you can improve the system for the long term.

(b) is a skill that most interview processes I've seen completely ignore. And (a) often is downplayed (as "simple" or "easy") compared to more clever tricks - but knowing how to do the clever tricks might turn into a temptation to use them more than you should.

Maybe you aren't near water or writing performance-sensitive code 95% of the time, but the 5% of the time you're in over your head, being able to implement (or identify when to use) basic algorithms will save you a whole lot of time, money, and headache.

However, I strongly disagree with your statement!

I work on distributed systems day in and day out, and more and more I find that I'm using or building distributed data structures analogous to BST, HashTable, etc.

Not knowing the foundations of my field in and out would be a mistake!

Disclaimer: Never worked in financial tech, I have thought about this problem for 5 mins. This is unlikely to be an optimal solution to keeping a sorted set of distributed data. I'm just trying to show how basic knowledge of data structures helps in the field of distributed systems.

Lets say you need to keep a sorted set of sooooo much data that you cannot keep it all on one machine. I would imagine all financial services firms have some custom datastore which has "potential buy orders" and need to keep them all sorted by profitability to efficiently search/insert/remove from that datastore.

In such a situation, my instincts would be to create a distributed, redundant Heap. Now, how do you build a distributed, redundant Heap, without understanding how a Heap works? How do you even know what to look for if you don't know what a Heap is?

Now, lets say you've built it such that each node in your distributed network acted like a node in a Heap, and the left "pointer"(i.e. url to other computer) meant "less than" and the right "pointer" meant "greater than". Now you have this data store in production and all of a sudden you realize performance worsens over time... "WHY is this happening? Is there some memory leak?". You investigate and realize that all of your data isn't being distributed evenly! "Do I need to like.. shuffle the data around? How do I get it so that the data is evenly distributes?"

At this point if you do not know what a red-black tree is, what do you even google look for? Lets say you dig around for a while and find out about re-balancing trees. Now you have to implement it, and eventually you figure out that one of the best ways is to color your nodes. When a future colleague/manager asks, "What is this system, please describe it to me?" wouldn't it be nice to just say "Oh visualize it kinda like a distributed red-black tree. It holds XXX data, and ensures that it is always sorted and re-balanced for optimal performance."

With dozens of database stacks to choose from, many companies won't have anybody actively and regularly working in the database's code, nor in the OS kernel code either.

If, then, an individual can successfully contribute to the company without ever hearing of a red-black tree, what's the value in testing for it, past "this is how we've always done it"?

(How long it would take someone who doesn't know CS lingo to string together "tree" and "balance" and plug that into Google, I don't know, but I suspect it's not impossible to find.)

You've misunderstood me. I'm literally talking about building a distributed B-Tree or Heap. As in, a Heap which cannot fit in memory or storage of any one node.

Think: S3/DynamoDB is a distributed, highly available HashTable; _____ is a distributed, highly available Heap.

Just because those topics show up infrequently doesn't mean that no one's using them. Plenty of companies outside of Google, etc. are doing complicated things that require a solid CS background.

But it gives you a great opportunity if you're a less well known company without the same name recognition. If your process is the same as Google's, you'll have candidates picking between the resume stamp that is a stint at Google and your offer. If your process is intentionally somewhat different than Google's, but tailored to your own immediate needs, you'll have a wider pool.

In my personal experience, I've rarely had problems hiring qualified candidates, and my employer doesn't pay particularly well, and isn't located in a particularly large market. A company like Google who does pay very generously needs to narrow the funnel just to get the pool down to an actionable number.