How to Get Your First and Second Jobs in the Tech Industry

Add Your Comment
6 July 2010
Posted in Company

First, this blog post is just my opinion based on my hiring experiences. Other hiring managers are sure to have other priorities, so take this advice with a grain of salt and use what you can. As a bit of background, I graduated in 1987 with an BSEE from The Ohio State University, and over the years have interviewed many job candidates, either directly hiring or giving my opinions on dozens of entry-level and senior candidates for programming, systems administration, and other positions. What this did is give me the opportunity to see correlations between how candidates presented themselves in job interviews and how they actually performed on the job.

The first thing to know is that its impossible to predict how any individual candidate will perform based on an interview and references. I have seen candidates have perfect grades, nail every question in an interview, have impeccable references, and yet be completely or worse, mostly useless on the job. This is especially true of entry-level job candidates with little or no work history. Even so, work history by itself isn’t a guarantee of future performance, it simply increases the chances that the candidate can actually do the work.

For large companies the risk of hiring entry-level workers is decreased with numbers. If a company hires many entry-level workers, they can afford the overhead of training a bunch, firing the under-producers, and repeat each year to build up a quality workforce. Smaller companies don’t have the luxury of this approach which makes hiring a riskier proposition.

WIth the background out of the way, I’m next going to lay out what I look for in a technology employee. First and foremost I look for people who are interested in technology of any type apart from their school work. Successful technology workers must keep up with changing technologies, and have a strong urge to continually research and learn. This is much more likely if someone is genuinely interested in the technology, and can’t wait to learn about a new API or way of programming. Time after time I’ve interviewed graduating students who knew nothing outside of their classwork, and I have to wonder why in the world did they get a computer science or electrical engineering degree? How in the world can someone get a degree in an area without reading a single industry magazine or book outside of class?

Most candidates can tell me about something cool that inspired them, but simply being inspired isn’t enough, I want to see that the candidate was inspired enough to learn on their own. For example, if the candidate was inspired by computer games, I will probe to see if they went and learned about the technology. Does the candidate know what algorithms are used to generate realistic 3D images in real time? I’m not specifically hiring for a computer game programmer, but the idea is that the person was inspired enough to learn independently.

The thing that the job candidates I’ve interviewed lately don’t seem to get is until I see concrete proof I’m going to assume that every single one of them never learned a single useful thing in school. I’ve talked to many people who claimed to have a 4-year CS degree and yet didn’t know the difference between an integer and floating point.

But even learning outside of school isn’t enough for me, I want to see actual activity outside of regular school work. Have they ever even compiled an open source program? Configured a complicated Linux system on their own? But those are just high-school level activities; the best thing I like to see is a student doing programming projects outside of school, either on their own or with others, and it doesn’t specifically have to be open source.

Consider how you’d pick an architect to design a house. Would you look at her GPA, and quiz them about classes they took? Or would you look at their portfolio and actually see what they’d designed before? By the same token, I look for engineer and computer science students, especially, to show me a portfolio of work, including design documents and lots and lots of code. This portfolio should be expanded as one goes through a career, adding more and more code, and including anything that could provide proof that one actually worked on the projects listed. Sure, someone could just steal some code and claim it as their own, but that’s easy to project against: first, they’d have to answer questions about it, and secondly, they’d have to be able to recognize code that was worth stealing. Work from the core curriculum would be OK, but I’d much rather see work on outside, independent projects or published papers.

What about internships and summer jobs? The problem with those is they tend to be trivial, as summer interns usually get crappy jobs, and they don’t result in anything worth putting in a portfolio. What about practice what you preach? My own portfolio is now several inches thick, and I’ve had to cull out a lot of the earlier entries from the late 80s, one downside of being in this industry for a long time. It’s great being able to look through old documents and be reminded of old projects and the people I worked on them with. I’ve been showing this book to new hires for a long time now, and hope that eventually this will become the norm in the industry. Give it a try and let me know if it helps you get that first or second job.

Michael Czeiszperger
Founder, Web Performance, Inc.