= 27d567bc2d48d9f40e9ccc20ea370b15)
Bugmaster comments on Two More Things to Unlearn from School - Less Wrong
You are viewing a comment permalink. View the original post to see all comments and the full post content.
= 783df68a0f980790206b9ea87794c5b6)
Loading…= b715d02e85f7b3b4ae65ca3d3e450868)
Subscribe to RSS Feed
Powered by Reddit
= f037147d6e6c911a85753b9abdedda8d)
You are viewing a comment permalink. View the original post to see all comments and the full post content.
Comments (148)
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--- after all there isn't reliable feedback from graduates or employers to the schools.
I suspect the short-run goals (baby-sitting, status enforcement vs. children and teenagers, acquisition of easily checked credentials) are the ones mostly being served.
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:
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.
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.
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.