Stupid Human Programming
Talk on software development.








Subscribe to "Stupid Human Programming" in Radio UserLand.

Click to see the XML version of this web page.

Click here to send an email to the editor of this weblog.


Saturday, May 15, 2004
 

Thoughts On Interview Questions, the Process, and Resumes

Given that i and few other people i know will be interviewing a bit more now :-) I've
put together an interview related wiki page at http://www.possibility.com/epowiki/Wiki.jsp?page=InterviewQuestions.
It covers C++ and general programmin interview questions. It also has some thoughts on some issues
companies should consider when interviewing and some issues interview candidates
should think about during the interview and when making their resume.

Here's a bit of it.

Thoughts For The Company Doing The Interviewing


* Know the kind of person you want, the skills they should have, and design your interview process accordingly.
* Do pre-interview phone interviews. This can save a lot of time for both parties if there is an obvious lack of a match.
* Do you really have an open slot with money for it? Interviewing is a ton of work. It sucks to go through the entire process and the find out there really wasn't any money.
* Decide who gets to decide if a person is hired. Is the manager going to hire who they want no matter what? Then don't bother with interviews. Does it have to be unanimous? Is it majority rules?
* Every person in an interview should have a defined subject area. Have people know what they are supposed to ask and don't overlap questions.
* Is someone a friend of the interviewee? If so don't have them interview the person. Make sure that the friendship doesn't influence others when making the decision.
* People lie. Make people answer a wide variety of questions. Have them read code. Have them write code. Have them demonstrate specific knowledge. Have them demonstrate detailed knowledge. Do not accept generalities or diversions.
* People lie. Have someone verify that what is on the resume is true. People will say they know C++ but can't describe a destructor!
* Check references.
* Be able to tell a candidate what job they are being hired for.
* Have a post-interview meeting where all interviewers discuss the candidate. Often people in a group will come to a different conclusion than if you ask them individually.
* If people know their role in the interview then there's no need for a pre-interview meeting. It can usually be handled by email.
* Make sure the candidate knows when and where the interview is. Make sure they have a contact phone number and directions.
* Make sure someone is there to meet the candidate when they arrive.
* Make sure everyone knows when they are supposed to interview and indicate they they will be there on time.
* Have alternate interviewers in case someone has an emergency.
* Have interviewers talk to each other during the interview process so they can indicate if any areas should be covered specially. Often someone will feel they didn't cover an area well enough or has an idea the candidate may not be being honest.
* Make sure someone walks the candidate out and they know the process of notification.
* Consider stopping an interview cycle early if the candidate is clearly a mismatch. Some companies don't give the candidate an interview schedule so they can stop the interview process without the candidate getting offended.
* Have people from different backgrounds and groups on the interview team.
* Make sure the meeting is room big enough and has any equipment needed for the interview.
* Have an agreement on how the handoff between interviewers is handled. Should the next interviewer expect a call? Should the next interviewer show up at the scheduled time?
* Is the candidate staying through lunch? Is the candidate going to go out to lunch with several team members? You can work this in as part of the interview. Or have them just go hungry.
* Have your HR department have a class so everyone knows what is legal in an interview.
* Consider a group interview where everyone interviews that candidate at once. These can be economical from a time perspective and allow for group interaction.
* If you can, have a computer where the candidate can enter and type in code. A real programmer won't have a problem with this. Be happy if they ask about source code control, nightly builds, release policies, etc.

Thoughts For The Candidate Being Interviewed


General Thoughts

