What I need to know for an interview process

[wyrd]

Mr. Nerseus as offered to give advice for interviews and resumes. So, heres the topic..

- What should I know for an interview?
- Whats the Dos and Dont list for Developers?

 

[Nerseus]

Resume Dos (aimed at someone with less experience)

• Include everything you know: languages, technologies, etc. If you leave something off that you even partially know, the person reviewing your resume wont know you know it
• Include any experience you have, even if its not professional
• List details about each job - your duties, tasks, skills used for each, etc.
• List certifications and degrees even if youre only pursuing them (mention that you are going for MCSD for example)
• If youre in college, run your resume by the English Dept. or Librarian (my school had people on staff to critique resumes)
• Dont be afraid to list your fry cook job. Maybe you handled stressful lunch crowds well or had to take over when others didnt show up - these are good qualities, regardless of the type of work
• Try to keep everything on one page. If you have enough experience to warrant two or more pages, then maybe
• If you have work experience, dont list what the company does or what your coworkers did - list what YOU did at the company
• Include all skills, even non-computer skills. For example, if you work well with others, find a way to put that in the resume.

Resume Donts

• Dont use Comic Sans font - use something more professional like Arial, Verdana, Times New Roman, etc.
• Dont list "too" personal data - age, race, religion, favorite hockey team
• Dont include your picture
• Dont include pictures of the tools you use (like MSs VB logo or the MCSD logo)
• Dont list every language, technology, skill that youve ever heard of - youll be asked about them during an interview plus the interviewer is going to KNOW you dont know 8 computer languages proficiently if youre still in school (or even out)

Theres a fine line between including everything you know and including too much. Remember that anything you put on your resume is something that you might get asked about during an interview. If you dont feel at a good comfort level talking about something, you might not want to put it on the resume.

Thats a good start. Dont forget, you can always post your resume here for us to critique. There are also two good websites (probably many more) for preparing for a job: dice.com and monster.com. I always liked dice, aimed more at computer professionals, but I know monster is bigger. They both have good tips on resumes, interviewing, etc. You can also scan through the job postings to see whats available. keep in mind that these arent all the jobs that are out there...

-Nerseus

 

[Nerseus]

Interview Dos

• Dress appropriately (may mean suit and tie, may not). Dont "go casual" simply because its a small company.
• Be prepared to talk about your resume, your jobs, what you did, etc.
• Be prepared to talk about your skills: language specifics, tools used, etc. Some companies may even put you in front of a computer and give you an "assignment"
• Be prepared to talk about your likes/dislikes with languages, tools, previous jobs
• Be prepared to talk about why youre leaving your current job (if you have one)
• Be prepared to talk about your future - where you want to be in a year, 2 years, 5 years
• Be yourself

Interview Donts

• Dont lie - you *will* get caught
• Dont say youve done something you havent, you will get caught
• Dont try and talk about a technology or use a buzzword unless you know what it means. If youre going to say youve developed an n-tier architecture youd better know some specifics
• Dont say you were bitten by a spider and have to go (yes, I had someone tell me that)
• Dont be afraid to say "I dont know" - maybe even a lot. My interview process for people that should be mid to senior level involves some *really* difficult questions. Not everyone has used MSMQ, COM+, Active Directory, etc. but Im going to ask, just to see if someone knows (especially if they list it)

The bottom line, as you can see from the "dont" section, is that you shouldnt over-exagerate what you know. Stick to what you do know and dont be afraid to say you dont know something. If your resume looks like a junior developers then the interviewer isnt going to expect you to know the three normal forms for a database nor how to set up DCOM security for using COM+ across a VPN.

I could make a monster sized list of the stupid things people say during an interview. I could make an even bigger list of the people that say they are experts at something yet cant answer the simplest question. Heres a sample of things that I swear Ive heard in interviews, starting with "spider man":

After asked to clarify something that just didnt sound right, an interviewee asked to end the phone interview as he had "been bit by a spider earlier ans wasnt feeling up to continuing".

Three years later, give or take, the SAME man interviewed again (I was at a different company but still doing interviews for developers) only this time, about 30 minutes in his kids started screaming in the background (he was calling in from home). After hearing him yell quite loud and meanly at his kids, he said he had to go. We asked if he wanted to continue later and he made up some other ludicrous answer (I dont remember because I was waving my arms at my friend pointing out that this was the spider guy).

