Software Engineering Communication
by Curtis Krauskopf
Many communication-type questions don't have a specific "right" or "wrong" answer. Almost any reasonable answer will be acceptable as long as it answers the question.
Q1) What was your biggest development screw-up? What insight did you learn from that?
A1) A "wrong" answer to this question would be "I really haven't had any screw-ups -- all of my projects are done perfectly all of the time". If your projects really are like that, then contact me so I can hire you. For the rest of us, we can point out at least one project that could have been done better or wasn't delivered on-time or on-budget.
This question can become a trap for you when you start bad-mouthing a previous employer or your current or ex-coworkers. Keep the criticism self-centered and about how you contributed to the problem. Starting your answer with a sheepish grin (if you can manage that) can disarm the interviewer and give you a little more time to construct your answer.
Even though we would like to forget our screw-ups, it's important to have them ready for an explanation when we're asked about them. This shows that you care about the projects you've worked on, that you try to improve yourself by learning from your past mistakes and that you watch for signs of repeating previous problems. Ending your explanation by explaining all three of these things turns the response from being a low-point in the interview into a high-point -- where your abilities are shown to shine.
Q2) Explain the internet to a young child.
A2) The Internet is a way that computers can talk to each other.
I think the key to this question is keeping the explanation and vocabulary very simple.
Q3) Explain a database to your grandparents.
A3) A database stores information in the same way that a phone book stores information. When you want to search for somebody's phone number, you can easily find it because all of the names are in alphabetical order. Similarly, in a database, all the information is organized in ways that make it easy to find. Unlike a phone book, though, most databases allow new information to be added, old information to be deleted, and changes to be made to existing data.
Using an analogy for this question is appropriate because of the audience.
I picked a phone book because its features are well-understood by everybody.
Q4) Explain how you learn a new computer language.
A4) Just about any reasonable explanation could go here. Some people learn by example. Others learn by reading the definition and rules of the language. Your answer should probably cover how you use small test programs to try features before using them in a real program (you do that, don't you?).
The way I learn a language is to read the language's specification and see how it's similar to one of the languages I already know. I usually buy two books: one that gives the language's definition and a second that shows examples. Using sample programs, I write small test programs to test out features of the language. Then I'll intentionally create problems in those small programs to see how the compiler reacts or how the program blows up at runtime. What happens if a semi-colon is missing? What happens if I use a reserved word for a variable name?
Q5) What C++-related magazines or websites do you read on a regular basis?
A5) Since you're reading this article, you probably
read websites that discuss C++ programming!
Some websites that discuss C++ programming issues are:
Q6) Have you ever worked on an open-source project? If you have worked on one, what were the most difficult issues? If you were to work on one, what would you foresee as being some of the difficult issues?
A6) One of the purposes of this question is to discover
if you've ever worked in a team environment and how
well you work on that team. Sometimes, large projects
are distributed amongst teams of programmers that interact
remotely. Your experience on large open-source projects
will help you integrate into the company's distributed
culture.
A recent slashdot.org
article asked readers nearly the same question.
The consensus opinions were to:
- Find a project you're interested in.
- Read the TODO list or find something that is broken or needs to be improved.
- Read the discussion message boards and learn the acronyms and terminology that are unique to the project.
- Communicate with the core developers to let them know you're interested in volunteering for the project.
- Code and test and retest your solution before delivering it.
- Deliver your project when you promised to deliver it. This shows that you are reliable and you'll be trusted with larger (and more interesting) assignments.
- Don't take it personally if the core developers seem elitist or cliquish. Many open-source projects are run by developers with poor people-skills. If you find one of those projects, don't try to change them or even bother pointing out their behavior. Just move on to another open-source project. There are so many well-run open-source projects that there is inevitably a project that you would enjoy working on.
Q7) What are the three most recent languages you've learned and why did you learn them?
This is another question with no right or wrong answers. Just tell it truthfully without embellishing your answer. A typical follow-up to the question is "How long ago did you learn them?".
The interviewer is looking for your ability to adapt to modern programming conventions and to stay abreast of the industry's technology. The interviewer also wants to know if you're a naturally curious person. Even though it might seem nerdy to a non-professional, learning a language just for the sake of learning it does have merits. If the only language you know is C++, then every problem looks like it can only be solved with C++. Having a variety of languages under your belt (and that you stay current with) shows that you're flexible, well-rounded and professional.
|
