Let me echo what tytso said. I work / have worked / have gotten job offers for a bunch of companies you've heard of and I would never consider < $100K+ unless for a pre round A. At places I've interviewed and at places I've hired I think there is an expectation that there is at least one language that you know really really well. If it's java, I expect you not only to know the syntax backwards and forwards but to have used at least one of {groovy, jruby, jython, scala, clojure}, to be able to discuss design patterns, failure modes of the gc, how to detect them and how to work around them, to know things like how to minimize memory usage, to have opinions on how the jvm team did generics and possible alternatives, to have used at least one common editor and know keyboard shortcuts by heart, to know how to use associated tools like ant, jar, ivy, maven, sbt, etc.
So my recommendation is you need to have at least one tech stack -- and I'd avoid .net, but some companies do use it -- where you're an expert and you're the person in your company that people come ask questions of.
Earl's on target here. If you spend five years obsessively learning the ins and outs of a particular language or technology, getting to know its strengths and weaknesses, and ideally at the end of that five year tenure, started contributing to advancing the state of the art of that language or technology, you'll likely be in the top 10% or more of that area.
I assumed that anyone who spent five years in an area would inevitably get to that point, but upon further reflection, it takes five years plus a passion for excellence and not being satisfied with "good enough". And that's something else companies look for --- they want 'A' players that are always looking to see how they can improve themselves, their environment, and help improve the people around them.
The good news is that in my experience there are many people who have come out of the military do have that ethos. So although I don't know you (Joshua) beyond looking at your electronic presence, I think you have a pretty good shot at becoming a world class expert. I definitely would encourage you to go for it!
I agree with some of what you said here, and maybe i have misunderstood what you're trying to convey, but allow me this little rant here...
Some of it seems excessive. I've been developing in C and Java for 11 years now. I make a tad under $100k and live in Atlanta, Ga. I have yet to need to know or discuss failure modes of the GC by heart, how to detect them and work around them by heart, how the JVM team did generics and possible alternatives, nor to know keyboard shortcuts by heart. I have however come across these things in my career and had to takle them. Guess what I did? Googled. Then I got back to writing code, what my job soley exists for.
It seems absurd that any company would require these things. If I was interviewed at a company asking me to talk about these things in the interview, I would walk out simply because I would feel it was completely irrelevant to how good of a software engineer I am. I really hate being interviewed by people who are more interested in asking obscure questions that just want to prove how smart they are (when we all know they probably just looked up that question/answer before the interview), rather than talk to me about coding and problem solving.
Things like memory use, basic algorithms, what design patterns are, collections, code quality, software development life cycle, unit testing, general coding problems, maybe some things about hibernate (if you use it), basic database knowledge, their favorite language and why and let's not forget overall personality and how they will fit into your team are far more important areas to cover. Not some obscure questions that will be used maybe once in your lifetime or on extremely rare occasions at the new job that can also be looked up on google when you need an answer for that rare occasion.
I even shutter when I think about design patterns being discussed because they're so over used and bad developers focus way too much on putting well known ones into their code base even when it may not be called for and just create so much more bloat for no good reason other than to feel like they're smart. An understanding of design patterns is great, but forcing people to describe any of them but the well known basics is just dumb.
The interviews my team gives exist around these things and I can honestly say we have yet to hire someone that didn't know their stuff very well and fit into the team nicely from the start.
I have only been without a job for a max of 3 months when I was laid off once and I have job hopped a lot, especially in my early career (which, there is a dirty secret there... That's how you make more money when you're staring off!). I have walked out in the middle of interviews before when it was clear that the person was asking obscure questions just to feel superior. I don't want to work with people like that...
Interviewers need to focus more on asking questions that software engineers face on a daily basis and less on odd and obscure things that can easily be researched in a short amount of time online when and if the problem ever presents itself.
I apologize if I got off topic or missed your point entirely. I was just having a conversation with someone about this very thing and it seemed relevant based on what I read.
I have yet to need to know or discuss failure modes of the GC by heart, how to detect them and work around them by heart
Knowing - and having experience of - the failure modes of your platform is one of those things that is invaluable.
Knowledge of GC issues in the JVM is something that indicates (a) you've worked on applications that tax the JVM, and (b) you are the person who people turn to when the shit hits the fan.
Sure, Googling will help here, but you need to have a pretty good understanding of the problem space in order to understand what to Google for. For example, how do you get from "the application is slow" to a query for "sizing the New Generation in the JVM garbage collector" unless you already know when to suspect GC issues, how to use jvmstat etc etc?
Well, obviously not everybody knows everything and if you're a great candidate but you've never had gc issues with the jvm, any good interviewer will shrug and move on. Also, and I hope this was obvious, but my comments were directed at experienced engineers and new grads are graded differently. But knowing basic data structures? That's doesn't make a good candidate, that's a low bar of a prerequisite. And if you haven't put the effort in to learn at least one editor -- and I don't care of it's vim, emacs, eclipse, visual studio, intellij, etc -- really well, I'll give you a thumbs down. I'd expect someone to know how to use bash and the unix toolchain as well -- the ability to use the shell + command line tools will save you lots of time, and I'd be pretty pissed if I saw a coworker blow a day writing in java what would take 5 minutes in {bash, command line utils, ruby, perl, awk}.
I expect particularly people whose strongest languages are java or c++ to know about design patterns. Saying you hate them and giving a good reason (I agree) is fine. But you ought to know what some of the common ones are.
Similarly for generics -- most good java engineers have probably wondered at some point why eg if AA is a subclass of A, why ArrayList<AA> is not a subclass of ArrayList<A>. There are lots of different designs for generics, with different strengths and limitations, and I would be surprised if a great candidate hadn't been exposed to more than one design and spent some thought or an afternoon reading language blogs.
Etc etc for gc.
tl;dr -- knowing basic data structures doesn't impress me; if you don't, we'll just end the interview early and have a discussion with our internal recruiters into how the fuck such a bad candidate got brought in. And my description above is what it takes if you want me to go over to the vp of engineering or cto and say do whatever it takes to hire this person.
So my recommendation is you need to have at least one tech stack -- and I'd avoid .net, but some companies do use it -- where you're an expert and you're the person in your company that people come ask questions of.