Thursday, May 9, 2013
Loop de Loop
Some time ago, an unnamed engineer applied to the unnamed company I was working at for a Sr Web Engineering role. I was in the chain of onsite interviews. Actually I was the final interviewer. My role was to challenge the person to the depth of their technical expertise. I really like that role. I found that when I compared notes with other engineers at the same company, most would ask pointless and non-revealing questions that didn't provide the applicant a chance to show what they know and how they think.
Anyway, this applicant had passed the phone screen. The notes were positive and suggested a high quality candidate.
I started the interview with my usual array of general technical questions, exploring the depths of their experience. I was not interested so much in what they knew as what they could do, so my questions followed a practical path of how would you do this, why would you do it that way, etc.
So the practical exercise was also a standard approach for me. Generalized, it was a task to collect all the DOM elements on a page that had the same classname. Now that task is easily provided by jQuery selectors, getElementsByClassName, querySelectorAll, and other more primitive functions combined with some javascript.
My requirement was that they use none of these, but write the function manually. This requires basic knowledge of the DOM, knowing where to start and how the DOM nodes relate to each other. Its a very straightforward tree navigation task.
That said, very few of my applicants ever wrote a clean version of this task. As a matter of fact, only one ever did it right without any coaching.
Now solving this problem was not the bar they needed to jump. No, it was much simpler. First show you understand the kind of problem it is. Say the words "the DOM is a tree". "I will have to iterate the tree starting at the root node (document.body) and collect any elements who's classname has the desired pattern". "And then return the array of elements".
If you could say that without help, and write a 'non-pathetic' solution you were hired.
I would offer help to the candidate in the form of lightening the load when they failed to understand the tree aspect of the problem. I would dumb the problem down a bit and say: ok, the task is to simply filter a set of nodes passed in as an array. Could you write that task out? Doing that well might get you hired. Most Web Engineers can do that. Not all. What a pitiful situation. You cant iterate a linear array and collect a bunch of nodes. What did you do before you got here? Pick your nose all day?
Anyway, this guy took the cake. he was unable to iterate a simple nodelist. I dumbed the task down ever more: Write a loop that adds up the numbers 1 to 10 and returns the sum.
C'mon, my dead grandmother could do this. But he couldn't. I looked at his resume again. He was a Sr Web Engineer, 10+ years experience. What galaxy am I in? How did this person get in here?
I knew no one would believe me so I took the giant pad we had setup in the interview room back to my desk and stashed the page in one of my drawers. I might need some real evidence of this guys truth. And sure enough I did. The other three interviewers gave a thumbs up. I vetoed vehemently and offered proof for anyone needing convincing.
Now maybe the guy just had a brain freeze. Ok that's fine. He can apply somewhere else. And he did. He applied to a consulting firm, got hired and 3 months later was working in my office as a contract employee. The world is a fucked up place.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment