Posted
by
timothyon Tuesday May 13, 2014 @10:59AM
from the anything-you-can-yourself-into dept.

First time accepted submitter Wisecat (3651085) writes "So we all know that computer programming jobs are hot right now. Heck, even President Obama has been urging Americans to learn the skill. But all of us in tech know that not everyone can hack it, and what's more it takes a while to learn anything, and keep up your skills as technology changes. Add to that the fact that companies (and their hiring managers) are always looking for 'the best of the best of the best' talent, and one starts to wonder: just how good does one actually have to BE to get hired? Certainly, there must be plenty of jobs where a level 7/10 programmer would be plenty good enough, and even some that a level 5/10 would be enough. And perhaps we can agree that a level 2/10 would not likely get hired anywhere. So the question is: given that we have such huge demand for programmers, can a level 5, 6, or 7 ever get past the hiring manager? Or is he doomed to sit on the sidelines while the position goes unfilled, or goes to someone willing to lie about their skill level, or perhaps to an H1-B who will work cheaper (but not necessarily better)? I'm a hardware engineer with embedded software experience, and have considered jumping over to pure software (since there are so many jobs, so much demand) but at age 40, and needing to pick a language and get good at it, I wonder whether it would even be possible to get a job (with my previous work experience not being directly related). Thoughts?"

Sysadmin scripting? Build tools control? Data modeling? UI development? Maintenance and enhancement on a ERP or SCM system? So it depends on what you are targeting and the demand. No one wants to support COBOL. Everyone wants to do mobile apps. So how do you differentiate in each of those areas? A 2/10 in one area may be considered a 7/10 in another area. That would be the better question. Please resubmit your question with a better statement of goals. Then we may be able to help you.

a 10% skilled programmer can be identified with simple interview questions. A 20% programmer can be identified with a little more effort. Beyond that? Really hard to differentiate in an interview. You can measure how good they are at language trivia. You can measure there ability to solve easy problems quickly. You can identify basic levels of sanity and social competence. But programming ability? You'll figure it out after they've been working for you over 6 months. So no, you don't have to worry about being a master programmer to get a job, you just need to be a 40% programmer and know how to interview.

I fancy myself a "knows a LOT of languages and knows how to adapt". So I can sit down in front of a machine running a completely in-house language, and be proficient in it in less than a day, very skilled in under a week. I think this is more important than already being proficient with any given language. Having a very broad background of languages is very useful, because there comes a point where a new language won't really have any surprises you're not used to managing.

Things change so fast with computers, how fast you can adapt is usually more useful than how much you already know. Experience goes stale so quickly, only adaptation remains valuable any distance out into the future.

So this makes it a little tricky to judge "programming competence". If you simply sit them down and see how well they can code in what you use right now, you're not necessarily getting a good measurement on how "competent" they'll be at it in a week. I'd say "throw something at them you know they have ZERO experience with, and see how they react". A competent programmer should be able to have 80%+ comprehension on any code you set in front of them. They should also be capable of very simple edits, and maybe even a little debugging. Have an experienced dev sit down beside them and then give them a simple challenge, with the dev as their assistant. The questions they ask the dev will tell you a lot about their level of competence. Get the dev's input on this later too.

First of all, let me be the one to say that getting past the HR department is independent of skill. Simply because they usually know LESS about programming than you. I don't know how much you know, but I can say with some credibility that if you ever had to do anything with computers other than turning it on, your chances are high that you're a computer wizard compared to anything that could sit in HR.

That aside, you do have some valuable experience and I'd build on that: You worked on embedded hardware. Yes, I'm dead serious, build on THAT. We're getting more and more "smart appliances", the next big thing in IT will probably be how to manipulate all the appliances in your home with your smartphone or your tablet. Let's face it, we've pimped TVs and got people to buy a new one every other year, at least. But their fridges, microwaves, washers and dryers sit there for years and years without being replaced. A marketing nightmare. The next big thing must logically be to get people to throw those out every other year to buy something better, and "better" in this case can only mean that you can somehow network them. My suggestion would be to get on that train.

If you don't want to be the guy designing and developing the hardware/firmware for the appliances, there will most certainly be a spot for a software developer for mobile devices who knows the "other side", read, the hardware in the appliance, and how to string them together sensibly. If you have any kind of experience with WPAN in any of its forms, I'd say you're going to be very popular.