Here are some things that self-titled experts couldnt answer (I swear Im not making this up):
1. Database expert: Didnt know how to sort records descending
2. Database expert: Didnt know the difference between inner and outer join
3. Database expert: Never heard of normalizing. When told what it was he *argued* against it: "Why not just store the string value, why bother with all those indirect numbers and joins - it slows everything down!". Never argue during an interview...
4. VB6 expert: Had never created a class - UDTs all the way
5. VB6 expert: Didnt know how to write an error handler
6. VB6 expert: Didnt know the difference between ByRef and ByVal
7. VB6 expert: Never created a DLL - one guy didnt know you could
8. ADO expert: Couldnt name the two common objects (Connection, Recordset). We usually prompt with one "one is a connection... whats the one you use to get records from a database? - no answer)
9. ASP expert: Doesnt know what Response or Request is used for.
10. COM+ expert: Didnt know how to use transactions
11. COM+ expert: Didnt know how to install a package into COM+ or export one

My second favorite (next to spider man) was Ukelale boy. He said hed do anything to get his foot in the door, even run around giving us massages, getting us lunch, and playing his Ukelale (quite famous in his native country) - just so he could get some experience. Ah, ukelele boy...

-nerseus

PS Wow, do I ramble when it gets late or what?

 

[Robby]

I wanted to add to this topic but you (Nerseus) covered it real well.

 

[Nerseus]

I should note that Ive always worked for smaller companies and thats where I do my interviewing. Ive done contract work at larger companies but I didnt like it as much. I prefer the smaller groups of experienced people. Its quite possible that some of my tips wont work as well when interviewing for larger companies, especially if they have a more formal Human Resources dept.

-Nerseus

 

[wyrd]

Insane info, thanks a ton. Had a good laugh reading it too.

Theres one part that was particularly helpful because it was a question brewing for some time..

"If you dont feel at a good comfort level talking about something, you might not want to put it on the resume."

The languages I probably would have listed on my resume were; PHP, Java, C++, VB6, VB.NET, C#.NET.

I havent done PHP in ages though and would definitely need to refresh my memory if I were to talk about it. C++ Im still just learning, I can do console stuff but theres a ton I dont know about the STL and I havent even begun to deal with Windows (Win32 or MFC). Once I started learning .NET I basically threw my VB6 knowledge out the door.

Argh, cursed by bad memory I tell you. Unless I work with something every day Ill forget it all within a matter of weeks.

Oh.. btw what about databases Ive worked with? Should I list the ones Ive delt with (ie; MySQL, Access, MS SQL) or just list "SQL" as a language?

 

[Iceplug]

Lovely tutorial, Nerseus. Looks quite a bit similar to the guidelines that they have here at school.

"The resume is the way for you to sell yourself" or some such wording.

 

[Nerseus]

Wyrd, you can include two sections: one for languages/tools/technologies that you know/use often and one for those youre only familiar with (like being able to read and/or tweak existing C++ code). Again, be prepared to talk about what you can do with the "familiar" languages - like youve tweaked code, compiled it, or just read up on it.

-Nerseus

 

[wyrd]

Very good idea. Never really thought about two sections for that.

Thanks again fellas.

 

[Robby]

I have a kind of list of all the languages that I use (in my resume), next to each language I put... Expert, intermediate or beginner.
So even though at one time I was quite proficient in C++, I now put that Im only Intermediate.

Just a thought.

 

[wyrd]

Hmm.. all excellent ideas.

 

[wyrd]

Yeah this thread is ages old.. I know. But I had a question related to the topic;

What sort of programs that Ive made should I include with my resume? I know that quality is better then quantity, but I dont know what kind.

 

[Nerseus]

I assume this is for a game job? Most other jobs (non-game related) probably wont want to see any code youve written (at least, I wouldnt want to look through it).

So if its for a game job, I could only guess theyd want some sample games. Id make sure the code was "clean" - well formatted, good comments, etc. Id avoid anything that might make it look "bad", such as a bunch of global vars, variables named "a" or "p" or such, etc.

Im no expert in applying for a game programming related job, but Id also expect some kind of documentation (at least a one page readme) that explained what the programs were, how to get them setup to compile, and any keypoints worth looking at (techniques used in code, etc.). Be expected to be asked how you did the coding (any design), how long it took, problems you encountered, why you made certain decisions, etc. - or, the normal interview stuff.

