DevDisasters

How To Say the Right Things at a Developer Job Interview

In a DevDisasters reversal, Dave's meticulous attention to detail that points out the numerous issues in code that made it to a production system was enough to earn him a role at the company.

• By Mark Bowytz
• 07/09/2015

After waiting anxiously for a week, Dave finally pulled into the Annex Corp. visitor lot bright and early Monday morning, a full half hour ahead of his scheduled interview. He felt completely ready to take on whatever challenges the interviewers would send his way, head on.

Oh yes. It was going to be a good day.

Dave was granted a mysterious "Vendor" badge by the security clerk, and was then ushered to a representative from HR who reviewed with him a listing of the day's interview schedule and launched into a lecture about basic background of the company, its history and vision, spoken in a tone that sounded like she had given the same spiel to every candidate who walked through her door.

First up was a meeting with someone who would be his team lead and his boss. The conversation wasn't terribly technical -- mostly just exchanging war stories of past software projects and what went wrong and right. It felt almost too easy, (unless he said the wrong thing by mistake) but in the end, it was a good warm up for his next round, where his technical prowess would be challenged.

In the next conference room on his list, Dave introduced himself to a senior developer in the group and another developer with whom he would be working at the same level. Following some general chatting, the senior guy pulled out a single sheet of paper with code on it.

"Heh. So, we're going to try something a little different. Here's a piece of code that we happened to have around that we figured would be great to cover in an interview," he chuckled, waving the printout before sliding it across the table.

"Yeah. The background here is that this one somehow slipped right by the normal testing and made it into production, resulting in some embarrassment," the other developer piped up. "Your job is to find the bug and get it fixed ASAP."

"Now, we won't count it against you if you can't find it. Just have fun with it. We just want to see how your thought processes work."

Dave had read about this sort of thing. Some of the meaner "Alpha Nerd" interviewers used this as a tactic to prove how much smarter they were than the interviewee. Were these guys that type?

"OK, I'll do my best," Dave confidently replied before taking the paper and digging into the code:

public Exception SendEmail(People Sender, People Recipient, string Subject, string Template) 
{
  try 
  {
    // Tack on the .txt extension if it's not there.
    if (Template.EndsWith(".txt") == false) Template += ".txt";

    string Body = File.ReadAllText(@Template); //locate the template 
    
    MailMessage msg = new MailMessage();
    msg.From = Sender.WorkEmail;
    msg.Subject = Subject;
    msg.To = Recipient.HomeEmail;

    Regex reg = new Regex("\u0023\u0023[a-zA-Z]+\u0023\u0023); //##SomeWord##

    foreach (string word in Body.Split(' '))
    {
      Match match = reg.Match(word);
      
      switch (match.Value.Replace("##", "").ToLower()) 
      {
        case "user":
          Body = Body.Replace("##user##", Recipient.UserName);
          break;
        case "pass":
          Body = Body.Replace("##pass##", Recipient.Password);
          break;
        case "FirstName":
          Body = Body.Replace("##firstname##", Recipient.FirstName);
          break;
        case "LastName":
          Body = Body.Replace("##lastname##", Recipient.LastName);
          break;
      }
    }
     
    msg.Body = Body;

    SmtpMail.SmtpServer = Settings["SmtpServer"];
    SmtpMail.Send(msg);
  } 
  catch (Exception ex) 
  {
    return ex;
  }
  return null;
}

After a tenuous minute that felt like an hour, Dave took a deep breath and started into his reply:

"Well, what first caught my eye was the fact that it returns an Exception ... instead of, you know, just throwing them when necessary, and the function is of the type Exception. And …"

"Also, the approach at regex matching looks a little weird, too. It reads in the template word by word, evaluating each one it comes across for a special variable. Could be a performance hit if you have a lot of really large templates. And … um …"

"Oh, the template doesn't have a path attached to it, so any malicious someone could use this to potentially read and e-mail any .txt file on the server! And …"

Dave paused, glanced up at his interviewers, and they didn't look how he expected. Were they perplexed? Annoyed? Obviously he didn't give the answer that they were expecting. He gave the code another read-through.

"Aha! Right there in the switch part of the code. The tags it's looking for in the template are all in lower case. The cases for first and last names in the switch are all mixed case!" Dave proudly exclaimed, "Yeah. It'll never ever match and the e-mails will all have variables."

Dave looked up from the page and noticed that the less senior developer had excused himself during his last explanation. The senior developer thanked Dave for his "excellent analysis" and retrieved the code sheet. A few questions later and Dave was off to meet his next interviewer.

A week later, Dave was extended an offer, which he accepted. Settled in to his new job, Dave was chatting up the developer who had excused himself during the interview and asked him what the heck was going on that day.

"Yeah, sorry about that," he replied sheepishly. "Turns out that was production code. You were supposed to point out the mixed case bug in the switch statement and the exception part that I had just fixed."

"What I didn't realize, though, was the path issue. We had a security audit coming up and, well, they look for stuff like that. Oh, hey, I didn't get a chance to say thanks for pointing out the regex bit. I mean pattern matching isn't my strong suit."

Dave nodded in appreciation.

"So, now that you're familiar with the code, Dave, how are your regex skills?"