What I need to know for an interview process

[wyrd]

Mr. Nerseus as offered to give advice for interviews and resumes. So, here's the topic.. :cool:

 

- What should I know for an interview?

- What's the Do's and Don't list for Developers?

[Nerseus]

Resume Do's (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 won't know you know it
  
• Include any experience you have, even if it's not professional
  
• List details about each job - your duties, tasks, skills used for each, etc.
  
• List certifications and degrees even if you're only pursuing them (mention that you are going for MCSD for example)
  
• If you're in college, run your resume by the English Dept. or Librarian (my school had people on staff to critique resumes)
  
• Don't be afraid to list your fry cook job. Maybe you handled stressful lunch crowds well or had to take over when others didn't 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, don't 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 Don'ts

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

 

There's 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 don't feel at a good comfort level talking about something, you might not want to put it on the resume.

 

That's a good start. Don't 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 what's available. keep in mind that these aren't all the jobs that are out there...

 

-Nerseus

[Nerseus]

Interview Do's

• Dress appropriately (may mean suit and tie, may not). Don't "go casual" simply because it's 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 you're 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 Don'ts

• Don't lie - you *will* get caught
  
• Don't say you've done something you haven't, you will get caught
  
• Don't try and talk about a technology or use a buzzword unless you know what it means. If you're going to say you've developed an n-tier architecture you'd better know some specifics
  
• Don't say you were bitten by a spider and have to go (yes, I had someone tell me that)
  
• Don't be afraid to say "I don't 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 I'm going to ask, just to see if someone knows (especially if they list it)
  

 

The bottom line, as you can see from the "don't" section, is that you shouldn't over-exagerate what you know. Stick to what you do know and don't be afraid to say you don't know something. If your resume looks like a junior developers then the interviewer isn't 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 can't answer the simplest question. Here's a sample of things that I swear I've heard in interviews, starting with "spider man":

 

After asked to clarify something that just didn't sound right, an interviewee asked to end the phone interview as he had "been bit by a spider earlier ans wasn't 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 don't 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 couldn't answer (I swear I'm not making this up):

1. Database expert: Didn't know how to sort records descending

2. Database expert: Didn't 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: Didn't know how to write an error handler

6. VB6 expert: Didn't know the difference between ByRef and ByVal

7. VB6 expert: Never created a DLL - one guy didn't know you could

8. ADO expert: Couldn't name the two common objects (Connection, Recordset). We usually prompt with one "one is a connection... what's the one you use to get records from a database? - no answer)

9. ASP expert: Doesn't know what Response or Request is used for.

10. COM+ expert: Didn't know how to use transactions

11. COM+ expert: Didn't know how to install a package into COM+ or export one

 

My second favorite (next to spider man) was Ukelale boy. He said he'd 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 I've always worked for smaller companies and that's where I do my interviewing. I've done contract work at larger companies but I didn't like it as much. I prefer the smaller groups of experienced people. It's quite possible that some of my tips won't work as well when interviewing for larger companies, especially if they have a more formal Human Resources dept.

 

-Nerseus

[wyrd]

:eek:

 

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

 

There's one part that was particularly helpful because it was a question brewing for some time..

 

"If you don't 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 haven't done PHP in ages though and would definitely need to refresh my memory if I were to talk about it. C++ I'm still just learning, I can do console stuff but there's a ton I don't know about the STL and I haven't 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 I'll forget it all within a matter of weeks. :(

 

Oh.. btw what about databases I've worked with? Should I list the ones I've 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 you're 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 you've 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 I'm only Intermediate.

 

Just a thought.

[wyrd]

Hmm.. all excellent ideas. :cool:

[wyrd]

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

 

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

[Nerseus]

