After sharing so many of your interview stories, I thought it was finally time that I’d share a couple of my own…
Back in the .NET 1.0 days, I interviewed for a contract position at a certain large insurance company around here. It was a technical interview with two senior-level developers. After I finished answering a softball question about how Try-Catch blocks work, one of the interviewers followed up with a question about Finally blocks.
“A Finally is placed after a Try or Try-Catch block,” I answered, “and will execute, in most circumstances, regardless of any executions that occ–”
“Actually,” the interviewer interrupted, “code within a Finally block is guaranteed to execute.”
“Err,” I replied, “yes – but, there are some situations that cause that code to not be—”
“Nope,” the other interviewer quipped, “that’s the whole point of Finally blocks!”
“Well,” I tried to explain further, “not always. A simple example is a stack overflow exception, but it can happen other times, especially in multi-threaded appli—”
“Alex,” the interviewer sternly jumped in, “read the documentation. You’re wrong here.”
“Okay… but, let’s say something catastrophic happens, like the process is terminated.”
“Uh-uh,” he smirked, “actually, the CLR handles that through process marshalling. Can we move on now?”
“All right,” I sighed. As tempting as it was to ask him to describe the just-made-up concept of process marshaling, I decided to concede. And just at that moment, I thought of the perfect rebuttal. “But what if you just, say, pull the plug? A Finally block won’t execute when the computer is turned off!”
I expected the developers to jump back and chastise me for an “unreasonable scenario.” But instead, their faces turned bright white. They slowly turned to look at each other. It was clear that they made the same mistake that many before them had made: believing Try-Finally to be as infallible as things like database transactions.
“And… umm…” I said slowly, breaking the awkward silence, “that’s why… you should… never put critical… business transaction code in finally blocks.”
The interview ended shortly after that. They did end up offering me the job, but I decided to pursue another opportunity.
The “Qualified” Candidate
Several years back, I was responsible for interviewing all of the “qualified” candidates that had applied for an opening in my group. “Qualified” was the status given by human resources and indicated that an individual had applied for the position in the “open application” period, had been pre-screened by an HR generalist, and had all of the “minimum qualifications” as set forth in the job description. For the opening, we had a total of one “qualified” candidate. Her name was Min.
Min’s resume looked fairly decent, aside from a few minor typos (DCMO instead of DCOM, Visual Basics 6, etc) and a few minor impossibilities (Oracle T-SQL and Microsoft Solaris). I had seen far worse and figured, with the language barrier and all, I’d give her the benefit of the doubt.
“I see on your résumé that you were a VB6 programmer at your last job,” I asked in the interview, “can you give me an idea of your day-to-day?”
“Mostly,” Min replied, “I tested, and make sure our program did not crash.”
“Oh,” I said, “so, like unit-testing with VB?”
“Actually,” she clarified, “I did not use VB. Just our program. But, program was written in VB.”
It didn’t take me too long after that to figure out that Min had never actually used Visual Basic. Or C++. Or, really, any other programming language.
“Min,” I questioned, “why would put all these skills and technologies on your résumé if you’ve never used them?”
“I figure,” she responded, “I would get interview this way. Then, maybe, job.”
Human Resources was a bit peeved that my group was so “picky” with our candidates ad rejected all of the qualified candidates (read: one) that they had sent over. After a bit of cajoling, they opened the position back up for applications.
A couple months later, on a visit to a meeting in an entirely different department, I ran into Min again. Apparently, she had been hired as a VB programmer for another group.