Interviews: The Factory Pattern

After a recent failed job interview, it happens--even for someone like me who never has a problem getting the next job, I've been refreshing my understanding of the basics. This is always one of the struggles of interviewing, when working day-to-day, year-to-year at a job, the "interview vocabulary" is not fresh in your mind.  Even though you might be working with factories, types, and encapsulation on a regular basis, you aren't talking about it, you are doing it.  One of the values I see in doing this blog, being more active on twitter, and hopefully finding other outlets like StackOverflow and local user groups, I can be more ready for ad hoc interviews, and not just the end of job interviews that I have to time to prep for.

Now the actual feedback I received from the interviewers was not that I didn't ready have good answers to the technical questions, but that I was defensive about (or with) my answers. Unfortunately, given the situation, I was not able to get follow-up feedback on what that meant.  So although I don't have details to report on this aspect yet, I do have a plan for working on my natural tendency of being defensive in stressful situations.

Rant: God, do I hate group interviews! As an introvert, give me eight one-on-one's in a row, take up four to five hours of my day, but do make me sit in a room with two managers, an architect, and three developers.  Ugh!  I've never gotten those jobs, but ALWAYS get the job where I do a series of one-on-one interviews.

One of the question and answers that stand out to me, was the one on the factory pattern. When asked about it, I basically gave that standard descriptor: the factory pattern is a construction, a creation, pattern.  I went into little to no detail, and drew a blank after I said I used them on my latest project. After leaving the interview I remember the awesome factory I create for creating Excel Reports. <sigh>

We had a dozen different individual Excel reports that needed to be generated.  All the reports had the same styles, header, and footer.  But the data being displayed in each report was quite different. So I created a a shared interface and a factory for generating the different Excel reports.

What's interesting to me, and this was something I did based on my gut, and not a reasoned approach, is that after several refactorings I moved from the factory pattern to the facade pattern. It would be an interesting an assignment for myself to re-approach my Excel code and see if I would make the same decisions to move to the facade pattern.  I know the primary thought I had when making the facade was that I did it during my last week on my job when my team members were on vacation.  The choice I had was to make the code as readable as possible or to write documentation.  I am a developer, so I of course chose rewriting my code.  :-)

In an earlier post, I recommend Derek Banas' YouTube series on Design Patterns. Based on what I just wrote I am going to re-watch Derek's videos on the factory pattern and the facade pattern.