-Ner

 

[wyrd]

I was asking about a typical programming job in general.

Example, if Im applying for an internship or junior level job at a software company, what sort of programs would be and would not be appropriate; Database, Web based, Hardware related, Game related, Graphics related, etc.

I can answer the question about game companies; they want to see something amazing that youve done, not necessarily a full game (which in this day and age would take years). If youve programmed some absolutely amazing particle engine that could be used by games, for example. Or perhaps a scene that shows off real-time and realistic terrain morphing like blowing holes in solid walls. Or even some nicely done rag doll physics.

 

[Nerseus]

As I said, for non-game related jobs, I wouldnt expect any code at all. And if I got some, I probably wouldnt spend very long looking at it.

The one time I *did* get source code submitted to me it was filled with expletives (F* this and S* that). He was a senior in college and claimed to have written it earlier that year and was quite proud of his liberal use of comments. We didnt hire him.

-Nerseus

 

[wyrd]

I wasnt talking about source code, but actual programs that youve built. Good info though about why not to include source code.

 

[quahog]

I have never developed games professionally or otherwise, so these are just general observations.

(Item 3 would work for game developers)
******************************************
From my experience, interviewers look for:

(1) relational databases of scale: Oracle not Access/sql server rather foxpro. (On the resume)

(2) types of applications, for example I specialized in medical applications. (on the resume but explained in the interview)
- I worked for 3 differant government agencies doing medical related applications. When an interviewer looked at my resume, they knew my learning curve was smaller than a developer who worked in the financial field.

(3) depth of experience. Are you a coder or did you work in all phases of the SDLC (explained mostly in the interview)

 

[Nerseus]

Well if youre going to distribute an application (or rather, if I as an interviewer were going to receive an application) I would definitely want the source and not the executable. First, I dont know that Id trust a potential candidate to write clean enough code that Id want on my machine (or maybe (s)hes just being malicious). Second, I hate installing just to uninstall something a bit later (too much clutter - Im a neat freak sometimes - more of an issue with COM+ and registry settings). And third, Id rather see the source so I could see what kind of code you write.

The main reason we dont look at source code from prospective employees is that a small program wouldnt show much about what you could do and a large program would be too hard to sift through. Also, there arent many developers who write large apps by themself and you cant tell from code who coded what. Too often I get resumes with people that claim to know a whole lot but who, in reality, know the average amount but worked with some guy that knows the real stuff.

Now if I were interviewing a candidate for a web job, thats different. Then we like to see websites that theyve done (if they have them available for public viewing). Ive had less than 5 interviews with people that had websites publicly available though - most cant show them because they rely on a database thats currently in use and behind firewalls, etc.

-Nerseus

 

[wyrd]

Hmm.. thats interesting. From what Ive read it sounded like employers would want to see what youve done. I especially assumed this because someone who knows how to talk the programming lingo (ie; what sql, ado.net, a .net assembly, manifest, reflection, etc. is) doesnt necessarily mean they know how to program, it just means theyre good at memorizing definitions from a book.

Then again, 99% of the research Ive done on the job market has been towards a game programming job, and they want to see what youve done. In the gaming industry dedication is the key, and by sending in work that youve done helps show that youre serious about entering the gaming industry and also shows some of your capabilities.

Unfortunately I dont have the skills for such a job and was thinking about an internship somewhere with a software company. Since Im a student, landing an internship shouldnt be to hard (assuming I can find a company that takes internships where I live).

Also, not to sound argumentative (probably to late at this point), but why would you not want to see someones code (crappy or otherwise)? If their code is sloppy then you may not want to hire them. Id think that itd be a good way to see what sort of programming habits they have (ie; do they use a nice form of OOP or is everything a global variable?). And Id image whether or not they send you in their own code or someone elses is just as much of a risk as them lying during an interview.

 

[quahog]

Most companies would tech interview you. They would either give you a test or have you grilled by one of their techs.

Showing them code or a web page that you created is great but how do they know that you created it? They are going to tech interview you.

If you do not have a long list of technobabble on your resume, do not worry. Your resume will not get you a good job. It should just get you in the door. If your are savvy enough to answer a good portion of the technical questions, you have a good shot at the job.

Good luck.

(Wyrd, it does not sound like you need to go for an internship. I have worked with many developers who got hired despite not knowing what a query was).