With my BSCS, I worked in aerospace, telecommunications, finance focused MoM (we are dated by our buzzwords), manufacturing supply chains, indigent health insurance, auto sales, dark pool trading, and medical device manufacturing.

I'm now out of software because I was a B player, and my freshness date expired.

Now I'm a long distance semi truck driver, and I'm currently sitting in my Kenworth T680 as I write this. It's the ultimate experience if you're a loner.

I miss the money, and the software writing itself, but I've never had a meeting since I started truck driving. I don't miss the development practices churn, or what I call work about work.

I do still automate some parts of my personal administrivia, mostly with python and Bash.

As for truck driving ... "They were hiring."

EDIT: I do enjoy it, it's a big and beautiful country, and the work is pretty easy.

I think a few drivers are worried about it, and a larger number are dismissive of it.

My opinion is that it's going to happen because it's possible, and because it must.

There just aren't people who are willing to be truck drivers. Shortages on the shelves and rising prices are already happening, because there's more things that need shipping then there are drivers to pull them. it's not just because of Amazon, it's everything.

Side note, if you like the idea of exposure to different fields as a software developer, blockchain is going to be pretty important in trucking, for bills of lading and similar record keeping and tracking.

That said, should you change your track from pure EE?

My personal experience in hiring has been that people with pure CS bachelors/masters are usually a worse fit for highly technical roles than those with another STEM degree. I think this is because it is harder to teach yourself electrical engineering than entry level software development.

A average candidate knows how to program. A good candidate knows has deep domain knowledge in something. A great candidate has deep domain knowledge and can turn that into code.