* Remember, you are interviewing the company as well.
* Hiring someone is risky. People are afraid of making the wrong decision. Any little thing will get you into the "it's safer to say no" bin. You need to make everyone think that you won't be a bad hire, that you will help the project, that you won't cause problems, that your are reliable, and that you will make everyone look good.
* Know your stuff. Most people aren't very good so you can really shine by appearing like you know something and that you could possibly be a decent person to work with.
* You can not "win" in an interview. Don't challenge the alpha personalities. Many people are insecure and don't want to hire somone who is better than they are. You must present yourself as competent, yet at the same time as not a threat to existing team members.
* Ask each interviewer how they like the company and project. How they answer is probably more important than what they say.
* Are the interviewers the kind of people you would like to work with? The fun of working anywhere is working with good people.
* How organized is the company in the interview process? A bad interview process may mean nothing or it may mean everything. It's just another fact to enter into your calculations.
* Ask for a tour of the plant. Is this the type of place you want to work? Is it all cubes? All offices? Are the cubes big or small? Do they have tall or short walls? Do they have doors? Are there enough conference rooms? Is everyone spread-out or close together? Do they have free soda and coffee? Are the bathrooms clean? Are the managers with the people or separate? Is development done in multiple sites?
* Are they able to tell you what job you are being hired for?
* Can you figure out if the project you are being attached to is in trouble?
* Ask about group turnover.
* Ask how they develop software? What is their process? What are their tools? Is all of this ok with you? DO they laugh and say there isn't a process? Is the process you working like a dog to make up for everyone elses mistakes? Do they have the hero culture where the idiot who stays all week is the hero but the people who do their job well are ignored? Does management just manage or do they handle all high level technical issues as well?
* Is the project and company heading a direction that you like?
* Is the amount of travel ok with you?
* Are the hours ok with you?
* Are the working conditions ok with you?
* Is the technology/tools/environment ok with you?
* What is their policy for working late and weekends? Why do they need to work so much? (if they do)
* Try and determine their need. This will help in negotiations.
* Keep in mind that negotiation happens after the interview and is usually conducted with HR. Don't talk about money or benifits with your potential team members.
* Negotiate! You need to get the best deal for you. A lot of people don't like to negotiate and leave money on the table.
* Don't lie on your resume.
* Show up on time.
* Ask to go to the bathroom and get a drink. This will show you people in their environment and give you a better look at their facilities.
* Read your resume before the interview and be able to explain everything on it.
* Study the interview questions in [General Programming Interview Questions]. It seems people are reusing many of the same questions so you'll sound much smarter if you practice.
* Consider bringing in a portfolio of your work.

In the Interview

* Show you are a team player.
* Show you are smart and can get things done.
* Show how you will solve their problems and won't be a bad choice.
* Don't try to show you are smarter than everyone else.
* Don't be argumentative. Show you have your own thoughts and opinions, but show you can work with other people without being an asshole.
* Try and find out what they are looking for and change your answers accordingly.
* Do not talk bad about any other company or person.
* Have a reason for leaving your previous jobs that doesn't paint you as a bitter revengeful person.
* Be warm and friendly.
* Smile. Laugh. Don't be too stressed, no matter how bad you want it.
* Communicate clearly. Don't speak down into the table. Don't mumble. Don't giggle. Speak in complete sentences. Complete your thoughts. Don't cover your mouth with your hand. Don't interrupt the interviewer.
* Give thoughtful answers. Don't speak without thinking.
* Don't make the interviewer work too hard. Volunteer information, but don't talk too much
* Ask the interviewer questions.
* In the US, make eye contact and have a firm handshake.
* Do not saying something sucks without first determining if that is the interviewer's most favorite thing in the world.
* Dress appropriately, get a hair cut, shower, have clean clothes, show you are normal.
* Think about the questions being asked. Get to the real intent. Do they really care about why a manhole is round or are they trying to see how you think?
* Remember you can be wrong. Keep an open mind. Don't be dogmatic. Keep your religious opinions on subjects to yourself. Otherwise you will be showing you won't be able to along with other people and they you'll make everyone's life hell on every little silly issue.

On your Resume

* Be buzzword compliant. People scanning your resume need to see the proper buzzwords.
* I think an objective section is useless and takes up valuable space in the first part of your resume.
* Assume people don't read your resume. People are busy so they may not read your resume until just before the interview or even during the interview.
* The first section under your name and education (if present) should be your "Experience Highlights" section. This should be all someone needs to read of your resume to know if they should hire you. Make your resume as long as you want, but assume only the first half of the first page will ever be read.
* Describe the technologies you have used on each project. Don't just describe the project.
* Describe what you have done on a project. Don't go into endless details about a project, especially if you didn't do everything.
* Frame yourself as someone who can get stuff done, learns quickly, can solve problems, works with people well, works alone well, and won't be a problem.
* Include no personal information. Nobody cares and it can only be used as a negative.
* Include things like patents, publications and awards.
* Write every item like a news paper article. Put the most important information first, that which they care about and shows you off. They probably won't read past the first line in a block of text.


comment[]

10:26:49 AM    



Click here to visit the Radio UserLand website. © Copyright 2006 todd hoff.
Last update: 7/11/2006; 12:56:09 PM.
May 2004
Sun Mon Tue Wed Thu Fri Sat
            1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31          
Apr   Jul