A Job Interview Trap Designers Might Avoid
I was caught off guard during a job interview after I told the story of my Ghost-O-Meter app. My audience was several designers and one developer who sat quietly on the edge of the group eying me skeptically.
I told them how the breakthrough in Ghost-O-Meter didn’t happen in the design or development phase. The moment Ghost-O-Meter came to life was one week after it was “finished.”
I could have shipped the app sooner, but it didn’t feel right. It matched my designs and it functioned as intended but something was missing.
The main UI of Ghost-O-Meter is a needle that responds to the intensity of the paranormal activity it detects. Although the needle accurately wiggled and moved up and down the scale it felt sluggish and lifeless.
When I was a kid I remember being mesmerized by the controls on my parent’s stereo. There was one panel in particular that fascinated me. It felt alive. A tiny window held a thin needle that bounced and danced along with the music measuring something about the sound that was far to technical for me to understand. That was the magic I wanted to recreate with the UI of Ghost-O-Meter.
So I kept rewriting the code until I finally I got the needle movement perfect. This is the moment in my interview where the skeptical developer spoke up.
“What was the code that finally solved the problem?”
The question caught me off guard. I sensed it was a trap with follow up questions like,
Why did you choose technology A over technology B?
Why didn’t you seek help from a more senior developer when you were stuck?
Why didn’t you ship the app when it was a viable product, then release an update that improved the needle movement later?
Did you consider method X?
These are valid questions, but they are traps. If I had answered honestly I would have insulted the developer because…
The truth is I don’t particularly care about the code as long as the result matches my vision.
The truth is my code was ugly and probably could have been improved by a “real” developer.
The truth is I wrote the code myself because I didn’t have the vocabulary necessary to write specifications for the vision I saw in my head.
The truth is that there were holes in my code knowledge that a competent developer could use to cut me to shreds, humiliating me in front of the group.
I scanned the face of the developer, trying to guess his intentions. Friend or foe? Perhaps it was my imagination but there seemed to be something hostile in his tone that convinced me to dodge his question with a brief description of hardware accelerated CSS and a promise that,
“I’ll email you the code and I would be curious what you think.”
Which of course I never did. Because evaluating a designer’s code misses the point. The app’s problem wasn’t solved by design thinking or code maneuvers. I only got there because I was determined to recreate an indescribable feeling I experienced as a kid hypnotized by an analog stereo.
Design school doesn’t teach you that the majority of your career will be spent wrestling with things that don’t quite feel right. The finished product might match your designs pixel for pixel. It might function exactly as described in your specifications.
But there’s usually something missing.
You will look for the solution in whatever process is popular at the moment. You will evaluate different technologies looking for the answer. You will be seduced by theories about minimum viable products. You might believe the promises of iteration, quality control, data, and agility. Maybe those things can get you there. But you should have a contingency plan. When process fails the only factor that can push your creation over the edge is your determination to keep pursuing an indefensible vision that seems silly to skeptics.
Stay creative.
