Advice to the Young Interviewed
For the last couple of weeks, my team has been interviewing candidates for
a junior engineering position. After various people at my company talk to the
candidate, we all get together to discuss our impression. Since interviewing
is not a course most universities offer, I wish could give these young people
a bit of wisdom from a gray beard.
First of all, if you don't get the job, try to contact the hiring manager and
find out why. While they probably won't give you too much detail, it doesn't
hurt to ask, and I always think it is a smart idea to ask for feedback.
On with the tips:
Responding with "I don't know" is perfectly acceptable.
No one knows everything about everything. The interview process is to gauge
not only if you can do the job, but what skills you will need to learn
after hiring.
A candidate doesn't get partial credit in an interview for guessing,
and it often makes him or her appear… well, like he or she is trying
to "snow" the interviewer.
A "trick" (if you can call it that) is to then ask the interviewer the answer.
This shows an interest in learning and in the question.
When an interviewer asks if you know x, it is best not to respond with
"I'm an expert" but to explain how much you know about x, and let the
interviewer determine the "category level".
For when someone claims to be an expert with a technology, and the
interviewer then asks a question that isn't answered, it makes the person
look far worse than if he or she said, "I'm familiar with X as I've used it."
When you are looking at a position, try to be able to talk about and ask
questions about the technologies required. For instance, if the job reqs
state JUnit, then at least hop on Wikipedia or something to get an overview
of it.
Another "interview trick" is to find out the people you will be talking to,
and Google or LinkedIn their names beforehand. You might find out more about
them, their side-projects, and people you may know in common.
This can help in the small talk at the beginning of an interview.
What you may lack in experience, make up with enthusiasm and show how you
are willing and capable of learning. Have a story that demonstrates how you
took the initiative to learn a technology before you needed it.
This week, I also talked to a young man fresh out of college. I was curious as
to what a computer science degree was offering. I'm concurring with
Joel Spolsky about the lack of depth. Seems like you will need to supplement your degree with
a bit of extra learning.
A couple of recommendations for you in your future career in computer science:
Learn about the different ways teams of engineers can develop together.
This includes labels like Agile development and "Waterfall".
Learn about Test Driven Development (TDD). Most of us "old farts" are
becoming believers in this approach, but they don't seem to teach the
advantages at school. Learn about JUnit (or an equivalent) as well as
about Mock Objects (take a look at Mockito) and Selenium.
Learn about the issues surrounding "code completeness" … in other words,
since you can never "prove" some code is perfect (just like you can never
prove a scientific theory), what ways can you come up with to help convince
you (and a QA dept) that the code is trust-worthy or "good enough".
In this regards, look at code coverage tools, continuous integration and
building tools (like Hudson), and the refactoring features in various IDEs.
Pick up a developmental side-project, like an open source project.
This will really help build up your chops like nothing else.
Learn some other languages, and be able to talk about some strengths and
weaknesses, and not just difference in syntax. For instance, you probably
know Java from school, but you should know at least one other functional
language.
Some of these bullet items will lead you to learn about "technologies" that
may be asked about in an interview, but knowing these will help you be a
better developer. Granted, many of my references are Java-oriented, as I'm
assuming that is what you may know best, but the concepts are applicable to
other languages and platforms (yes, there are even multiple unit test frameworks
for verifying your procedures on Postgresql).
Finally, I encourage most young developers (and well, just about everyone)
to learn to communicate effectively. You could combine this suggestion with
the one about open source projects, and help to document something that is
already actively developed (as it seems that the biggest stumbling block with
many open source projects is the dismal quality of the documentation).
Another idea is to start a blog in order to practice writing, because no
one is "good enough" in the realm of communication (you can tell my limited
skills).
Tell others about this article:
