Howardism Musings from my Awakening Dementia
My collected thoughts flamed by hubris
Home PageSend Comment
Request For Feedback

Come on, you old fart. What advice would you give to the kids coming out of the university?


Excellent advice. The willingness to say "I don't know" is very important, and something I look for in all candidates!

—Duncan Ellis

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:
Click here to submit this page to Stumble It