I assume this is for a game job? Most other jobs (non-game related) probably won't want to see any code you've written (at least, I wouldn't want to look through it).

 

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

 

I'm no expert in applying for a game programming related job, but I'd 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 I'm 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 you've done, not necessarily a full game (which in this day and age would take years). If you've 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 wouldn't expect any code at all. And if I got some, I probably wouldn't 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 didn't hire him.

 

-Nerseus

[wyrd]

I wasn't talking about source code, but actual programs that you've 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 you're 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 don't know that I'd trust a potential candidate to write clean enough code that I'd want on my machine (or maybe (s)he's just being malicious). Second, I hate installing just to uninstall something a bit later (too much clutter - I'm a neat freak sometimes - more of an issue with COM+ and registry settings). And third, I'd rather see the source so I could see what kind of code you write.

 

The main reason we don't look at source code from prospective employees is that a small program wouldn't show much about what you could do and a large program would be too hard to sift through. Also, there aren't many developers who write large apps by themself and you can't 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, that's different. Then we like to see website's that they've done (if they have them available for public viewing). I've had less than 5 interviews with people that had websites publicly available though - most can't show them because they rely on a database that's currently in use and behind firewalls, etc.

 

-Nerseus

[wyrd]

Hmm.. that's interesting. From what I've read it sounded like employers would want to see what you've 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) doesn't necessarily mean they know how to program, it just means they're good at memorizing definitions from a book.

 

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

 

Unfortunately I don't have the skills for such a job and was thinking about an internship somewhere with a software company. Since I'm a student, landing an internship shouldn't 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. I'd think that it'd 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 I'd 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).

[wyrd]

Why would I not go for an internship? :( I have 0 experience in the real world, everything I know is self taught or learned from school.

[quahog]

Go for both. You have to start somewhere.

 

There are ups and downs with both

 

Many companies like people with little formal experience but are technically knowledgeable, because they can pay them less.

 

On the other hand, internships are great but many companies would not let interns get near a pc to write code. Why would they? If the intern writes something good, the intern is gone in 3 months. Someone else would have to pick up the code. Many internships that I have seen are great if you want to know how to file and copy.

 

But internships can work out well also. You may get new skills/experience/ and contacts.

 

Either way, good luck.

[quahog]

If the internship does not workout:

 

If you want experience, go to your local church/ synogue / temples / fire station / VFW / union / political party or candidate, etc... and see if they need some application. Do it for the experience, if you get paid good. If you do not get paid ask if you could donate your work (get a tax write-off and a professional reference)

 

Example:

Volunteer Fire departments have to report on the number of fires that their members attend. In Maryland, many fire stations record this in a notebook. If anything happens to the notebook....Their members recieve a pension if they attend enough fires, so this is very important. They tally this up by hand but pushing a button for a report is easier.

 

You would end up with full life cycle development experience and something for your resume. Keep the rights to whatever you sell and you can resell it.

[wyrd]

On the other hand, internships are great but many companies would not let interns get near a pc to write code. Why would they? If the intern writes something good, the intern is gone in 3 months. Someone else would have to pick up the code. Many internships that I have seen are great if you want to know how to file and copy.

 

That's not how the interships I've looked into have been explained to me (and I've asked people who work there). For example, the Livermore Lab (government work) assigns a worker to you who gives you work to do, but a lot of time to do it. The worker assigned to you is also there to help you with any questions that you have. Unfortunately it's also been explained that getting interships there is very hard.

 

If an internship does not provide me with an opportunity to gain real world experience, then I simply wouldn't bother with it. A little investigation before applying for an internship usually gives me a pretty good idea whether or not it'd be worth applying there.

 

It could be different in your area, but that's just not how it works with the companies I've looked into.

[Nerseus]

From what I remember, getting internships in general was pretty hard. They were limited, and so many programmers wanted them. I have no idea whether an internship normally leads to a permanent job after college. I know it works that way in other professions, but I have no experience with it in computers.

 

Having said that, we have just hired 3 part time developers from the local university. One is a student (graduates in December and will come on full time), the other two are teaching assistants and may or may not come on full time when they graduate. We hired the student because we wanted a junior guy and he was very good. He told his teachers about us since we're one of the few C# shops in town and they were interested and also very good.

 

As for learning real world experience from an internship, take note of where you do your internship versus where you might want to work one day. Smaller companies tend to be a little looser on design and documentation while large companies, especially government jobs, tend to put a lot of emphasis on design and documentation (and other procedures). My first job was the former and while I learned a LOT about VB I didn't learn much about working on larger projects the *right* way. It's one of the reasons I left actually, though I wasn't sure what was missing at the time.

 

-Ner