Slashdot Mirror
Ask Slashdot: Will Older Programmers Always Have a Harder Time Getting a Job?
Theseuss writes "Given the strong youth culture associated with the modern day Silicon Valley startup scene, many times it falls to the 40-year-old programmer to prove that he can still use the newest up-and-coming technology. Yet the rate at which the tech sector is growing suggests that in 20 years there will be a an order of magnitude more 'old-hat' programmers in the industry. As such, do you think the cultural bias towards young programmers will change in the near future?"
Ignore Silicon Valley.
50 years ago it used to be a hot-bed of science and technological innovation. Now it is a magnet for designer coffee-swigging social cloud blog web 2.0 get rich quick smartphone app hipsters.
Look for real companies designing and building real products for proper customers. Silicon Valley's day is gone.
Stick Men
They're the ones that will. Find a job at those.
False premise. Assumes a bias without providing evidence.
I personally believe that the experience older programmers provide over younger counterparts makes them a desirable hiring option. The catch is that the price has to be right. Some of the older developers demand two to three times the salary of younger programmers. When you do that, you have to ask yourself if you deliver quantity and/or quality two to three times greater than those younger programmers. If you honestly believe you do, then your next task is to prove that to prospective employers, but it's going to be a tough sell. It can take close to a year for someone to realize that they hired a fraud, so you're a more expensive gamble to that employer than a younger employee.
There are certainly older programmers who can produce much better software at faster rates than their younger counterparts, but it is difficult to prove and requires the employer to take a greater risk in hiring you.
Finally, is it me or was there no article at all? Seriously, Slashdot - WTF?
Its more about their attitude. There are some solid patterns and just software development knowledge that is great to have and haven't really changed regardless of the technology. I hired a guy at the end of his career (programming for 30 years, he worked with punch cards in college) he said he just wanted to program, he picked up everything easily, contributed to design and implementation with some JPA 2.0 db interfaces from an AngularJS front end. Unit testing, in memory databases and all sorts of stuff.
I have found that age doesn't matter, if you are going to be a stick in the mud and in my day type of person, I will never hire or want to work with you.
Some technology and syntax change...good designs and ability to learn and adapt don't.
I can say the difference between now and the last time I had to do this (~12 years) is stark.
Seriously...if I have to take another test checking my ability to O(N) a problem, I'm gonna scream. I've been living in ginormous game engines for 6 years, and the amount of times I've had to, in the span of a timed half an hour, optimize a routine to make sure it was running in the optimal time has been....zero.
I'm sure it comes up, and I'm sure it's useful, but this all reminds me of the older assembly guys who used to put in all kinds of wonky tricks that eventually got optimized out by the compiler. Bubblesort has been solved. If your company has to implement it again, you're doing it wrong. There's a routine lying around somewhere in the company. Really.
I don't know what the solution is for evaluating tech talent, but this doesn't seem like it.
Also, web guys...if you're really concerned about speed, maybe you should consider writing some of this code in a lower level language. Plus, if your ad server takes 5-10 seconds to respond, then all of your optimization is for nothing anyway. But hey, you got the O(log N) solution. Bully for you.
As opposed to what? A manager?
Fuck that noise.
Yes, older programmers will always have a harder time getting a job, just like older people in all other professions. Age discrimination isn't just an computer industry problem.
The other advantage 20-year-olds have is they can give their life to the company. They don't care about having to work 60-hour weeks as long as there is foosball and free pizza. Why go home when 'work' is cool?
A 40 year old often has a spouse, kid or two and a dog they might like to take for a walk. They don't care about BS phrases like "Work hard play hard!"
if you love what you do at what age should you stop doing it and switch to something you loath?
Boy I remember the old days of writing web CGI apps in C, way back in the 1990s. People would look at me like I was insane if I were to suggest writing web apps in a language that compiles to machine code. There seems to be a whole industry dedicated to declaring native apps an evil that must be extinguished.
The world's burning. Moped Jesus spotted on I50. Details at 11.
There are certainly older programmers who can produce much better software at faster rates than their younger counterparts, but it is difficult to prove and requires the employer to take a greater risk in hiring you.
It isn't difficult at all. At my company, an "older programmer" solved a bug in code written by a younger fella by introducing a function that we all never knew about. This fella refactored code, cleaned up the mess we had in our AIX/DB2 system and saved my company lots of cash by single handedly writing code that verified that our data migration to PostgreSQL from the mentioned DB2 system was worthwhile.
Specifically, he wrote code that printed cheques the way we wanted (Numbers to words), in about 1/4 of the lines of code we had. All this by employing functions we never knew existed. Nothing can beat knowledge/experience. Nothing!
What is the newest up-and-coming technology that programmers have to deal with?
All the new technology is just an API library.
Programming languages have remained the same for the last 20 years.
A blanket statement, and a stupid one at that.
I just turned 50, and I work as a web developer at a university. Developing software is my ideal job, one that I will be very happy to do for the rest of my life, let alone until I'm old enough to retire. Hell, I do it for fun in my spare time as well.
Where do you think people should go? Management? No thank you. I have no interest in attending meetings and shuffling papers (and no matter what anyone might say, a lot of management is just that), and I know that I wouldn't be good at it.
Maybe by code monkey you are referring to people who take a spec and implement it in code. I agree that that's not a lofty ambition. I am involved in the entire project lifecycle. Still, there's a special delight in writing good code, and you should not dismiss those who are content to do just that.
a thousand times this. I'm close to 50. Over 30 years of SW development experience that is easily verifiable should I suddenly find myself looking for work 'the hard way'... My friends who are out looking for work tell me the latest fad that all the cool hiring managers are doing is giving you timed tests to make you prove you can write a "C" function to find the bottom of a linked list or some equally inane task... Maybe that's great when your hiring pool is a stack of resume's from fresh-out-of-schoolers but my CV alone should tell you that I've done the work. Then you and I can just sit down and have a grown-up conversation... If you want to see my code, there are lots of open source repositories I can point you to... But I'm not a circus performer. I can't tell you the last time I've had to stand up in a room full of people and write code on a whiteboard.
Not when 2038 approaches.
I eat only the real part of complex carbohydrates.
Agreed. If you hate programming so much that you are looking to climb out of it, you probably are going to be a terrible manager of programmers. If your goal is to become a manager because you love programming but want to ensure the projects are managed better, then that is a good reason to want to become a manger.
I found age discrimination 2008-2011 but not now. I expect it will return after the next stock market or dot-com 2.0 crash.
But I'm not in Silicon Valley.
I've been living in ginormous game engines for 6 years, and the amount of times I've had to, in the span of a timed half an hour, optimize a routine to make sure it was running in the optimal time has been....zero.
Do you happen to work for EA? That would explain a lot...
today is spelling optional day.
Yes, I moved over to management as well. Reason? Money. Simple as that.
As a programmer, you'll hit a glass ceiling sooner or later. But as soon as you have "manager" in your title (or, better, "chief" + $whatever + "officer"), you suddenly tack a 0 to your annual salary without actually doing more work...
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
Honestly, any programmer that is worth his or her salt is going to be employed no matter what their age. There are plenty of schools and non-profits looking for help. Of course they may not pay as much as the corporate office, but you'll be working. I also think you should start looking to strike out on your own as a contractor or freelancer soon after 45. I say this as a 52 year old who is exploring other options now. I'm writing some mobile apps for a local school district as part of my community service and I know from speaking with the administrator that I've got at least one way to earn should my company decide to push me out the door with my gold watch.
Not all other professions. There are some where age comes as a benefit. Legal and political circles come to mind, for example.
I like hiring new grads for some things, experienced folks for others. In this case I needed a Java guy for an app dating all the way back to 1999. I preferred somebody who had lived Java in those years.
It is true that lower level languages and compiler capabilities provide certain optimizations.
However, O(n) in most cases has nothing to do with high level/low level language. If you write something that has an exponential runtime then that is not something solved by a compiler optimizing it away nor a low level language. It is all about the algorithm/flow control used, not the language/compiler.
In line of business applications using database access frameworks, with many you have to be wary of this problem:
http://stackoverflow.com/questions/tagged/select-n-plus-1
This isn't exactly a O(n) optimization problem, but it is more easily understood and solved by someone who understands the concept of O(n). While true, reinventing something like quicksort is stupid, in many other cases there is no generic algorithm that solves the problem, but is more of a matter of just avoiding certain bad practices in the way you leverage the database framework.
If you want to solve the problem you describe, you will need to create an institution that provides an industry recognized accreditation and testing so that these kinds of things can be tested once, and then you can just provide those credentials to each potential employer and skip over those things. Good luck :)
As long as the quality of work continues to be an imponderable - not sure why this still is the case, unless management continues to remain clueless - decisions will be made only based on how much money someone costs, and older people want more money. Perhaps they imagine that experience is valuable.
Sure, I used it. It totally has its uses. But I'm not being old fart about it. I actually love working in Python for many, many things. It just seems totally bizarre to me to be trying to cycle optimize what is ostensibly an interpreted language. It's kinda like hypermiling SUV hybrids.
But you're right, there's some fear of every writing compiled code these days. Heaven forbid you even directly interface with hardware, either.
As a 30 year old engineer architecting and developing 3d graphics engines, I also find these kinds of interview questions worthless and stupid.
both unlink health care costs that are higher for older people and there needs to be more forced OT pay as the older people really don't want to work 60-80+ hour weeks even more so if they don't pay OT.
As others have observed, older workers tend to want to be compensated for their experience... so they're more expensive.
In a rational hiring world, that might not matter much--they usually deliver greater value, too--but it's often not rational people (or, let's be polite and say, people who could be better-informed) that are making that decision--it's people who want to minimize costs no matter what.
Hire an expensive engineer who really understands the work? Or two young cheap ones who might not? The latter, of course--for the same reason that outsourcing to the third world is so popular despite the incredible hurdles of management and quality. And if the bet fails, and neither of the young'ns can get it done (despite the 80-hour weeks that they can deliver and have come to expect), well, you'll be off to another job by then anyway and no one will know.
It's a vicious cycle: VCs like start-ups that live on ramen noodles because they're cheap to fund, unlike ones that have a real staff and a real track record. And sure, some of those cheap ones will succeed, and they'll get the press (in no small part because they are young), and that will perpetuate the myth that only young folks can innovate, leading the VCs to believe in their own decisions.
I don't see the bias going away. As a general rule, young people are less expensive, more dedicated, more attractive, and just more fun than us old farts. The market want crap in a hurry, and this is one of the primary reasons they get it.
You might be able to surmise from my username that I could be about 3 years from retirement (as if I would -- I love what I'm doing)
I've always stayed current and learn something new every day. I have found it definitely does depend on the culture of the company you are dealing with but also on the nature of the work. For freelance work, just about everyone I deal with seems quite happy to depend on "the old guy" to get it done, especially if they would consider the project a grind. They know they will get a good result and I can tell it just feels like a safe bet to them.
It happens sometimes that after a few freelance projects a company will want to talk about hiring me full time. On the East/West coast is where I have encountered the "I'm young and smart so you must be old and dumb" attitude. I sure don't take it personally. And in the Midwest decades of experience still counts for plenty and they will wine & dine you to get you go full time.
I didn't mean to indicate that lower level programming = the way to go. My point was that most of these tests miss the forest for the trees.
Sure, you're munging data. But either a) your dataset is known and your company has mostly solved this problem, or b) you're engineering new solutions which don't fit the way before.
You profile, find the parts that need optimizing, and optimize. That should be done regardless of the situation. In addition, the new "fuck it, ship it" mantra that seems to be all the rage would say get something working, then you make it work well. Not "you'd better do it exactly right the first time or it's worthless."
Data requirements shift. Focus of target moves. These all have to be addressed. A good programmer will plan for the changes as best can be so that if a new algorithm has to be used sometime, it can be swapped out as quickly and as painlessly as possible. Therein lies the experience. Not on whether you hit on the local maxima first try.
But I've noticed that the ability of bad ones to get hired tends to fluctuate with the boom-and-bust cycle. Are you a bad one?
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
It's not a question of age. It's a question of whether you're willing to work 50-60 hours a week, often without being paid overtime. Cut your rates, and you have no problem finding work.
All you have to do is settle for half of what you're really worth.
You're not only competing with the youth, you're competing with the overseas sweat shops.
The only way to maintain an income comensurate with your experience is to specialize in tools and technologies few others know. And as more and more people enter the computing industry, that becomes harder and harder to do.
I do not fail; I succeed at finding out what does not work.
No.
But the games biz has a ton of legacy engines all over the place. And most of the work on them isn't getting it to run more efficiently. It's adding features; it's testing user input; it's gathering data; it's keeping things from blowing up. And these problems aren't unique to the game industry.
There is plenty of work to go around adding features and improving/bug fixing that don't involve simply finding algorithmic solutions.
It's always been a peeve of mine that programming courses have been, for my experience, devoid of two real world aspects: error handling and user interface. Neither of those has a tinker's cuss to do with O(n) solutions, and if you look at many, many of the problems companies are facing, it has to do with those. Experience seems to be the teacher of those, as universities seem to have fallen short of any semblance of lessons in those areas.
It's one thing to do an exercise with a single command line function that has a clearly delineated in/out and a simple dataset. It's another when you're interfacing with legacy code, trying to fish a line thru to a class that doesn't want to expose it's members for some undocumented reason. Plus, the program has a real tendency to assume data validity, and changes makes crap blow up real good. That's real world company stuff, not whether or not quicksort or bubblesort is the best choice.
"Age and treachery will always overcome youth and skill"
New programmers may have skills with new software, but they may not have skills and experience with organizational politics, system design, product architecture, code reviews, QA, all the rest of what makes great programmers great.
But my point above about interview questions is that the bias is built in. The interview process, involving pointless tests and white board coding, seems geared towards the recent graduate. It's inherently biased against the experienced coder, because most of that academic stuff is long in the past by the time they interview.
I can't speak to whether or not it's intentional, but it's there, and it's very different than other industries.
What alternatives are there, except to be a manager which is an extremely undesirable job for many? Although "code monkey" has different meanings. I like being a programmer but I don't just want to be a grunt coder. I would consider that designing a new system is still a programming job, and I'd hate to ever design something from a desk and be completely hands off while all the actual building is relegated to the new hires.
Seriously...if I have to take another test checking my ability to O(N) a problem, I'm gonna scream. I've been living in ginormous game engines for 6 years, and the amount of times I've had to, in the span of a timed half an hour, optimize a routine to make sure it was running in the optimal time has been....zero.
I'm a firm believer in those sorts of interview questions... and they have nothing to do with O(N). They're just a convenient way to see how the candidate responds when given an underspecified, mildly-complex problem to think their way through -- but a problem that can fit within the time constraints of an interview. It's definitely not ideal, but I think it provides a lot more insight into the candidate's problem solving skills, mental agility and the attitude with which they approach problems than anything else short of a two-month trial employment, which neither side can afford.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
In the 7985 years they'll start upgrading everything to have 5 digit years, so they'll be looking for people experienced with legacy software.
I recently took a multiple-choice C# quiz for a hiring interview. I didn't like it at all. I think that a test or quiz should give you the opportunity to demonstrate skill and knowledge. The test I took seemed to be designed to trick me with corner cases.
For example, there was a question that demanded that I know what happens if a variable in a using clause is set to null inside the using block. Why on Earth would I ever want to set the variable in a using clause to null!!! That makes no sense.
Wh47 d1d j00 541, 31337 15n't t3h r0xor5 ne m0r3???
As someone who gives CS interview problems, I have to disagree with your assessment. The problems aren't designed to prove that you can implement a bubble sort. It's meant to be representative of the sort of typical hard problem you'll be faced with writing software. The reason why we choose CS problems is because they are properly bounded, they have a finite number of correct answers, and if you get off course while working them out on the board, we can better help you to get back on course. Furthermore, there are decades of research that have gone into these problems, so a naive board implementation leads to all sorts of prompts for interesting questions.
Most of my evaluation has nothing to do with whether you get the right answer or the wrong answer. It has to do with how you arrive at the answer, and how you respond to constructive criticism, or in a pair programming environment. I couldn't care less if you can write a bubble sort coming in; if you solve the problem quickly, I'll just substitute a different one that you can't solve quickly. It's the process by which you arrive at an answer that interests me, and CS problems are, by far, the easiest way to uncover this.
Yes, they're still in Silicon Valley, but are invisible to the news media and marketing people. Cisco is here for example, big, huge, thousands of jobs, and nothing whatsoever to do with startup culture or web apps. Then there's Intel, Varian, Broadcom, VMWare, Oracle, Hewlett-Packard/Agilent, Genentech, Apple (there are a lot of older people at Apple, it is not a day care center like Facebook).
We have one guy that understands build processes. I have done any serious code in years, but some of the crappy code I've seen is pretty horrid.
Here's an example:
Just over a year ago we had some Java developers doing some web code. This was on a Linux/pSeries hardware. I.e., it's a Power chip, not Intel/AMD. I was asked to install the JVM software by the developers. They gave me an Intel binary. OK, no prob. I asked them to send me the Power installation package. They responded that it was Java and the underlying hardware didn't matter. Oh really? One of the developers actually got pissy and started trying to explain that he ran it on his Windows machine and another guy ran it on his Mac. Tried again to explain the difference between the jvm executable and the jar but then I realized that if he didn't understand that, it wouldn't be much point.
The guy we brought in knows that. Lots of other things too.
But I've been on 3 interviews so far where showing your work merited a "sorry, that's not fast enough" with nary a discussion on thought process, coding style, etc. I even explained my thinking with the dataset and worst cases.
It'd be one thing if it was used as a way to glean a thought process, but when the bottom line is merely O(n) vs. O(log n), you're not looking for candidates who can find a way through a problem. You're using specific knowledge as a sieve. And that's where the age bias comes in. The experienced programmer knows that the answer is rarely X or Y, it...depends. And sometimes that "depends" and the design around it is the key to scaling later or blowing your leg off. I'm not saying every experience programmer knows it, but the young ones rarely do. But they're sure up on their mergesort implementation.
I've yet to have someone give the version of that test where the hard coded array or hash is the solution, because that's what you get to from experience: knowing when to be fancy and when to be specific. The academic solution seems to be built in from the start. And that favors the recent grad, period.
No, managers do tons more work. Generally they spend all day being managers, then the rest of the evening until midnight being programmers to get stuff done. And it's not tacking another zero onto the salary, I don't think we have bottom line managers making a million dollars a year for doing little work, you have to get to the executive level for that.
I agree. I've become a little dependant on an internet connection to look stuff up to jog my memory and trying to do this stuff in an interview is stupid. Most of the time I'm taking a 50/50 guess over if the best answer is simple or not, but either way I don't write code perfectly the first time, nor do I jump into a solution without spending ample time to think about it. I also do research to double check my understanding and knowledge. Bottom line is that the interview process is a poor way to select candidates.
And I'm 29. You're not alone. Too many job interviews waste our time by introducing too many points of failure. I hate doing phone interviews then coming in for an on site and I get the dick who didn't read my resume and just presumes I already know everything they envision is used for the job. I suppose it just proves that it wasn't the job for me but it's frustrating when you realize you have to wait longer for the next job to come along.
Join the Maker community. Make your own software. Screw the companies. They want young people because they work for less
No, it doesn't depend on management, it depends on ownership.
The instructions to management are now, "Get the youngest, cheapest, most scared". The last thing they want is someone experience enough to know when they're getting fucked.
You are welcome on my lawn.
I have yet to see it. It's used far more as a quantitative judge of someone's ability, when it's barely a sliver of what happens in coding. Heck, I spend most of my time handling exceptions, checking corner cases, and refactoring classes to make sure someone else can use the code someday.
To me, the way to go is to have some sample code, whether it be some previously written or requested by the company. Then, that code is brought in and the team can do a defacto code review in person or online. It's much more representative of a real world situation, and code reviews are much more about discussing methods than simply judging the efficiency of an algorithm implementation.
List of skills that are completely ignored by the academic quiz method: error handling; class design, including planning on later improvements/changes; code documentation; ability to read other people's code; refactoring skills; test automation
All of these are huge towards working in a company, and I have yet to run into an interview process that even addresses any of those. It's all about the simple CS test.
My boss can hire two fresh-outs for what he pays me. He knows this. A short sighted person might think two fresh-outs are more effective than me. My boss knows better. I regularly deliver way more than two fresh-outs, and I show up on time every day, not hung over. No drama.
Not every boss is like mine. Many think that more cheap labor can get the job done. Good luck with that. You get what you pay for.
there are 3 kinds of people:
* those who can count
* those who can't
There's a job, if you're a COBOL programmer. In the last few months, I've had friends and relatives wishing they were proficient in COBOL or their company needed someone proficient in COBOL. I hear it pays $100K+.
Here's the problem though. I have interviewed a lot of people with good looking resumes who completely fell apart when asked to do simple coding on the board. Simple stuff like how to clear a bit in a word when their resume indicates lots of experience working with hardware. Similarly, if their resume says C and we're hiring a C programmer, they should be able to some simple C code without headscratching. I don't even ask the harder questions I used to ask because I'm almost positive they won't be able to answer. I can't even ask CS style questions because so many come from other backgrounds. I've honestly had people try to explain that they've been working with "middleware" and that their device drivers really were just ways to a higher level application to a lower level library which is why they really didn't know how it all worked. So I ask the programming questions to make sure they really can do the job without asking for help every ten minutes. It's only later in the code reviews that I think "OMG why is this sorting a list inside an interrupt!"
Fresh out of the job market (and into a job) almost none of the interview questions had anything to do with what was in my resume. They should be seeing if I'm a liar but instead they want to know what I do in my free time or ask me new grad questions for which nothing similar has ever came up in my career...
And see how I think? I think differently than you do and solve problems my own way. Does that make me unqualified?
Also, web guys...if you're really concerned about speed, maybe you should consider writing some of this code in a lower level language.
Game guy. Please stick to giving advice about game engines. You don't know anything about the web if your suggestion to improve performance is to "write in a lower level language". Your advice is akin to me saying "Hey game guy, if you want faster games, why don't you get a faster internet connection!"
Everything else I agree with.
AccountKiller
Not true. Those resumes are often lies. I see a great resume that says someone can do the work. And yet they can't wrote up a very simple function on the board, the sort of thing they'd have to do every day on the job. Maybe searching for something in a list is inane, but you'd be surprised how many people with years of C experience on the resume can't actually do it. I feel stupid just asking some of these questions in an interview because they're so basic, but so many people just can't do the basic stuff. Now granted, maybe the recruiters are scraping the sides of the barrel to get these candidates (my theory is that with the current economy that the best engineers are staying put instead of changing jobs).
Ie, Joel on Software mentions some of this, saying that he expects that for the simple questions he would like to see the programers just start writing out the code without pause. And yet I have seen people pause because they can't remember whether to use '~' versus '!' and the like despite a resume that says they should know this completely. I have a really simple question which can be done with a one-line answer that 9 out of 10 candidates can't do.
And besides the programming examples aren't just for checking if someone knows the syntax. We also want to see how the candidate can think about a problem. I try to ask something that they would not know if they just crammed the night before so that it requires them to think. That's important to do on the job: thinking is an important part of the job, whereas bullshitting about what's on the resume is really only useful in the lunchroom. Can the candidate think logically about the problem, or are they flailing about?
Believe me, someone can spend 30 years in the industry and still be clueless. Quite a lot of programming jobs are very basic; in fact right now I think that most programming jobs require minimal thinking, they instead either require mostly gluing together different frameworks, or else making minor tweaks to a large existing body of code.
Just a few years ago there were endless stories about the 50 year old programmers, and now its starting up with the 40 year old programmers, soon it will be the 30's then the 20's then we wont have to worry about some douche that never kept up to date wondering where his next pascal for the next cube job will come from
Where I work, we have several divisions.
One division trains firefighters and EMS. We have an incredible training facility, so not only do we teach Firefighter I, we also train veteran firefighters on extra-hazardous stuff like oil refinery fires. They also teach search and rescue in our rubble piles and collapsing buildings.
Another division trains cops, tactical drivers, etc. That division includes an on-staff sniper.
A third trains people to work on high voltage electric lines.
Then there is my division, "administration". We're the IT people, bookkeepers, etc who keep the agency running. Guess which division had the worst safety record last year. Yep, us nerds. For my employer, the people clicking a mouse had more injuries than the people putting out big fires, crawling under collapsed structures, or performing dynamic entries (seat raids).
Yes, we nerds are suitably embarrased by this fact.
Actually, if the CS board problem is done correctly, then error handling, software design, and planning can be measured. There are plenty of corner cases in most of these problems. That's where the real fun begins. Even something as simple as adding and removing items in a linked list or a binary tree leads to corner cases.
Everything else comes down to Q&A. That's where we get into probing questions about design, documentation, etc.
As for code samples, I'm not a big fan of code samples. You won't believe how many times I've seen people plagiarize source code in interviews. The only exception here is the take-home test. The only problem is that take-home problems have to be rotated out pretty quickly. They hit the forums within a week.
Not all companies have that glass ceiling, actually. The really big tech companies often have extremely senior non-management technical roles (common titles are things like "distinguished engineer" and "technical fellow" and the like, sometimes with "senior" variants thereof). In terms of pay scale and location in the org chart, these folks are usually somewhere between the upper end of middle management and VPs. They will frequently work in areas where they *influence* large teams of people - for example, they may be architects, or have an advisory position to an entire product team - but the work they do is largely at their own discretion and nobody reports to them. I know a guy who worked for Microsoft's Windows team in such a role; when I asked what area he worked on his response was, quote, "whatever I want to". Somebody who can solve the sticky problems, who can do the things the less-experienced don't even know is possible and get it to work within the time they expected it to take, are very valuable. Sometimes that's even solving problems that other engineers didn't realize *were* problems, like scalability issues that had never yet shown up in testing because the thing wasn't ready to test at scale yet.
Now, it's not necessarily easier to get those positions than it is to get a management position and continue moving up the ladder that way. However, down that path lies the loss of any time to do the stuff that's actually fun in software development: the coding a tool or feature and seeing it work, the (FINALLY!) fixing that damn bug, the refactoring some method to run in n*log(n) time instead of n^2, etc. Managers, especially once they have other managers reporting to them, don't have time for that stuff. If they're doing technical stuff at all, it's probably mentoring their newer employees and maybe doing some code reviews. More likely, they're spending their time in planning meetings and status meetings, 1-on-1 meetings with their underlings, meeting with managers from other teams to handle disputes, and so on.
If I ever went back into development (I do security consulting now; it's a different kind of fun but it's great work and I still get to cut code on a regular basis), I'd do it somewhere that has a real senior engineering career path.
There's no place I could be, since I've found Serenity...
that depends if management wants to waste time and money reworking mistakes that would have been avoided by someone with experience.
Today, the digital world is young and new
The managers are young, the employees are young, the customers are young
Once upon a time, the railroad was the hot new tech, then radio was, then tv..etc
Someday, software will be as mature, professional and boring as ball-bearing engineering
I suspect that ball-bearing engineers suffer no age discrimination
BTW..I am a 60 year old programmer who is turning away work. I work in the totally non-sexy world of embedded systems and industrial equipment
I see a lot of people where the resume talks about what "the team" did, and on the interview the discussion is about what the product did. And that can get the candidate past a lot of filters if the interviewer naively assumes that everyone always pulls their own weight in a group.
... in fact, as I get older, obviously more people have worked with me. So my "network" (yeah, hate that word, but oh well) is bigger.
My current job happened when someone who used to manage me called me up and said they needed someone good, right now, would I be interested? She already knew me, so that was the interview.
Now, would I have a hard time just walking in off the street, playing buzzword bingo? No idea, and hope I don't have to find out ...
Health insurance alone is one good reason to hire all young workers. Any company that hires older employees or fails to fire them before they age may suffer serious insurance premium penalties. Then there are issues like time lost due to illness, doctor appointments etc.. Older employees may also have been exposed to some rotten employers and feel that dragging along is their right. A bright new star trying to shine bright is what employers want.
But it's not the *only* thing, and yeah, that's doable with some profiling. In that case, it's already screwed, and you're going in to optimize. That doesn't involved walking in in 2 seconds and seeing the solution. While companies want that, there's usually a reason the code got that crufty. The young bucks are the ones who walk in smashing everything in sight, assuming everyone is dumb but them, and when they remove the wrong strut and the whole room comes collapsing around them, that's when you wish you had someone with a bit of experience.
But explain how having an introvert stand at a white board and work on an algorithm in a vacuum is anywhere close to coding an optimal algorithm. We're not robbing banks here, we're writing code. We have a few minutes to check what has been done and why.
and you can't tell from talking talking to the person about the code they wrote that they didn't write it, something is seriously wrong. I know there are BS folks out there, but if you ask the right questions, you can tell what they wrote and what they cribbed.
You don't know anything about the web if your suggestion to improve performance is to "write in a lower level language".
We built all of our web page content using JavaScript. High level, low level, who cares? It runs on the client machine, so if users complain about speed, blame it on their system or choice of browser.
Have gnu, will travel.
Ok, so let me see...you rely on an interpreted language to do your reads and writes to your database. Why not use C/C++ and interface with it thru your engine for the most used algorithms? Python has an excellent method to access C routines, and much of the access routines are written there anyway. I haven't worked much in Ruby, but I'm guessing there's a way as well. It's the same damn thing with games, or any speed critical system. The access speed has nothing to do with the processing of the data, and optimization is about more than just the algorithm. If the underlying disk/db read takes 10x longer because you're using some wrapper, then why not look at that? Or is it too hard? Your server side code doesn't need to be cross platform anyway...
I can say the difference between now and the last time I had to do this (~12 years) is stark.
Seriously...if I have to take another test checking my ability to O(N) a problem, I'm gonna scream. I've been living in ginormous game engines for 6 years, and the amount of times I've had to, in the span of a timed half an hour, optimize a routine to make sure it was running in the optimal time has been....zero.
I'm sure it comes up, and I'm sure it's useful, but this all reminds me of the older assembly guys who used to put in all kinds of wonky tricks that eventually got optimized out by the compiler. Bubblesort has been solved. If your company has to implement it again, you're doing it wrong. There's a routine lying around somewhere in the company. Really.
I don't know what the solution is for evaluating tech talent, but this doesn't seem like it.
Also, web guys...if you're really concerned about speed, maybe you should consider writing some of this code in a lower level language. Plus, if your ad server takes 5-10 seconds to respond, then all of your optimization is for nothing anyway. But hey, you got the O(log N) solution. Bully for you.
Too many people looking for too few jobs. As a 50 something programmer I am now, shall we say, "semiretired". My last interview was a humiliating kick in the crotch. O(N)? Yeah, that and more. The kids need to wake up an (*gasp*, dare I say it?) unionize before they get "rightsized" out of the biz.
"If god did not exist, it would be necessary to invent him" --Voltaire
...along with older garbage collectors, older mechanics, older rickshaw drivers, older accountants, and older NFL quarterbacks.
When I was leaving a past job, I was involved with interviewing my replacement. I had built and supported a number of interconnected web pages and middleware largely using Perl (for internal company use, so scaling performance wasn't an issue). One of the people we brought in had been doing Perl programming for years, so we asked him to bring in an example of his work. It was a beautifully coded 'expect' type interface to command line ftp to transfer files between servers. Excellent coding style, comments, attention to detail, etc. And then I asked him, "Ever heard of CPAN? Do you know what the NET::Ftp module does?" Half a dozen lines to do what pages of his code did.
I'm not a CS by training. I'm an EE who 'fell into' web and client server apps from some embedded work. 90% of what it takes to get a job done is to know where to lay your hands on the appropriate resources. Nobody can jump into anything more than a trivial coding job with everything they need already in their head.
Oh, yeah. The whole O(N) crap: One of my duties was to support an automated code generator that took system requirements documents, did some natural language recognition, populated a knowledge base and used that to generate test code. It was originally written by a couple of flight controls engineers (MEs) and, in spite of all of our CS people jumping up and down, screaming "Can't be done. NP-hard!" it worked beautifully.
Have gnu, will travel.
'm writing some mobile apps for a local school district as part of my community service ..
Huh. That's new. So the judge ordered you to do how many hours of community service programming? And what did you do? Beat up some kids who wouldn't get off your lawn?
Next question please.
What old farts hear:
"You're not a good fit."
"You don't have the skills."
"The position has been closed or filled"
And one I actually got: "Your commute will be too long."
You see, people over 40 are a protected class in legal speak. What that means is if a company were stupid enough to say, "You're too old.", they just opened themselves up to an EEOC lawsuit.
Now, when I was volunteering as an IT guy at a free clinic, one of the guys there was a retired IT manager. And this is what he said, "When there's a choice between an older or younger candidate, the younger will be chosen. I'm not saying it's right, but it's the reality."
Working with retired IT/Development managers was a real eye opener. One actually said to leave IT.
I'm trying but starting over again is really hard because folks don't like hiring middle aged entry level people and they are quite incredulous that anyone would want to leave a lucrative career like software development.
It is VERY hard out there for folks who are unemployed. Just being unemployed is a black mark against you and the longer you're unemployed, the chances of getting employed again approach zero.
Freelance? Even worse.
I'm 34. I find it hard to get excited about the latest technology. Maybe that is my shortcoming maybe that is experience. Not being excited/dropping everything for the latest fad is a matter of knowing what is possible with existing technology and having been around for more than one cycle of: parallelism, single threaded performance, macro vs micro kernel etc etc. I'm not perfect but a lot of the attrition in tech can be attributed IMO to allowing HR to craft openings to use the latest acronyms rather than expecting experience/higher level thinking that they are fully unqualified to evaluate.
Cisco is here for example, big, huge, thousands of jobs, and nothing whatsoever to do with startup culture or web apps.
And nothing whatsoever to do with real products either. Zing!
I see the glass as full with a FoS of 2.
I work on one of the world's most influential computing platforms and I am 40. One of my most respected coworkers is 65 and nearly everyone has grown kids. Age has very little bearing on one's career and respect. I had a great job at 20 and I have a great job now. If you are not getting traction in a particular company or living area, do look around.
(And of course age by itself doesn't guarantee success over younger folks either)
I am a recruiter who recruits in the engineering spaces and in particular the Oil & Gas space in Australia.
So while not IT it probably crosses over in that we see a significant difference in attitude to years of experience between Australia and the US. For example a Senior Drilling Engineer with 20 years of experience can find it hard to get a job in the US. There seems to be a real preference for people with less experience ie younger.
In Australia the attitude is the opposite. Here the attitude is a 10 years of experience they haven't seen enough to know what not to do and that 20 is what you need to be useful.
Makes my life easier I guess, as we bring a load of skilled people over to Australia but the difference in attitude is interesting.
I went 11 years coming out of Carnegie Mellon without being able to score a serious software engineer position. Thankfully I make video games on my own to prove I have experience. I'm thinking of looking for a job if my latest game www.throneandcrown.com has failure to get popular. The fresh guy out of college is passed up because he has no experience. I was hoping I'd get a chance at finally getting my career started after I had a decade of experience I got on my own. I thought the decade of working on personal projects before that would help to get me a job coming out of Carnegie Mellon(which is supposed to be a good school for computers). But hey, not everyone gets a job, no matter how good they are at what they did. I'm not here to boast, but just to explain I'm competent, I've never ran into a bug in 22 years that I couldn't debug. My software runs fine and is complex (hundreds of thousands of lines of code). But will anyone even give me an interview for a junior position, nope. Things can't possibly get worse for me in terms of career as I get older because my career never started. I guess it sucks to graduate after the dot com bust.
God spoke to me
It might not be possible to ask the more direct question, "what does a using block do?", in a multiple-guess format without giving away the answer.
Attention zealots and haters: 00100 00100
I am getting close to 40 (geez, really?) and have had no problem. Could it be that the people complaining simply don't have the skills necessary to compete? I think that it is more that these 20-year-olds turned CTO/CIO/CEO simply have no clue what they're doing, and are hiring people that are style over substance. However, I could be wrong. After all, if you cannot use the newest up-and-coming technology, what do you have to offer, anyway?
Sounds like somebody got turned down by Facebook...
I work for a 28-person startup and we're pretty evenly distributed across the board.
Would have been funny if he answered, "Yeah, I wrote NET::Ftp".
Indeed. Unfortunately that results in bloated, insecure, unreliable and unmaintainable software as well, that very soon gets hugely more expensive than any real or perceived gain from hiring "cheap" developers.
For the current generation in 20 years, I have little hope though. They are mostly incompetent and paying more for them does not make the least bit of sense except for the few that are actually good at what they do.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
It's all related to the most profitable configuration for the company.
Most companies out there, especially the big ones, know pretty well what they are doing. Typically, a ratio of one as senior as possible resource for 20 juniors that don't have a clue. Shield this up with meticulously written contracts and a good team of lawyers and you end up making more profits than doing the right thing.
Everything I write is lies, read between the lines.
I'm 56, should I be forced to retire?
Programming is still something I do more or less 7 days a week because I like it, not to get rich or just because I'm paid to do so. When I started out this was pretty much the only way you could get into programming, i.e. my (technical) university didn't even offer an IT degree when I started there.
I've been programming since the seventies, I have written MBs of source code in many languages, but of course I'm getting about a year older every year. :-)
The main difference between today and 25-30 years ago is probably that now I'll spend a bit more time up front thinking about the problem _before_ I sit down to write the code. I've taken part in 3 of the 4 Facebook Hacker Cups that have been held so far and I've noticed that I get into trouble in the later rounds when time pressure becomes critical, but I like to think that I'm still coming up with good solutions even if it takes me more than 30-40 minutes to do so.
The international competitions that I've won have been for the fastest possible code but with some weeks to deliver the solution.
Terje
"almost all programming can be viewed as an exercise in caching"
I'm an older programmer (yes past 40, programming for about 30 years) and find no problems at all with finding work.
You'll bring more experience than the hipsters. Only issue with some companies is the higher rate/salary.
Ridiculous that once you're older you should be managing a group of 20-something programmers: do what you love, and if that's programming and not managing, stick with it.
I think that the chance you get hired depends on your own skills and attitude only. Most programmers stop keeping their skills up to date when they're forty. They shouldn't be surprised that that diminishes their chances to get hired. Attitude is important. You won't fit in if you missed out on Twitter or Instagram or whatever the kids in the team do. You won't fit in if you play golf and people you work with bring their skateboard to work. I'm sixty, I love snowboarding, I ride a super fast motorcycle, I have purple hair, I wear short skirts. I work freelance mostly (yes, that I'll give you, freelance works better) and I get plenty of jobs and projects offered. It helps that the market for Android developers is very good, but then, it was my deliberate choice to switch to Android programminig in 2008.
no, I don't have a sig
I've never been asked O(N) at interview. Maybe things work differently in the UK.
I'd sidestep the question anyway. Who gives a shit about the performance of that one algorithm, other factors will influence system speed and responsiveness far more.
In fact, if the primary reason you're recruiting is because you have one mission-critical algorithm that you need highly optimising and the rest of the architecture is solid, then you don't need me anyway. Hire a fresh computer science graduate on a contract for four months.
What makes you think management can recognize mistakes? They'll simply declare them features of whatever system they are hawking, or "known difficulties in our progress", or something. Management doesn't recognize mistakes unless they lead to their ouster, and then they draw the wrong lessons.
I like to have developers bring in some code they've written and go through it. It's amazing how many developers are just not good at interviewing... until we start looking at code. Oh, and the fakers, well, they seem to never bring code to the interview.
As far as tests go, we use them for people fresh out of school because there is a huge difference between passing a CS class and actually being able to apply that knowledge.
-- $G
Translation of "recently trained": the young.
A shop that evaluates candidates on computer science fundamentals (which is a very good idea, IMO) is going to favor those recently exposed to them. While I took the classes and got A's... I got my masters in 1999. 15 years is a long time to suddenly remember the details of A*, figure out (n) of Boyer-Moore, and white board out a BST delete operation in working code.
Programming languages change in such time. Techniques, jargon.... it is rough for the old.
I am very small, utmostly microscopic.
I think I see your problem. Most companies don't make the developers write code on the board every day, as boards are very inefficient compilers and the intellisense is just atrocious.
I don't understand why we make interviews so uncomfortable for the people we want to work for us. Give a programmer a goddamn keyboard, if you really want to see what they can do. The board is for visualizing high level interactions, not writing modules.
Millions long for immortality who do not know what to do with themselves on a rainy Sunday afternoon. -- Susan Ertz
It's all related to the most profitable configuration for the company.
The problem is, "profitable" usually actually means "what will get me (high-level exec) the most profit in the least time?" Often followed by "before I bail the ship I just helped sink."
Shore that up with bean-counter metrics, projections that fail to properly account for costs (especially intangible ones) and you can easily justify "saving" money by preferring the inexperienced. The only reason why anything has any quality anymore is that advanced manufacturing techniques and materials allows relatively incompetent and de-motivated employees to turn out items that exceed what was possible 50 years ago when low price and cheap junk were more obviously related. Software, however, isn't something that benefits much from microprocessor-controlled fabrication equipment, which is why cheap software is still cheap junk.
The old-time model of a corporation was based on the idea of a more or less permanent core population of differing levels of skill and experience. Since the 1980s the model has changed to the conceit that everyone is an interchangeable cog purchased at commodity prices, used up, and then discarded at will. Except senior management (who are obviously unique, indispensable and irreplaceable, thus mandating extreme compensation).
I think we're at the point in the cycle, especially in Silicon Valley, where youth equates to connectedness with modern trends in technology. It may be a somewhat correct assumption, especially in my case where I find social media and chronic smart phone use to be odious. But I don't think most older programmers feel this way. As people get older and this the social media hype begins to peter out, I think companies will become realistic again. I know quite a few dotnet programmers that are over 40, and when it comes to PHP and MySQL I think companies in general are kind of indifferent about age.
No. You don't have to be a manager, but you do have to do more than sit in your office and code your little chunk of the universe because any kid out of college can do that. Heck, an awful lot of people out of high school can do that and don't necessarily require even a living wage. Older programmers should be mentoring and leading. You don't have to have "manager" in your title to do that. The best programmers are the ones who can lead teams of more than 8 programmers, orchestrating the whole product life cycle. Generally, they contribute code too, but they also worry about repeatable testing, providing a release plan, code hygiene and standards, integration and customization points, and testing. I've been on both sides of the fence, hiring and looking for work as a programmer. This has always been the reality. Your skill set should be commensurate with the years of experience you've had, which means that you should show a certain professional maturity. If you haven't advanced your skills beyond code monkey in 30 years, you've got a problem.
You don't get experienced without time. Time makes you old. The places I've worked (top-10 commercial software developers such as Microsoft) actively seek out experienced programmers. I'm in my 40's, and the companies I've talked to in the last two years consider my experience a big plus. They don't care how old I am, they care about what I can do now, and the proof of being able to do it successfully my background provides. Besides, what are the chances I'll still be there in 10 years? The same has been true for me when I hire developers. Entry level programmer? get someone hungry who will work hard and (relatively) cheap. Need a strong technical lead to architect, design, and implement part of something big? Hire someone who's been in industry 20 years and done it before. If you've delivered good results in the past and are a good programmer, the big software companies are desperate for you. I've seen jobs sit open for a year or more because there weren't enough good, experienced applicants. I've seen the same needs at bigger software houses in Silicon Valley. I can't speak for startups because I haven't done that, but there's a lot more than startups in the bay area...
I always thought a better, and in some cases, more real life test for a programmer would be to hand them a chunk of someone else's code, something real and in house but obviously not something that is proprietary. Ask them to recommend ways to improve it if possible, or explain why it is good, sound code if not. Good programmers will recognize good code (even in languages they haven't worked in) and recommend fixes where they see problems. Someone you want to hire will be honest about whether or not they've worked in the language and will almost immediately spot things like potential null pointer exceptions, potential leaks of connections, unhandled exception possibilities, etc. or even just poorly structured code.
If you're already talking about unionizing to "fix" the problem of finding and keeping work for unemployed programmers, you've already lost.
I've been programming 20 years. I picked up Pythton in 2 days, and inside a week had a multithread serial port driver embedded in someone else's framework, which had never been done and. they didn't think would work.
The foolish young punk.
In seriousness, I see many young ones treading down the same paths and mistakes. Clearly colleges aren't keeping up with lessons learned in the field.
(-1: Post disagrees with my already-settled worldview) is not a valid mod option.
Be happy it was a CS test. The engineers in my company don't have any sway with HR. The incoming software engineers don't have to write a scrap of code before they get hired. Instead they're given a generalized IQ test. That's it.
So you don't implement bubble sort on the job, just how often do you pattern match 3 geometric shapes?
The simple CS test is a gate to see if you can code. They probably have a lot of applicants that can't even do this simple test. And doing it in person in real-time solves some major problems.
It's just a puzzle. A simple puzzle to make sure your brain isn't mush. It's just about the same as seeing if you can schmooze with office workers and small-talk with HR drones. And if they're doing it right, it's certainly not the last gate you have to get through before getting hired. Hopefully they quiz you on the higher level skills and yeah, a code review of some previous work sounds like a good idea. (As if I could show any of my military contract work in a job interview).
So hey, reverse this string, write out fizzbuzz, or sort this array. Can't do that? There's the door. If you can do that, then we can move on to the next step.
Yeah. Almost as funny as the Microsoft/David Korn standoff.
Have gnu, will travel.
Since Java has been around for nearly 20 years there is a whole generation of management that is convinced of the dangers of developing without a GC. Then there is the whole fleet of youngins who are scared to manage memory allocation themselves. Native code is being expunged from all but niche corners of development because of the inexperience and ignorance of the masses.
I am becoming gerund, destroyer of verbs.
It will probably drive up the level of Consumer intimacy with code.
As more "experienced" end users with more time on their hand, and less tolerance for poor quality code emerges. And more "experienced" programmers reside on the Consumer end of the pipeline... with lots of surplus time on their hands.
The concepts of "open source" and "shared source" will probably grow.
Microsoft will probably even have to "open up" and may receive help with "documenting their code" for future generations... or risk irrelevance like an ancient fossil buried in time. Software archeologists will be unearthing Technet in the far flung future.. unless they adapt.
Its rather an anomaly that we currently have industries based on the idea of "software rarity, scarcity, and end exclusivity.." its more natural to consider a program and source code to be included in the Appendix of a book. Because once it looses currency or context.. the book is the only referent. Consider a niche spreadsheet like Quattro Pro 123 or Wordstar.. anybody "know" how to install or productively use those today?
Microsoft is as much like Apple and Apple is like Microsoft.. they live in the moment.. and if they slip into the past too much.. then they disconnect with the customer base willing to accept the unique ideology "pay for software".
Eventually that ideology will shrink.. as free software, documented and opensource software gets "good enough".
Google and Red Hat on the other hand will probably become even more relevant.. even if Patents are used to attempt to strangle them simple because of the "poison pill" built into making their source code available. As a support model.. they could go out of business and be forked..
this should get modded up. Spreadsheets say "if it takes 1 person 3 months, then with 3 people it will take 1 month". But spreadsheets cannot account for change (loss) in velocity because of the time needed to coordinate 3 people. Spreadsheets says "if it takes 1 person at $2000 3 months, then with 3 people at $500 each a month, it will cost less and be done in 1 month". But spreadsheets cannot account for experience that may change design decisions which affect total cost. I think this mentality is more prevalent in larger companies. In startups (or with startup new product), bottom line is quick out the door and as low cost as possible. Unfortunately, the spreadsheets cannot account for the higher maintenance costs long term because of decisions made in a rush to get it done. The spreadsheets says it costs $X 5 yrs ago so why is it now costing $10X.... I am dealing with this every day. True story: I was asked to estimate some work by a big MBA executive type. I put my team together and we provided and estimate. He said it was too high we needed to review it. We did. We pared it down a little ( 10%). He said that was too high. He already told the customer X. We are factoring in fixing problem areas, and missed or misunderstood requirements, and time for unit testing and time for integration testing. In otherwords we are trying to factor in those intangibles. Experience has little value (above a certain amount) unless you can make it measurable in spreadsheet. I think the person that can solve for these intangibles and make them tangible and measurable will become very rich.
I've always said English was my second language. Had Romeo and Juliet been written in C, I might have understood it.
Starting in 2000/2001 (outsourcing) the landscape changed, and development projects became very difficult to find. I had thought there would always be work for good people, and I thought I was one of them. Little did I know how little management cared for the retained wisdom of the more experienced software engineers. There are lots of young programmers around, but a commitment to larger practices was what made software engineers. I think it is a terrible waste that America has so many experienced software people flipping burgers or unemployed when we need so desperately to compete internationally.
They also teach search and rescue in our rubble piles and collapsing buildings.
HOLY COW, now THERE'S a gig: building collapsing buildings.
Demand: There's ALWAYS another construction job to do next week.
Quality? The damn thing needs to stay standing for just a few days.
Obsolesce? No one's surprised when it falls apart.
Insurance? If it collapses and kills someone, that's just job training -- NOT my problem.
Offensive rubble color? Just wait a week and this time ask for Baby Blue.
Contractor termination scenario:
Builder: Bob, I'm afraid we're going to have to let you go.
Bob, crying, in shock: But why?? I do the absolute best job that I can do! My work is built to withstand anything!
Builder: Well Bob, you see: that's the problem.
The neighbors that come by and always complain about the smoke and noise? That's easily outsourced to friends:
That division includes an on-staff sniper.
Yes, we nerds are suitably embarrased by this fact.
Ob Dilbert.
If the universe is someone's simulation -- does that mean the stars are just stuck pixels?
My first software engineering job in the silicon valley was in 1978. I've been in and around the valley ever since in both engineering and project management. I've yet to see a bias against older programmers. I'm nearing 60 now, and I certainly have no issue finding work. I work for a small startup in the cloud application integration space. I would guess the average age of the engineering team is closer to 40 than 25. While I've never seen age discrimination, I have seen programmers who let their skills stagnate complain about age discrimination.
Probably because it's a hassle to set up the interview that way. What computer do you plop down for the interviewee, what editors do you provide, do you make them do some stupid point-and-click IDE or let them use vim or emacs, etc? Then you have to arrange for the computer somehow that is clean and wiped and properly set up in time by IT, etc. Sure it can be done but I've never seen it happen.
But on the other hand, a programming job is not only about programming, especially at more senior levels. If the person can't communicate well on the white board, what does that say about the person communicating ideas in front of the peers, or communicating with customers or other departments? I'm an introvert, but I have to spend a LOT of time using people skills on the job.
Yes I understand that people aren't as comfortable writing code on the board, that's normal. I take that into account, everyone who's interviewing candidates takes that into account, perfection isn't the goal. And of those who aren't comfortable at that, I would suspect that 75% are also uncomfortable writing code on an unfamiliar computer while someone is watching them (and you do sort of have to watch).
OMG! When will slashdot stop posting repetitive, whiny "I'm old, can I still program" stories!? I guess I have another 20 years of "Am I too old..." headlines to look forward to before they finally push me into my grave.
A lot of companies and businesses have programmers that do not fall under the 'tech company' category. Insurance companies, colleges, railroad companies, large store chains (eg: Walmart and Target), RV companies, and many other industries all have in-house programmers. All of these businesses and industries are scattered across the country. Unless you absolutely must work in a tech company in silicone valley, you should not limit your options. My first career oriented job was at a relatively small health insurance. A very large part of their software was developed in-house. They had some developers that were only in their twenties, but the majority of them were at least 40, if not in their 50s or early 60s and preparing to retire. Why? These companies see the software as just an in-house solution to a problem and not a product in itself. They do not need someone that can write in whatever the fashionable language of the day is. They need someone that has the skill and efficiency to maintain a system that was probably written some time ago in a language that fit their needs. A 20 year old that only knows C# is not going to be of any use to them when they need someone that can quickly adapt their in-house solution that was written in C or Fortran to fit new health insurance laws.
Some places higher young programmers because they are cheaper.... but some places purposely higher older, experience people. Consider all options, not just tech companies in Silicone Valley.
If you were really writing CGI apps in C and not using stuff like FastCGI then your apps would likely be slower than a FastCGI or modperl/modphp etc program due to the overheads of process creation.
So yeah it does seem silly to use C, a slow to develop language combined with CGI, a slow way of running webapps. Worse of both worlds.
How many pages per second and concurrent requests could your CGI C apps handle?
We're actually soliciting bids for a new rubble pile to be built. We'll pay several million dollars to whoever builds our next pile of broken concrete. I suggested that the ordnance disposal class could build one cheaper ...
We DID have complaints about smoke and noise. It probably didn't help that the fire field is at the end of the main runway for the local airport, so visitors flying in often ser large plumes of smoke just past the end of the runway.
The higher ups wanted to move the fire field to a more remote location and use that land for another purpose. Our director did the obvious thing - he "crashed" to 300,000 pound locomotives in the middle of the property, accessible only by dirt roads. He told them "sure, you can have that land back, you'll just have to drag 600,000 pounds of Amtrak to the new place somehow." Twenty years later, we're still there. I wonder if that director was BOFH in a previous life.
I joined the company I currently work for at 40+. Since then, we've hired people older than me (young ones too).
Shameless plug:
We're looking for good C++ developers. Age is not an issue.
Good company. Turnover is close to nonexistent. Interview is murder.
Location: Richmond Hill, Ontario
They had discovered that they paid as much in workers comp for desk workers as they did for hardhats. There are a lot of ways to hurt backs, hands, eyes, necks in the poorly designed non-ergonomic open-plan offices. And those injuries are expensive to diagnose and to treat.
As someone pushing 50, programming since my teens, I have to agree with this, and maybe to generalize, older programmers should also pursue embedded systems jobs in such companies, since an older programmer probably has a lot of related experience working on constrained systems and dealing with low-level custom protocols and such. I did a job search starting in early 2011 after several years as a (part-time) stay-at-home dad (not good on a resume to most employers), while also doing a couple Android apps (not much sales), some paying programming projects for my wife's consulting work, various free and open source stuff (including Python, Java, JavaScript, and CouchDB/NoSQL), and a bunch of (unpaid) writing about technology and society. It took about nine months of looking to land a position after sending out 100+ resumes, working my way down from dream jobs (e.g. Willow Garage telecommuting) to just about anything as our finances dwindled. We've generally only worked for others when we ran out of cash and credit to fund our own free and open source stuff, and my wife's consulting work had hit a dry patch with the recession, and apps I wrote were not selling well, and making money of my writing somehow did not look promising. I thought about trying to make a go of selling software as a service, but it just seemed too risky.
It was a tough search given the Great Recession then. Ultimately I got a contracting job at a big ancient-by-internet-terms broadcaster supporting internally-developed broadcast infrastructure software that has been in use for over fifteen years. It is a sort of soft-real-time embedded system requiring extremely high reliability with possibly million dollar costs for seconds of downtime (like affecting commercials during sporting events). Unlike your father's example, adjusted for inflation, the pay is much less than I used to make in my early 30s doing Smalltalk (the hot technology then). But, I did not have to move for a contract as I did then, and I can work mostly from home, so that's a big perk as far as contracting jobs go. There is a significantly older developer than me on the overall project, plus a couple highly experienced managers older than me. In general, I'm very thankful for the job, and the people I work with are nice, and the work itself is challenging in an interesting way (if you like the puzzle of making sense of the work of dozens of programmers of various styles and levels of competency over more than a decade in multiple languages implementing a complex task).
I can see though that as a programmer I am slowing down in some areas (even if I have other strengths). As someone who has spent decades always being the best overall developer around, this is the first project I've been on that I've had to admit to myself there are better programmers on the team than me in many respects. That is a bit of a blow to my ego.
It's also the kind of position I probably would not have stayed in or done well in in my 20s or 30s, including because the emphasis is more on reliability than innovation. Reliability at first glance is boring, but it still has its own more subtle creative challenges both technically and socially, and there can still be a lot to learn and do. For example, ironically one of my big "value-added" efforts was getting people to agree to get rid of a somewhat-unreliable recently-added component to the system by helping find the root cause of the problem the additional complexity was supposed to fix (but ultimately didn't). When I was younger, I would have been more likely to have tried to get the extra complexity to work instead of spending months navigating the social and technical landscape needed to remove it. How do you measure "programmer productivity" when the end result is making a system more reliable by getting rid of an expensive piece of custom hardware and software which sounded like a good idea at the time? I'm inspired in this in part by Andy Hertzfeld's essay about Bill Atkinson and "-2000 Lines Of Code":
A 21st century issue: the irony of technologies of abundance in the hands of those still thinking in terms of scarcity.
Which region? What country? What development area? What language?
If you are an old coder wanting to get some job at some startup mobile app social networking company, sure...probably you don't fit the profile.
For everything else, I am sure age trumps youth, as people who run companies tend to look at the extra they are paying you as a good return on investment when delays can cost you millions, or clients, etc. Experience wins every time.
No program of such nature ends up working as you intend. They are only used to deny people any ability to think/act in the long term.
Twitter supports and protects racists - by smearing their critics with the "Hate Speech" label.
It's all related to the most profitable configuration for the company.
The problem is, "profitable" usually actually means "what will get me (high-level exec) the most profit in the least time?" Often followed by "before I bail the ship I just helped sink."
Shore that up with bean-counter metrics, projections that fail to properly account for costs (especially intangible ones) and you can easily justify "saving" money by preferring the inexperienced. The only reason why anything has any quality anymore is that advanced manufacturing techniques and materials allows relatively incompetent and de-motivated employees to turn out items that exceed what was possible 50 years ago when low price and cheap junk were more obviously related. Software, however, isn't something that benefits much from microprocessor-controlled fabrication equipment, which is why cheap software is still cheap junk.
The old-time model of a corporation was based on the idea of a more or less permanent core population of differing levels of skill and experience. Since the 1980s the model has changed to the conceit that everyone is an interchangeable cog purchased at commodity prices, used up, and then discarded at will. Except senior management (who are obviously unique, indispensable and irreplaceable, thus mandating extreme compensation).
Juniors and newbees to programming will delight in 16 hour days and short delivery schedules. That product that they produce will be as good as any Monday morning product. Full of potential, but also costly to maintain. Bug fixes in the field cost lots of $$$$.
The senior, works his day, perhaps after supper another two hours, but those two hours are for quality control. Who has the cleanest bugfree code? Any answers to give?
Leslie Satenstein Montreal Quebec Canada
Juniors and newbees to programming will delight in 16 hour days and short delivery schedules. That product that they produce will be as good as any Monday morning product. Full of potential, but also costly to maintain. Bug fixes in the field cost lots of $$$$.
The senior, works his day, perhaps after supper another two hours, but those two hours are for quality control. Who has the cleanest bugfree code? Any answers to give?
Once I've gone home for dinner, I'm done for the day. I already know from years of experience that the all you're going to get in the nature of quality creative work per day in a commute-to-work office is about 6 hours and more time in the office will not make any positive difference.
The exception is the stuff that hits me while I'm having "shower" inspirations.
What you get from experience isn't necessarily bug-free code. But code that has been properly thought through, aided by experience, is less likely to be a hack-job design where every bug fix pops out another bug somewhere else.