Considering the number of complaints I hear about recent graduates not being good at work, it’s possible that schools aren’t doing a good job of preparing people for typical office jobs...
In my experience, schools aren’t doing a good job of preparing them for software engineering jobs, either. Most of the candidates I’ve seen (and I’ve seen quite a few) run the gamut:
Has heard the word “linked list” before (just for example). Doesn’t know what it means.
Has heard the word “linked list” before. Knows what it means. Doesn’t know what it’s for.
Can answer basic questions about data structures and algorithms. Knows what they’re for, in theory. Doesn’t know how he’d actually use them.
Knows how to use basic data structures and algorithms. Can apply them, but only if he is given a source code file with clearly labeled “YOUR CODE HERE” sections. Doesn’t know how to get help, or how to ask for help. If he gets stuck, just sits there, staring forlornly at the screen.
Knows how to write programs. Knows how to ask for help directly. Doesn’t know how to find help on his own.
Knows how to write programs and how to look up answers to questions. Forgets the answers as soon as he looks them up; doesn’t know how to correlate them into a general picture. Does not believe that a general picture exists.
Knows how to write programs, how to look up answers, how to ask for help, and is able to actually learn on his own.
The last category is actually employable, and makes up maybe 5% of college graduates. The other 95% either lack the basic CS vocabulary needed for learning, or are unable to learn at all, which renders them quite ineffective as far as real-world software engineering is concerned.
Does this mean that those of us who are close to the bottom category actually have a really good chance of getting software engineering jobs? Or is the job selection process equally defective?
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.
In my experience, schools aren’t doing a good job of preparing them for software engineering jobs, either. Most of the candidates I’ve seen (and I’ve seen quite a few) run the gamut:
Has heard the word “linked list” before (just for example). Doesn’t know what it means.
Has heard the word “linked list” before. Knows what it means. Doesn’t know what it’s for.
Can answer basic questions about data structures and algorithms. Knows what they’re for, in theory. Doesn’t know how he’d actually use them.
Knows how to use basic data structures and algorithms. Can apply them, but only if he is given a source code file with clearly labeled “YOUR CODE HERE” sections. Doesn’t know how to get help, or how to ask for help. If he gets stuck, just sits there, staring forlornly at the screen.
Knows how to write programs. Knows how to ask for help directly. Doesn’t know how to find help on his own.
Knows how to write programs and how to look up answers to questions. Forgets the answers as soon as he looks them up; doesn’t know how to correlate them into a general picture. Does not believe that a general picture exists.
Knows how to write programs, how to look up answers, how to ask for help, and is able to actually learn on his own.
The last category is actually employable, and makes up maybe 5% of college graduates. The other 95% either lack the basic CS vocabulary needed for learning, or are unable to learn at all, which renders them quite ineffective as far as real-world software engineering is concerned.
Does this mean that those of us who are close to the bottom category actually have a really good chance of getting software engineering jobs? Or is the job selection process equally defective?
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.