And while "everyone can be a software developer" right now because the demand is so high (we're in a middle of a mini-dotcom-boom), it won't always be that way. Expect to see saturation in the next few years. Yes, the self taught person who works their butt off will be able to make it, but it won't be common, or will be limited to entry level positions, which will become more and more competitive. We're already seeing this happening a bit.

I'd be willing to take either side of a debate for "is there a shortage of people who, when given tight specifications for a piece of software (write a function that takes X as input and provides Y as output) that enumerates all of the corner conditions can produce a program in a language that they are familiar with."

At the same time, the "person who can work with the business user on the software, think about the architecture of it, identify the design necessary, come up with the estimate that actually matches the time frame that it will be done in with a reasonable error... and produce software that takes X as input and provides Y as output while being aware of where the edge conditions may exist and ask for clarification on how it should work"... I believe there is a distinct lack of that portion of labor.

Furthermore, there is also a lack of people who are able to move from the first labor pool to the second, and a lack of mentors who have the time and ability to help that group move to the second.

I don't think its incredibly difficult to hire an entry level person as long as one sets the bar low enough and has people within the origination who are capable of providing the design. On the other hand, it is very difficult to find the people who can give the necessary instruction to the entry level people to allow them to become productive within their ability.

As an aside, I also find that within the entry level group... there are a sizable portion that have the attitude of "I learned language X and that was hard enough, I'm going to stick with it and not learn anything else." That X can be found for all languages and none have the monopoly on it. However, it is disconcerting for me to see those individuals... I started out as a C programmer, and then Perl (full stack web - some JavaScript in there) and then Java (enterprise), and then Java stand alone (swing application)... and while I'm still a Java programmer, I can see other languages looming on the horizon. Java will become the COBOL, and while there are still COBOL programmers out there, its not something that one wants to get stuck in for another two or three decades waiting for that last app server to be turned off before they can retire.

----

At the "anything past entry level", I still find that the number of qualified applicants drops off substantially. For entry level, the applicant pool is very, very large. I am now despairing that many of that pool don't have the necessary skills to move beyond following someone else's design.

I don't think this will neccessary be the case, Java is far from being in maintenance mode. It looked like it would be some years ago but there now is a lot modernization going on, both inside the language itself and inside the ecosystem. Maybe it might loose its top position, who knows, but I don't see it being practically dead anytime soon.

Sure enough there will definitly be those weired "COBOL like" enterprise things building on top of all of the bad ideas from the early Java days which stay forever and which nobody not already familiar with wants to touch for good reason.

"Go hook it up to that PDP get it working and go an talk for Brian and work out with him how to use this to digitise the 3d droplet cloud his experiment is producing.

It didn't even come with a cable just a 20 sheet photocopied technical manual.

Real world analogy: When I was trying to renovate my place, I had to look for contractors/carpenters. All the good ones are overbooked for 4-6 months out, many only take referrals and won't even talk to you otherwise. At -the same time-, a bunch of contractors I called said they retired or changed field because there was no job and business sucked.

Software engineering is heading a similar way. The barrier for entry for "I know how to build an app" is very, very low. But the "skill ceiling" is very, very high. There's a ton of positions, but when anyone can self teach or do a quick bootcamp and get in, well, there's a lot of competition for these jobs. At the higher end though? There's also a lot of jobs...but competition is non-existent.

I’ve never prepped for a tech interview and I’m never going to read a stupid book that’s supposed to coach me.

What am I prepping for? I’ve been a programmer 10+ years. I’ve had 10+ years of “prep”. Is that “fresh” enough for you?

Tech interviews have gotten way, way out of hand.

For better or worse, this practice will take their company wherever it’s meant to go.

- None of us know everything about every environment, even though we often imagine we do

- If you want a job, and spending a few hours prepping on data structures and algorithms (either to improve your performance, or to verify your performance is in fact perfect) will help your chances of success or your confidence, why not do it?

You might want to consider:

- Just because you don't want to follow the recruiter's advice, it doesn't mean it's a 'stupid book'.

- Although the recruiter mentioned 'programming problems', the problems in the book may test a wider (or just different) range of skills than what you (or I) consider 'programming'

- The fact that you've 'never prepped for a tech interview' may have impacted the set of environments in which you have worked, and it may be hard to know whether you would enjoy working in those places where preparation is 'table stakes' (i.e. necessary but not sufficient) for success.

- Companies that interview in ways that require/expect some preparation might be (intentionally or unintentionally) filtering out candidates who are not willing to do what is required to achieve their aims. (If you're not willing to spend a few hours with a book to increase your chances of landing a great job for the next 2-3 years, then maybe you wouldn't be willing to learn whatever JS library is required to succeed at your next project.)

You and I have not yet had the pleasure of meeting. But I know other people with 10+ years of coding experience, and the majority would improve their chances of succeeding at a given interview loop, by preparing using 'cracking the coding interview'.

It seems to me that you're presupposing that "success" equates to ending up with an offer.

I posit that for some professionals, success is actually deciding (ideally mutually) if employment is desirable/beneficial. The decision may well be that it is not, but that would still be a success.

In this latter situation, preparation time might be better spent researching the background of the team on would be joining, the company itself, and technical and cultural environment, in order to ask better questions during the interview, rather than studying so as to achieve what could be, arguably, described as gaming the technical screening portion of the process.

Be aware of this: 99% of teams/companies out there are not solving quantitative problem. They are throwing chunks of code from stackoverflow at some app. They use every framework, tool, methodology of the year and look for those names on your CV.

Yet, there's a niche where people do data driven development, understand and use statics and mathematical models, and do real engineering like aiming to solve a problem with the minimum amount of complexity and code.

Aim for that. There are teams like this in Google, Amazon, Facebook and other smaller companies. You have to go and hunt for those. Stay away from coder jobs.

hardware jobs pay less. many times, much less.

The interview process for software developers is as you write, terribly broken at a lot of companies from the point of view of most developers. I do not see this changing in the foreseeable future and it does not matter what software you have written in the past, you will get the opportunity to prove yourself all over again for the rest of your career.

One possible solution is to work for yourself. This solves some of your issues and introduces a whole different set.

You really don't need to know a lot. You choose to know a lot probably because you either feel uncomfortable not knowing the whole picture, or because your just curious. I have meet a ton of great developers that their knowledge base was their language and libraries because that was all they needed to know to be great. One guy I know that hires peoples ask one question in interviews to gauge peoples knowledge "You click the address bar of a browser type in www.google.com and push down enter on the keyboard what happens?". There are some people that give 5 min answer and some that could spend a hour just explaining the keyboard interaction with the operating system across 4 different operating systems for a hour. Find what domain you enjoy and just do it.

Everything is "just" something, and their is no way around having to do cumbersome work and making decisions to get some where doing anything.

You should stay in software because you want to. If you need others to validate a reason for you then you probably should get out while you can. Keep it as a hobby, but the second you start questioning something like this you either need to try something new or go on a camping trip and drop some mind altering drugs so you can find a answer. Maybe do some volunteer work in a third world country.

* Everyone can be a "software developer". Everyone can also be a [whatever]. Why would you want to have a whole profession for yourself? If you don't have to prove yourself during the interview, you'll have to do it on the job. This is not going to be different somewhere else. In general, is better for you if your colleagues have to meet a minimum competency standard.

* You have to know _a lot_. There is a lot and there is a lot that changes. There is also a lot that stays the same and a lot that you can transfer from an area to another. Once you are a good at design, architecture, Test Driven Development, Pair-Programming etc. you are not going to forget everything just because you have to use a new programming language.

After all it's "just" software. How you solves the problem and write your code internally is going to influence how good it works (bugs, performance) and how fast you can change and improve it. People will care about that. Usually, you are going to work in a team and your colleagues will also care about your solutions.

> "For some reason, companies do highly mistrust my skills and degree. Other jobs, equally well paid, do not require this."

I think if other jobs were able to directly test your technical skills in an interview they probably would. I personally hate whiteboard style interviews as well but, having sat on both sides of the interview process over the years, I see a lot of value in seeing people's code. Personally my preference is a take home coding test, but interactive coding is fine too if the problem isn't too tricky. Probably this is because I am self taught and don't have a degree to lean on that colors my opinion so take my words with a grain of salt I guess.

More that once I've come across such crossroads, and the answer for me is:

(i) Find a niche in which you can excel, master your domain and then people will "care".

OR

(ii) Don't worry about how others perceive you as long as you are having fun along the journey. Find a way to stay happy.

If you’ve got a talent for it, then look at your career in terms of how you can increasingly fulfil that ‘how’.

That could be your own business or a company/vision/mission that really sings to you.

You might get a few bad experiences along the way but they would only serve to remind you of that ‘how’, and give you more resources to do it better.

For me that means blending my passion for proper agile, coaching, and compassion, into my dev workflow such that I will always leave a team or company better than I found it. There have been plenty of situations where I failed to do that but it only empowered me to learn and adapt.

That’s not a yes/no answer, it’s just another perspective.

The key question is “Do you like the work?”

So you have the opportunity to ask “Do you like the work?” under many different circumstances.

My strategy is to build stuff with other folks, create a value and try to transform that to real money (with a startup for example).

I think your real question is more around what you wanna do with your life.

Because you are already heavily invested and is part of the current elite of software engineers, probably. If you still like it, why leave it?

https://youarenotsosmart.com/2011/03/25/the-sunk-cost-fallac...

I don’t give any credence to the college someone graduated from when I’m conducting job interviews. I have a computer science degree, but I’ve seen too many people graduate with a computer science degree that cAn talk theory all day long but couldn’t program their way out of wet paper bag. On the “smart and get things done” quadrant, they were completely on the “smart” quadrant.

I have been a software developer for over 20 years, but unfortunately I spent way too long at one company and became an “expert beginner”[1]. So I’ll just talk about the last ten. For all intents and purposes, I may have gotten three solid years of usable experience out of my first 12. I’ve had 5 jobs in the last 10 years - my interview experience.

1. A semi technical interview. No white boarding. I just described my experience and thought process about delivering results. They were a startup and liked my practical experience delivering code.

2. I did a pair programming test where they had a project with failing unit tests and I had to refactor the code to make the tests pass. I think they had a written test with some practical questions and a coding part.

3. By now, my years of experience and practical worthwhile knowledge had finally gotten somewhat in sync. I was applying for senior level roles. They asked technically questions, a whiteboard interview where they wanted me to design a scalable, fault tolerant system and a normalized database system. They quizzed me on my design decisions.

4. A team lead position where the hiring manager asked me about my 90 day plan to create a software development department and to come up with a migration development plan to move them off of an old Access backed system.

5. A white boarding discussion about the company’s current technical issues with scalability, automation, fault tolerance and suggestions about how I would tackle them.

I did have to do a whiteboard coding exercise that consisted of writing a merge sort. I did it, they made an offer but after seeing the interview process, I knew that was a company I would never work for at the position they were interviewing for. They did make me an offer though.

You have to know _a lot_. Programming languages, Tools, Operating Systems, Tests etc. On top of that, specific domain knowledge is required. Unfortunately, my brain forgets and if I work with different technologies, after 1 year I will not start at 0 but definitely neither at 100%.

I consider myself a full stack developer/architect from the web down to (cloud hosted) net ops/Dev ops/development. I can go in with no infrastructure and design a pretty good system at each level. Yes if I am not constantly working on a part of the stack - especially the front end - I do have ramp up time to get at a high level of efficiency. But people do it all of the time.

This is no different than any other high paying profession. You’re expected to know a lot about your field or at least be able to ramp up fast.

After all it's "just" software. Besides yourself, nobody really cares how you solved the problem. Sure, it's quite appealing to think through a complex system, tune it, develop it etc. but often it includes cumbersome work and decisions are made elsewhere.

Most software development involves maintenance of other people’s code. People very much care about how you implement something.

As far as being able to make your own decisions, the secret is working for a small company. But only do that after you gain some real world experience and can learn from others.

French companies pay freelancers not only more than employees, but they are way more annoying with the later. They just give you a better status for some unfair social reasons.

American companies will generally have more interesting projects and higher budgets. They will pay you more than a French company, while it will still feel that it's cheaper for them.

As a freelancer you can still pay for taxes, social security, etc. and yet double what you would had made. Plus you get flexible hours and you can work from home.

The downside is that you can't suck, be lazy, or sick for too long. You have basically no safety net.

The Uk has been known for ages as a place to get well trained engineers on the cheap.