 |
|||||||||
|
|||||||||
|
|
I remember when job-hunting back in college, lots of business majors would tell me "It's not what you know, it's who you know." Some kids even used it as an excuse to avoid studying in order to go to parties instead ("Why waste time studying pointless knowledge when what really matters is having a strong social network?"). While there is some merit to the idea - i.e. you do want to build your network - this paradigm doesn't apply well to skilled labor that can be objectively measured, like software engineering.
If a job doesn't require much skill, such that there are tons of qualified candidates, then of course personally knowing the hiring manager is a competitive edge. From their perspective, if all else is equal, hiring a known acquaintance mitigates risk. But, if a job does require a lot of skill, such that recruiters are actively competing to find that top talent, then they will beat a path to your door. In software engineering, if you have the knowledge, then people will want to know you. It's a two-way street: developers what to be employed, and companies want the best employees.
I think of it like talent in the NBA - some players just play better than others (I believe all people are equal, they just some have different skills). That's why scouts are running all over the nation, constantly trying to woo the top free-agents. If you're the top NBA draft pick, even if you don't know anyone yet, scouts are going to want to know you.
Sure, I understand that cronyism and nepotism exist, but in software engineering, such corruption would put that recruiter at a serious competitive disadvantage. Worst case, I'd expect that a corrupt manager's greed would trump their cronyism, and they'd hire the best talent. Anything else would essentially be throwing away money.
some what I agree with you, but just give a look to this minimsft.com blog,
you will find even companies like microsoft are not immune to this
networking problem
The problem with this is that software engineering can't be measured
objectively, at least not by the people usually doing the hiring. There is
no useful objective test that takes less than a month, so getting a job
depends not on having the best skills, but on making the interviewer
believe that you have the best skills.
Thanks for your reply. Tom, when you say "at least not by the people
usually doing the hiring" - I guess it comes down to who's doing the
hiring. Just like they have tryouts in the NBA to see if you can really
make a free-throw, you can give quizzes to test a developer's basic skill.
If you ask your candidates to write even simple code, like "write a method
to loop through a string[] and uppercase all elements", you'll quickly
start filtering out unqualified candidates. Many companies have technical
people help with recruiting in order to evaluate candidates exactly for
that reason.
While it is possible to do technical interviewing well, it's not something
you can assume happens everywhere. That is only partly due to the skill of
the people asking questions - in a market where the candidate will get
multiple offers there is a limit to how many questions you can ask. The
coding test that can be easily fitted into an interview is the equivalent
of asking the prospective player to pick up the ball and hold onto it for a
few minutes - you can weed out a surprising number of spectacularly
unqualified people, but it doesn't tell you what will happen in an actual
game.
