How I Was Hired and Rejected For The Same Job

Reaching the end of my time in the Game Design program at the Vancouver Film School, naturally thoughts drift to job seeking. On that note, I thought I would share a funny story about how I got my first high tech job.

This story takes place 11 years ago. I received a phone call from Software Kinetics Limited. Someone from SKL was on the school’s advisory board and I had given each member a resume. To be honest, I had not expected anything to come of it.

SKL was in the business of designing software under contract for government and industry. They had an upcoming project with an opening for a junior software designer, working in a language called TCL (pronounced tickle). I was very upfront that I had never worked with TCL, and that other than hearing the name, I new nothing about it. The woman from HR said that was fine, and that they still wanted to interview me.

So a date and time were agreed upon and on the appointed day, I went in for the interview. It was to be a two stage interview, first with HR and then the real interview with the department head.

The first interview went great. I answered all of her questions easily. I could tell that I made a very favorable impression. Then I moved on the the second part of the interview.

The interview started great. The interviewer seem to like my responses. I was confident and could feel that I was knocking it out of the park. I couldn’t ask for a better interview.

Then he asked me what I knew about TCL.

I repeated what I had told HR. I really knew nothing about it, but was sure that I could get up to speed quickly. I had been up front about this from the start, so it assumed that while they would have preferred someone with TCL experience, but it wasn’t a hard requirement.

I assumed wrong.

The entire tone of interview changed immediately, and I knew that I wasn’t getting the position. The interviewer sat there for a moment, thinking. I must have impressed him enough to think me a good hire, just not for his TCL project. He asked me to wait while he fetched another manager to speak to.

The other manager had put in a bid for a project that he was expecting to win, and was beginning to think about hires he would need. The project would be a Windows project in C++, which was a much better match for my skills. However, it was premature to actually be looking for staff for a project he hadn’t won yet. This wasn’t a real interview, just an impromptu meeting.

After that I left. I was sure I wouldn’t receive the TCL position, but was hopeful for the C++ one.

A few days passed. I believe it was the following Monday. I received another phone call from SKL wanting to set up another interview. I agreed to come in the following morning.

The interview consisted of a fairly formal technical interview where I was grilled on my knowledge of C++ and Windows.

I felt the interview went very well. At the end, I was told that he would let me know within two weeks. Then thinking about it for a moment he added that he’d try to get back to me within a week.

So I went home feeling better about this interview than the last, but not thrilled with needing to wait a week or two to find out if I had the job.

Then that afternoon I received a call from HR with an offer. I went in the next day (Wednesday) to sign the contract and I started Thursday.

They had apparently received verbal conformation that had won the C++ project, but the contracts hadn’t been signed yet. So they decided to temporally assign me to another group, until the actual startup of the C++ project.

So they put me into the TCL project. I was now doing the job that I had originally been interviewed for.

When I got home Friday, after my second day on the job, there was a letter waiting for me in the mail. It was a rejection letter from SKL, send after the first interview.

So that is how I was hired and rejected for the same job!

By the way, I never did end up on that C++ project. The client had apparently also told another company that they had won the bid. When the dust settled, the other company ended up with the contract.

I worked the TCL project for several months, until it was winding down. I was third man on the team, which peeked at six. I learned a lot on that project, and found a level of camaraderie within the team that I have yet to find an equal. Not unrelated, I also had the best manager I have ever worked for, Susan Muston.

The project was to build a library of test routines for verification of telephone and network switches. It was pretty straightforward code, but highly dependent on the inner workings of a variety of switches, most of which were poorly documented at best. A large portion of the job was tracking down the one person in the client’s company that had the specific information needed for a given switch.

 

Nevertheless, the project was very successful, despite the fact that almost all of us had never touched TCL before.  SKL had promised the client that they would provide people with TCL backgrounds or, failing that, that training would be provided. Training consisted of dropping a textbook on each of our desks.

That said, I was writing production code on my second day on the job. And the only reason I didn’t on the first day was because a power blackout cut my first day short. Kanata (where this took place) had major problems with the power grid that summer, which led to repeated blackouts. But that’s another story.

 

Breeding ground for game innovation

It has been often lamented that the current generation of video games lack innovative game play, instead offering the same-old-same-old with constantly improving graphics.  The reason for this is clear, with games becoming more and more expensive and thus fewer and fewer actually make profits, publishers are looking for sure bets.  As a result, innovation (other than slow iterative change) is viewed as an unnecessary risk.  No publisher is going to throw million$ at some crazy new idea that might not work.
Yet it should be clear that for games need to innovate.  Who wants to play the same old game.  If we want the consumer to part with their money, we need to offer them something that they can’t get elsewhere.

Yet all is not lost.

There is a venue for pure, raw innovation in games, and it completely bypasses the mainstream game industry.  I am referring to Flash Games.

Flash games allow small teams, or even individuals, to produce small games.  These quick and low budget games can be made around whatever crazy idea that someone comes up with.  Virtually anything is possible in terms of game play or subject matter.

Granted, a lot of them suck.  But that’s not the point.  To have innovation, you need to experiment.  When you experiment, sometimes it works and sometimes it doesn’t.  What’s important is that game designers are free to try, free to experiment, without millions of dollars and the fates of companies hanging on their successes.  Equally important is getting the public to play them.  A game without players isn’t a game.
Ultimately, the public is the best and only judge of fun.  Some games will rise to the top of the pile, others will quickly be forgotten.  This is as it should be.  Failed game ideas are not failures for the industry.  They say in science that there is no failed experiment, for “failures” teach us what doesn’t work.  The only real failures, in game design, are games that are killed before making it to market.

Intros

Hello world!

Hello world is an expression known to just-about-everyone that has learned a non-trivial programming language. For everyone else, the traditional first program to write in every new language simply writes “Hello World” to the screen. This is generally considered the single most basic and simple program possible that still does something (marginally) useful.

However, in the pre-internet world in which this program was first written, the greeting didn’t exactly reach the world. Now-a-days, blogs let you potentially reach a very large chuck of the world.

So, in my first post to my first blog, I say to all: “Hello World!”