Three Interview Issues Worthy of Discussion

Three recent “interview worthy” issues were recently brought up by a friend who has the misfortune of managing several hundred researchers of various types at a well-known entertainment company.

The three issues are (a) working with other people, (b) deadlines, (c) recent programming experience.

As always, I take these things personally.  But probably these questions have nothing to do with me. I suspect that it has to do with having to deal with self-entitled, prima donna researchers at his international facility combined with possibly a misunderstanding about my recent work.

First, I am probably easier to work with than anyone else I know assuming you actually want to get the job done which is a big assumption. I did time at UCLA in the 1970s, I know what teamwork means and I dont just pay lip service to it. I let people know what they need to know to get a job done, I help them when they get stuck. I explain potential problems and suggest possible solutions to them when appropriate. If anything I have the character flaw of “oversharing”.

There can be a problem when people are insecure and defensive, as they often think I am talking down to them, as I tend to explain things using the English language which has words of more than two syllables. This can be especially problematic with self-identified “producers”.  There can also be a problem when people say that they want to go to the moon, but really want to go to the corner. There are other issues as well, but in general working with people is not a problem when we are all people of good faith trying to get the job done.  

Second, deadlines were problematical in my youth due to my genuine contempt for arbitrary ones. Over the years, I have learned that organizations rely on arbitrary deadlines in order to manage large projects and get anything done. Thus the problem becomes not whether or not a deadline makes sense but about everything else involved with the process of making a deadline, which is to say such things as scope of work, schedule, approval processes, client management, project strategy, resources allocated, the talents and personalities of the people on the project, technologies in development, training, and most of all whether a system has been put into place, engineered if you will, to be able to make deadlines of this nature without too much blood and mangled bodies.

With no false modesty, I will tell you that I am one of the best persons I know to help conceptualize and engineer such a deadline-making system as well as being excellent at managing a process to completion. I can also tell you that, particularly in the entertainment industry, there are people who do anything in their power to prevent and sabotage such a system from being put in place or working. At that point, it is up to senior management to step in and discipline the producer who is damaging the organization or discipline the prima donna who uses chaos and insubordination for their own purposes of self-aggrandizement.

I have often been involved with projects whose goals were so lofty, and the resources and time allowed so limited, that compromises are required to make anything happen at all.  This kind of situation, which often feels like the story of my life, requires everyone to work together.  Decisions have to be made, directions have to be set, people have to be honest.  This is why we get paid.  

Third, the issue of recent programming experience has more to do with structural economic issues and confusion about what the talent for technical work is. Back when there were far fewer technical people available, I was recognized as one of the best on the West Coast. Now that there are so many good technical people in the various fields, I feel, modestly, that I am one of the best technical people on the West Coast. But this can be difficult to communicate to many people today because they are confused about what they want.

Do they want someone who knows the technology inside and out, and can be creative with that technology or do they want someone who knows what -1 means in a stupid software package that they are using on a project because someone thought it was trendy and they might more often get laid? Do they want someone who can design software and has taste, or do they want a moron who is easy to control and knows how to type. Decide what you want.

And then, if you are still concerned, talk to my references, who are near the top of their fields, and see what they say.  

I hope this has helped.