Interviews Are Two-Way Streets

Last year I finally had enough of the company I worked for and began to start looking around for new work. I'm proud to say that I ended up landing an awesome job with Adobe. I knew I pretty much had the job but a recent acquisition of another company by Adobe meant that they had to freeze hiring for an unknown number of months while they sorted out the influx of new employees. Since they couldn't tell me exactly how long it would take and I really just could not stand it anymore where I was at, I began to look for temporary work elsewhere while I waited.

I started shopping around for potential new employers and did eventually find some temporary work to satisfy me until I started my real job. I got to do quite a few interviews with a number of different companies and got to see some very....interesting things. One company, based in Salt Lake City, (we'll call them Markup Pedantry Inc., MP for short) put me through a very odd interview process indeed. It took half the day (about 4 to 5 hours) and while it was odd from the start, it didn't get really strange until close to the end.

Toward the end of the interview process with MP they took turns bringing in different pairs of developers to ask me a variety of different "technical" questions. It started off with the standard trick question drivel I've seen at a lot of companies. You know, the kinds of questions where the answer would only reveal how well you memorized a specific solution to a tricky situation, rather than how well you can solve real world problems with real world tools. Anyway, one of the questions they asked me was something along the lines of this:

On the whiteboard, use semantic markup to model "Old Glory".

I walked up to the whiteboard, stared at it for a moment, then had to ask myself, Am I crazy or is this one of the stupidest exercises I've been asked to do in a long time? Semantic markup is just markup that more accurately describes the information it's representing. Instead of generic DIVs and SPANs you'd either have custom tags, attributes, or classes that more accurately described the contents contained within.

From Wikipedia: Semantic HTML is the use of HTML markup to reinforce the semantics, or meaning, of the information in webpages rather than merely to define its presentation or look.

I've been asked about semantic markup before but it was always as an aside; merely stating the definition of what semantic markup was usually got me by. I started putting something like the following up on the board.

    <flag id="oldGlory">
        <stars>
            <star />
            <!-- repeat to 50 -->
        </stars>
        <stripes>
            <stripe color="#f00"/>
            <stripe color="#fff" />
            <!-- repeat alternating color to 13 -->
        </stripes>
    </flag>

To this day I don't know what they thought was wrong with it, but this was clearly the point in the interview where their demeanor changed as they stared at the whiteboard in bewilderment. I tried to clarify if that was what they were after and they replied with something along the lines of "uhh, sure". The interview finally ended and I never heard from them again.

This was a shop that supposedly used AngularJS and NodeJS. Up until that point, even though it was an odd interview, I felt like they were pretty happy with me. I still laugh trying to figure out what in the world they wanted. With Angular directives in active use at their company and ES6 Web Components on the horizon I assumed custom tags were fair play. I could have easily made them all DIVs with custom classes, but they refused to give me any more clarity beyond the original (extremely vague) requirement so I did it the way I thought would be best.

As you can probably guess, I wasn't too upset that they didn't call me back for another interview. I treat my interviews as two-way streets, as though I were interviewing the company just as much as they were interviewing me (because I am). Treating interviews that way not only helped me weed out choices I would likely grow to hate, but it also added to my professionalism because I was clearly not at their mercy, as it were.

If a company acted at all unimpressed with me, I didn't want to work for them anyway. I knew I had what it took for the positions I applied for and I also knew that I'm quite well-spoken and very knowledgeable within my field of expertise; if despite all my efforts, they still couldn't see that I was the right person for the job, then they were clearly also not the right company for me.

MP is a perfect example of a company that, in my opinion, lost out on a great employee because they had no idea how to interview a candidate properly. Instead, they showed me a glimpse of what working for them might be like. I didn't even work for them yet and I was already being given vague requirements, met with stubbornness when I asked for clarity, and then immediately cast me off when I didn't magically come up with whatever odd solution they had in their heads.

In the past I might have left that building with my head hung low, beating myself up wondering why I didn't understand what they were asking. I no longer waste time wondering about things I might never know the answer to. Rather, I went home and read up on semantic HTML just to make sure I wasn't crazy, then happily went about my business interviewing other companies to see if they were a fit for me.

I would definitely recommend to anyone going through the interview process, that they consider both sides of the proverbial coin. Don't get discouraged when you don't get that return call. If you know your stuff and are confident in your own abilities, then an interviewer's inability to recognize that might not be entirely your fault. Don't get me wrong, it's definitely a good idea to do some self-examination and identify anything you think you can improve on. Just don't get too hung up if you can't seem to find the flaw in yourself.