In my experience, there's no such thing as a 5/10 programmer. If a person has good fundamentals (decent math and analytical thinking), the right attitude, and the desire to learn and improve, then while he might find himself at the 5 mark temporarily, he will eventually get to the high mark. Without the right attitude, he'll be stuck at 2 and generally do more damage than good.

I lived in California after the dot-com crash, and the field was tough-going for a few years. I had to take some out-of-state contracts with sleazy agencies to pay the bills. Fortunately I had some "legacy" knowledge to fall back on compared to the web-only developers, who had to compete directly with other webbies recently dumped from the failed dot-coms.

Remember, ups-and-downs are likely and the field changes fast. Being good enough to work in the field during the boom years may not be good enough for the bust years, and you could wind up with the wrong skills at the wrong time.

In my opinion, for a longer view, pick a field you are good at rather than one that appears strong now.

And people skills are always good to have and/or hone because that reduces the chance you'll be off-shored or automated out of the job.

Lots of people in their 40s and 50s and 60s have mediocre jobs writing 200 lines of code per quarter in some large corporation.

But maybe it's a damn good 200 lines:-)

Note that measuring productivity by lines-of-code has a lot of caveats. I've seen bad, repetitious code that could have been reduced to 1/5 its size if the repetitious parts were simply put in functions with optional key-word parameters. The programmer didn't "get" key-word parameters.

Even when you get good programmers, projects are often managed to push as many amps through a developer as possible. When that happens to a team, more difficult things do get accomplished, but the code often still looks like it was written by an amateur. Bad code ends up being like credit card charges that never get paid off, while the owed amount continues to climb until bankruptcy occurs. This is because the bad code wastes a percentage of everybody's time every day, and the mess compounds as everybody works around it. So, it is often better to just not hire a developer that isn't "the one" (who is often worth about 10 normal people).
We used to do interviews including the entire office, and generally require unanimous approval. Maybe 50 to 100 people between phone screens and actual interviews were done to get one person. I think there is an oversupply of people trying to specialize in programming; and most people should be learning programming as a supplemental skill to a specific business.

HTML 5 is a specific version of a markup language. iOS is an operating system. CSS 3 is a declarative styling language. And jQuery is a framework that works within a programming language (specifically, JavaScript).

Furthermore, people who use (a.k.a. "know") these things aren't necessarily programmers. Programmers write instructions for computers to follow. Writing markup, styling, or layout instructions are not programming, since the "rendering engine" is using that markup to do the actual layout and styling of what is displayed. Using an operating system is not programming for exactly the same reason. There is a program already capable of doing what you want, and you're giving it commands that it translates into computations and actions.

I'll concede that you can call yourself a programmer if you use jQuery, since you can't really use jQuery in any other context other than programming. Easy-mode programming that shouldn't pay much, but still programming. (As you said, it's "trivial".)

Self-taught developers do need to pick up enough math to stop writing code that dies under its first realistic load (complexity theory). You can't write a good compiler without being able to learn the math. Computer graphics and Statistical programming require absurd amounts of math to do well (to be the 10x developer).
I agree that the academic background isn't necessarily useful, and we see good people who went from high school to military to industry.
Computer Science as it now stands has serious rigor problems. Which is why it is undergoing a serious security crisis, and the only light at the tunnel is languages that will reject logically inconsistent input that wont follow a specification. That means that at some point, programming is going to look a bit more like Haskell, and require some ability to write code that meets it's spec the first time; rather than quickly building something that undergoes haphazard maintenance for years on end.

i am paranoid about that as i'm 43, but honestly i haven't seen it play out. I've consistently been able to find work. I have recruiters banging on my door day and night. i've turned down offers from those big imposing software giants. maybe i'm just lucky because my core competencies are in use all over the place. maybe i'm lucky because i'm a young and hip 43 riding around on my skateboard with my full head of hair and getting mistaken for a 20 something. However, i strongly suspect that i just happen to be able to pass a technical interview and that's really all that most places care about.

Oh, also, i'm not really interviewing at those startups run by actual 20 somethings.(If i really needed that job, you can bet i'd ride my skateboard to the interview)

Lines of code per day also depends very strongly on what stage of completion the project is at. If you've just started on a new module and are painting with broad strokes you might write hundreds of lines of code in a day. If you're filling in fine details or fixing bugs, you might write one line of code (or negative lines of code!).