Showing posts with label interview. Show all posts
Showing posts with label interview. Show all posts

Saturday, January 29, 2011

Unbalanced Expression

For the most part, interviews have always gone easy for me which is curious because I have an almost uncontrollable fear of social settings. I'm generally so consumed by the anticipation of the event that when the meeting eventually takes place my technical reflexes take over. This is both a blessing and a curse: technical questions and topics are not a problem when in this state but a vague question about personality and past experiences tends toward meaningless rambling about nonsense. Social prowess notwithstanding I've come out on top more times than not in these adventures... until recently.

I interviewed at a startup company where there were two technical questions that I had trouble with. Incidentally, the 'who we are' and 'who are you' portions actually went much better than usual - I do love irony. In either case, the first question was related to querying billions of bytes of data to provide quasi real-time behavior to users. The question was intentionally vague leaving much open to interpretation and I pared it down as much as my experience supported: what is unique in the data, what are the time constraints, what about false negatives/positives, caching, backend structure, and so on. In the end I just came to the conclusion that I could not provide the design details that they were looking for and said so. This took about fifteen minutes and they did not seem too discouraged with my ultimate conclusion.

The second question was direct and significantly less open-ended - this is the part that really threw me for a loop. The question was this: 'Solve the following expression using any language you want'.

(((1+3)*7)+((((3-1)/(1+3))*8)))

Me: "Use eval in ruby or python"
Them: "Good. You can't use eval"
Me: "I'm not too familiar, but a Lisp interpreter?"
Them: ... confused, unexpected looks ...
Me: "Nah, that is incorrect Lisp format, never mind"
Them: "Yeah, that's not exactly proper Lisp format. What else?"

I asked if the expression would always be balanced and that we only had to deal with binary operators. The answer was yes on both counts so I started drawing stacks on the whiteboard roughing out what would work. Eventually, I presented the following Ruby solution:

$ops = []
$vars = []

OPS = ['(', ')', '+', '-', '/', '*']

def push_op op
    $ops.push op
    if op == ')'
        $ops.pop
        v2 = $vars.pop
        v1 = $vars.pop
        op = $ops.pop
        v = eval("#{v1} #{op} #{v2}")
        $vars.push v
        $ops.pop
    end
end 

def push_var v
    $vars.push v
end

$stdin.gets.chomp.split(//).each do |c|
    if OPS.include? c
        push_op c
    else 
        push_var c
    end
end
 
puts $vars.pop

(the eval part was agreed to be hand-waving for a more complex case statement)

The immediate reply was: "Nope. You've missed a fundamental flaw for this class of equations". So I went back and did the entire equation by hand and realized that the solution would not support the unary operation of (). That is, something like ((1+2)) would end up with my solution popping from an empty stack. So, I injected the fix and claimed that the problem was solved for balanced and valid equations. Here is the fix.

def push_op op
    $ops.push op
    if op == ')'
        $ops.pop
        if $ops[-1] == '('
            $ops.pop
            return
        end
        v2 = $vars.pop
        v1 = $vars.pop

Again, the reply was that I was missing the real fundamental problem with this type of equation. I asked if this particular solution exhibited the flaw they were talking about and they claimed it did. I was stuck at that point and ultimately left the interview with the sense that I failed some basic understanding of mathematical equations. When I got home, I typed up my solution and ran the input they provided and the output was exactly as I had expected (the same as an eval call). I wrote my follow-up email to the company thanking them for the interview but I also attached my script with sample run indicating that I stood by my solution from that afternoon.

What do you think... did I missing something obvious or were they looking for my ability to stand my ground when I had the best solution? They never conceded that I actually had the correct answer; in fact, they indicated that I should take it home and consider what I was missing.

So, yeah. I'm still a bit off-balance from that experience.

Wednesday, December 15, 2010

The Moment of Trust

I was recently propositioned by Bloomberg with a lead engineering position.  Truth be told I really didn’t do anything in particular to precipitate this event; I just got a keyword match on my online resume. This means, of course, that I did not deal with Bloomberg directly at first but through their hired recruiting firm. 

This firm was a little different than those I have dealt with in the past; they were hired directly and had a specific process for weeding out candidates before they ever got to the Bloomberg campus. The claim by the recruiting firm was that the hiring process was so strenuous that most people would fold without preparation. My interpretation was that Bloomberg is big enough to not want to waste time with unqualified applicants.

In either case, the process with this agency was fairly drawn out. There was an initial phone screen; then an extended session where I did some live coding online; and finally there was a detailed technical phone interview. Most of the initial portion (the first two sessions) dealt with my knowledge of C++ topics and how well I wrote optimized production code on-the-fly (because that is relevant). The final screen dove into logic problems, questions with dynamic rules, and the like. The reasoning offered to me was that Bloomberg’s interview process was modeled on that of Microsoft and Google and I could expect these types of things.

Ultimately, I passed these stages and was set for the actual Bloomberg interview. According to the recruiting firm Bloomberg only interviewed as long as the found it relevant which meant I would know quick if there would be no offer since they would just show me the door with thanks. Specifically, I was told that less than 2 hours was not good and 3 to 4 hours meant I’d made it the full way through.

The interview process was set up to incrementally increase in difficulty. It started with what would be fellow engineers asking pointed technical questions and progressed to middle-management asking design questions and more vague logic questions. Then, upper-management asked questions about how I deal with conflict and people management related stuff. The process climaxed with me meeting the director of operations and discussing the role I’d play and compensation. All told, I was in the facility for more than 5 hours. Things had gone well.

My wife was ecstatic. After all, it was her idea to consider the opportunity in the first place. In addition to that nugget, there was a significant amount of money on the table – I stood to make more than 150% of my current salary. After talking with the recruiting firm on the phone they assured me that Bloomberg had been in contact and that they would be preparing an offer.

I took the long way home from that interview. I ran over the good points and bad points and how I could have done better – I don’t think I’ll ever be satisfied with the progress I make.  When I got home, my wife and I had a long talk about what I would gain and lose by accepting an offer and I decided to write the recruiting firm and tell them to convey my thanks to Bloomberg but that I would not be accepting any offer.

In that decision, and my wife’s reaction to it, I knew that I’d found true happiness. I asked her what she thought about my decision and – with everything we stood to lose – she said: “I trust you.”