I’ve been busy with professional contractination work, which is a word I just made up to describe the chaos that goes on while being vetted for a new client. “Do you know PHP5?”, “What is class inheritence?”, “What’s the difference between include and require?”, etc. I wish I could make a indexed video of me answering these questions but I don’t think that would work for some reason. Still its just par for the course and I really don’t blame the client or the client’s gatekeeper asking because I’ve been on the other side of the fence, vetting out people and its a miserable task.
My resume shows 5 years of contract work and I’ve got half a dozen references ranging from developer peer’s to team managers and c-letter people…but from what I’ve seen none of that matters. Out of respect for all involved, I won’t be mentioning names, employer, or anything specific. Last thing I want is to kill someone’s career or tarnish a client’s reputation. That said, I’ve seen some pretty terrible “Senior” developers. What I mean by terrible has little to do with how they solve problems, but the fact that they don’t solve problems.
One recent case, I worked with a “Sr.” developer that proclaimed themselves “Team lead”, “Chief Architect”, and “Dev. manager” which was surprising because I finished three different projects on time and tested for production use in the time that this individual struggled with one project. Speaking to the CTO of the company I got to look at the person’s resume and it all made sense. They had been in the industry for 4-5 years as well, but 3 and a half of those years was as a “junior” developer in a fairly large team. Then they jumped or got booted and fell into my client’s company and became the defacto “Senior” developer because there was no one else. I think two things fed this person’s loose grip on their reality. In very large company’s, I’ve noticed that junior developers are not to be seen or heard and instead are programmers. They aren’t given opportunities to grow through mistakes and failures because that’s not what they are there for. Then the other side is that without peer review from competent peers… its easy to imagine your poop smells like roses.
Another case was a peer that got signed to the same company as me, both as contract to hire. One unique thing about this situation was that I knew NOTHING about the language or technology being used. The only saving grace is that the team leads had re-implemented a better/saner version of a framework pattern I had designed a few years ago. So of course I struggled in the first week and somewhat into the second week, but fortunately the language in use was imperative object oriented so everything eventually clicked for me. I won’t lie and say I was a super star, but I did my best to pull the line and help the team meet its goals. Meanwhile the other contract made a lot of mistakes: it’s generally a bad thing to hit on the female staff at work, if the product lead takes the time out to give you advice… its probably cause your fucking up, and lastly do not alienate your peers. Healthy dev. teams are like Survivor… if you become the weakest link and cause others to work harder to cover your ass, you will find yourself out of a job.
What I am getting at is that, in both cases it would be tough to figure out if someone can actually do the work needed for an employer. Their resume might look amazing or their credentials impeccable, but neither really mean much. The subject of vetting out good candidates has been covered over and over across the web and print…so I will keep my advice simple. If you have a small team or no team, go with established recruiting firms that will incur penalties to themselves if they recommend a dud ( generally 5-10 business days covered ) or if you do have a team, get them involved in the last stage interviews and see if this person fits in. I am sorry, I know this would seem to eliminate anyone who has text anxiety or social disorders… but time after time Geeks & Nerds recognize their own.