Advertisements
Skip to content

Posts from the ‘Human Resources’ Category

20
May

Life of a Contractor (or, How I learned to be Treated like a Second Class Citizen)

I wish this was hyperbole.

I’ve had a few contracting gigs in my career as a software developer. Really, it is quite common in this industry. Many, if not a good majority, of contractors are not strictly 1099 workers per se (we’ll cover that in a minute); instead, many are employed by staffing agencies such as Robert Half and FGP and farmed out to clients who have an established contract. The employees typically submit hours worked at the client and, if approved, are paid through the agency. There is typically no benefits (or very poor benefits), no paid time off, and, because the you’re not in the “in” crowd of bona fide part-time and full-time employees wholly employed by the client, you may be looked down upon.

From the article Software Developer’s Guide to Contracting Versus Salary Employment by John Sonmez:

You can either be a contractor of some sort, or you can be a salaried employee. In my career, I’ve been both, and each has a distinct set of advantages and disadvantages. In fact, in some companies there is an entire culture built around the differences between contractors and employees. When I worked at HP, first as a contractor, then as an employee, there was this notion of “blue badgers” and “orange badgers.” Orange badgers were the contractors, and they were typically paid less, had no benefits, treated like second class citizens, and even at times told they couldn’t use the HP walkways or participate in any onsite activities. Blue badgers were HP employees who had a blue badge that signified their elite social status. They were employees and entitled to all the benefits contractors didn’t get. It was difficult to become a blue badger. Every contractor hoped to become one, but few did. But that is just one company culture. […] The reason why I am telling you this is that I don’t want you to be surprised if you feel like a bit of an outsider if you take a contracting job at a large company. While there’s nothing wrong with being a contractor, it’s also important be aware that you may not be included in the company culture.

As a developer, I can only attest to what my experience was like from the programming perspective. As a contractor developer, it was not uncommon for me to…

  • Have what considerable experience I had developing ignored. I’m all for having a uniform code base, but it does not require you talking to me like I’m a complete idiot or am so wet behind the ears that my nickname is “Niagara.” I can respect that as a contractor, my contributions could have a lasting impact–both negative and positive–and that, after my tenure, it would be up to someone else to maintain it. (Read this article for some more anecdotes about being a “highly paid consultant”).
  • Be regarded as the lowest rung in the caste system.
  • Have items kicked back from QA/other programmers because it didn’t meet whatever imaginary standard they had.
    • I should mention that as a trick, if you want to generate some plausibility into why you want to nerf a programmer, have QA keep sending back bugs that have been solved and demonstrated fixed. Do this enough times until you have a good percentage, then you can drop the hammer.
  • Be excluded from company events (which was fine; I wouldn’t expect my HVAC guy to join my family picnic).
  • Be accosted verbally. This seems to be a running theme in my life…

Contractors make up a large segment of many organizations. For example, Google essentially runs off contractors, the “invisible workforce, off company payrolls” doing grunt work “for the Silicon Valley giants with few rewards.” Indeed, “[p]eople look down on you even though you’re doing the same work” is the sentiment for many contractors not just for FANG but throughout the industry. The federal government lives and breathes contractors (helps avoid public unions).

I coped with these behaviors the best I could, often just riding them out until the next full time endeavor came along. There were times when it was awfully frustrating to be treated with such little regard. I hate being a contractor; it’s simply not my cup of tea. But, my father always told me: “Put up, or shut up.”

So, I shut up, was shown the door after the company merged with another, and landed a full time position in a job I love. If employees are seen as expendable, then contractors are seen as little more than a means to an end.

To employers, please: I know there are a lot of morons that get past the door, but there are plenty of good contractors who are great at what they do. They are a guest in your house, so try to make them at least feel a little bit welcome while they perform their duty.

Advertisements
15
May

The Games We Play: Hiring Senior Developers

Today I found myself reading the article Senior Developers are Getting Rejected for Jobs by Glen McCallum. I’ll let the opening paragraphs set the tone:

After the initial phone screen they sent me to a 3rd party site (HackerRank) to solve three programming puzzles in a one hour time box. It was my first attempt at this. The first two were easy but the last one was trickier. My solution didn’t pass all the unit tests. It passed something like 8/10 tests and there was no time left to debug it.

At this point I was filtered out of the company’s selection process.

Being a software engineer isn’t easy by any means and oftentimes we (developers) find ourselves traversing through a Dragon’s Layer-esque of quizzes, tests, and the dreaded whiteboarding sessions. Granted, for a more junior-level position, I can understand a good whiteboarding session or some assessments to gauge whether or not the individual learned anything. But when interviewing someone who has years of industry experience, are these miniature gauntlets really helping anybody?


I think part of the problem is the fear of feeling “stuck” with a bad developer. From the article 7 Reasons Why Software Develoment Is So Hard by Paul Smyth, the author cites that “[t]here is no barrier to entry into the programming world and thus it is awash with many poor programmers who adversely affect projects.” Are we at the point where the industry demands perfection in every aspect of operations?

Or is it just practicality?

Continuing on from Glen McCallum’s blog, we see that while developers hate them, companies love them:

Programming puzzles as a hiring gate solve [the problem of a large quantity of applicants and weed out inexperienced applicants]. To a company it is worth skipping over a few great candidates in order to simplify the review and selection process. With a now unlimited pool of applicants they can afford to do that. The numbers suggest that there will always be more good developers in the pipeline.

For this reason I believe that Programming challenge hiring gates are here to stay and will become even more common in the future.

I have bad news for senior developers in the field: many job placement agencies (Robert Half, especially) implement these gates as well. And, as much as I hate them, my workplace utilizes these aptitude tests as we were wasting so much time interviewing poor candidates that couldn’t even tell me what an interface was.

Later we’ll talk about one aspect that exasperated this problem: coding boot camps and the games that they play. Until then, you better know damn well how to use the Strategy pattern in conjunction with a SQL query that can determine the vowel count of every last name in a Japanese customer database and every database has a different collation.