Hello all, excuse me. From my point of view programming skills are not really bound to any programming language. It is possible to implement object-orientation in C or even in assembly (with minor limitations) as well as implement procedural code in python or MatLab. The really important skills are not about programming languages but about system design and abstraction. Part of that comes with talent, a lot of it only with years of doing. That's what the boys and girls wonder are not able to offer :)
Agreed. Only after I graduated from the university did I sadly learn how much they did not teach me. Now it is up to me. Maybe if I had spent a few more years there, the professors would have eventually covered what was really needed to succeed.
Absolutely! This industry is in constant change. If you are not prepared to keep up then you don't belong. I, certainly, would not hire someone that gets out of date.
College/university is just the start of your learning.It does not give you a set of skills.
I have interviewed a lot of programmers for the past few years. My general impression is that if you list a lot of programming languages in your resume, you tend to disappoint me quickly when I ask a question that's just bit in-depth on one of the claimed skills. One the other hand, if you mainly list over 10 years of C++ experience, I'd chat with him longer with more interest. The people I work with who have in-depth skills on one language generally take about two weeks to learn to a new language of the same programming paradigm to start working on a new project and maybe another few weeks to become moderately proficient in that language. There are more important things in design and engineering than language names on the surface.
A third way is that the person is a lemming and uncritically follows whatever the language-du-jour is.
A fourth way is that the person may have no people skills, no social life, and no sense of balance or perspective.
I learned to program in color basic and fortran4, then I became very good at programming in UVOS. But I can also program in the Allen Bradley Micro-LOGIX languages, and write program performance specifications that tell a programmer exactly what the code must do. It turns out that being able to know exactly what must happen is more important than the actual language. And it has always been my impression that the choice of a language was determined by what had to be done.
The alphabet-soup array of programming skills can be looked at two ways. One is that the person is well-rounded and can be a great contributor to a project. The other is that the person may not know any of them very well! It might be better in that case to be the world's best C programmer. I always remember this one restaurant I stopped at on a road trip. The menu had every entre on it under the sun, from burgers to chickenfried steak to burritos. I remembered wondering with that many menu pages of entres if any of it would be very good. A couple hours later my stomach was telling me the answer! ;)
I tend to look at it like musical instruments. You can play the same tune on several instruments. This means the main thing that is different is technique between instruments. The question comes down to would a new musician master an instrument faster than a seasoned musician? If yes, then an older musician would not be a good choice to hire if the older musician just learned a new instrument. If no, then it makes since to hire the older musician because he has something that enabled him to have an advantage over the newer musician. Ignoring Front Office Appearance, fads, and looking at skills, older musicians can hang on as long as they can play. I believe the same thing applies to engineering and new skills. The problem comes when HR and not engineering types look at engineering hiring. HR looks at qualifications and mainly sees words to match while engineers understand those words and the skills behind the words. Older engineers may not know all the newest buzz words but they have the experience to understand the new buzz words and chances are they already know the said buzz word under a different older word. The HR person would say to the old engineer you lack qualifications but the engineer would say it means the same thing.
You certainly can poke a lot of holes in my argument. Legal or not, there is a lot of age discrimination going on. However, I'm not speaking about guarantees. Just about improving the odds. Myself, having crossed over into half-century+ club, and not-that-long-ago unemployed, I understand well what it's like to compete with applicants that have to triple-space to fill even a one page resume.
Personally, I've had much better experiences hiring older, seasoned developers than I have youngsters (I've hired three in the last two years. One young and two not young). But not everyone will give both young and old an equal chance. Still, I've only hired older developers who have kept up with the newer technologies.
In terms of whether just self-learning (or class learning) is enough rather than having used it in a project; mostly. Having a decent set of recently learned skills gets you 60% there. It says to me as a hiring manager that regardless of age, you have a fresh and adventurous mind. And that's what I need in a developer skills and a fresh and adventurous mind.
Even better than just learning is to take that knowledge and just build something out of it. If you're into software, build out a web application or two or three for fun and be prepared to show it during the interview. If you design hardware, then build something. It may be more expensive than software, but for the price of a few dinners out, you can have a nice little microcontroller project to bring along.
None of this guarantees a job, but it makes the odds better. And - what have you got to lose? When I was self-learning and doing projects while unemployed, if nothing else, it made me feel better. It gave me more confidence when I did get called in for an interview.
Is it enough just to self-learn and not *use* new languages etc.? Surely the first interview question will be: How have you applied these skills in a project? That said, it does sadden me to see very specific skill requirements being called for when flexibility is, IMHO, much more valuable. How many of us have been hired to do one specific job and, in the first month, been asked to take on something quite different as business needs change?
What are the engineering and design challenges in creating successful IoT devices? These devices are usually small, resource-constrained electronics designed to sense, collect, send, and/or interpret data. Some of the devices need to be smart enough to act upon data in real time, 24/7. Are the design challenges the same as with embedded systems, but with a little developer- and IT-skills added in? What do engineers need to know? Rick Merritt talks with two experts about the tools and best options for designing IoT devices in 2016. Specifically the guests will discuss sensors, security, and lessons from IoT deployments.