My own job-seeking data is stale, since I do have a job currently. From what I’ve seen, though, there’s always a need for the following two categories of software engineer:
1). Someone with a lot of experience, who can easily pick up (and extend) whatever eclectic patchwork of frameworks and home-grown code exists at the current company, and 2). A smart programmer with little to no experience who could work for (relatively) little pay, while learning how to solve real-world problems.
The big problem with category (2) is that these programmers are most often employed as interns, either in a temp position, or with an option to get hired full-time. Unfortunately, interns get paid very poorly.
The job selection process itself can indeed be very defective, but the advantage here lies with the job-seeker. People who have actual skills, or the ability to acquire such, are relatively rare, and thus there’s always some degree of demand for them—which means that they can pick and choose among multiple employers. Chances are that at least one of these companies would have a decent job application process, where they let you talk to actual developers, solve small programming problems, etc. -- as opposed to answering inane questions about the shape of manhole covers, or what your biggest weakness is, etc.
How do you get past the resume keyword-scanning process where you worked with language X for the past 10 years and even if you are in category 1, nobody will hire you unless the job is for language X? Even if there is not literally a computer scanning resumes, a prospective employer should do a Bayseian update that compares the chance that someone without Y on their resume can pick up Y and the chance that someone with Y on their resume is skilled at Y. You would never get to the interview stage unless the total number of resumes is small enough that the employer is willing to interview even applicants with low probabilities of being suitable candidates.
One popular method, if you’ve got a programming job, is to write some automation tools or other minor, relatively language-agnostic projects in whatever language is buzzword-compliant at the moment. Wrote a few build scripts in Ruby? Congratulations, you’ve deployed Ruby infrastructure in a mission-critical environment.
This will usually come out once you’re talking to a human, but at that point you can talk about your personal projects and show off your actual knowledge of the language.
Yeah, that’s tough. The only way out of this that I can think of is to keep practicing other languages and frameworks in your free time, by building your own projects. This way, you could put these languages on your resume and be fully honest about it.
Alternatively, you can do what apparently 99% of job applicants at our company are doing, and lie through your teeth. Normally I’d argue against this approach, but the fact that the vast majority of applicants are doing it is evidence for the viability of the strategy; the fact that people like me actually say stuff like, “It says here you know C#, so let me ask you a basic C# question” is probably just bad luck for them.
My own job-seeking data is stale, since I do have a job currently. From what I’ve seen, though, there’s always a need for the following two categories of software engineer:
1). Someone with a lot of experience, who can easily pick up (and extend) whatever eclectic patchwork of frameworks and home-grown code exists at the current company, and
2). A smart programmer with little to no experience who could work for (relatively) little pay, while learning how to solve real-world problems.
The big problem with category (2) is that these programmers are most often employed as interns, either in a temp position, or with an option to get hired full-time. Unfortunately, interns get paid very poorly.
The job selection process itself can indeed be very defective, but the advantage here lies with the job-seeker. People who have actual skills, or the ability to acquire such, are relatively rare, and thus there’s always some degree of demand for them—which means that they can pick and choose among multiple employers. Chances are that at least one of these companies would have a decent job application process, where they let you talk to actual developers, solve small programming problems, etc. -- as opposed to answering inane questions about the shape of manhole covers, or what your biggest weakness is, etc.
(Replying again to old post)
How do you get past the resume keyword-scanning process where you worked with language X for the past 10 years and even if you are in category 1, nobody will hire you unless the job is for language X? Even if there is not literally a computer scanning resumes, a prospective employer should do a Bayseian update that compares the chance that someone without Y on their resume can pick up Y and the chance that someone with Y on their resume is skilled at Y. You would never get to the interview stage unless the total number of resumes is small enough that the employer is willing to interview even applicants with low probabilities of being suitable candidates.
One popular method, if you’ve got a programming job, is to write some automation tools or other minor, relatively language-agnostic projects in whatever language is buzzword-compliant at the moment. Wrote a few build scripts in Ruby? Congratulations, you’ve deployed Ruby infrastructure in a mission-critical environment.
This will usually come out once you’re talking to a human, but at that point you can talk about your personal projects and show off your actual knowledge of the language.
Yeah, that’s tough. The only way out of this that I can think of is to keep practicing other languages and frameworks in your free time, by building your own projects. This way, you could put these languages on your resume and be fully honest about it.
Alternatively, you can do what apparently 99% of job applicants at our company are doing, and lie through your teeth. Normally I’d argue against this approach, but the fact that the vast majority of applicants are doing it is evidence for the viability of the strategy; the fact that people like me actually say stuff like, “It says here you know C#, so let me ask you a basic C# question” is probably just bad luck for them.