No Open Blockers

One of the biggest points I try to hammer home with my students is to take advantage of the fact that I’m a full-time developer and have been since college. I have a different (and let me be clear: not better, not worse) perspective on things than some of the other professors at Villanova and I think it’s important to take as many of these perspectives into account while students have access to them. I’ve extended this to not only my own students (both past and present) but any other students I’ve encountered in my various guest lectures, colloquium, and simple time spent in the computer science labs.

One of the students I met that falls into the last category e-mailed me and asked if I would proofread his resume. I ended up throwing out some random tips on interviews and resumes at the end that I figured should probably be shared more globally. I’ve interviewed a number of people at various jobs, including a streak at Gestalt where I was interviewing around 2 a week for a few months, so while I don’t claim to be an expert I can at least say what I’ve looked for in the past.

Be interested in what you do. If you’re doing this for a paycheck, it shows. If you’re genuinely a computer geek and really have fun doing this stuff, it shows. An interview for a tech position is not the time to worry about the social implications of having compiled your own kernel. Setting up a MythTV box at home isn’t a good pick up line at a bar (trust me, I’ve tried), but it shows a lot of initiative and interest in a tech interview.

Don’t be afraid to admit what you don’t know. It’s much better to say “I don’t have any experience with that yet” than to stumble around making up an answer. The interviewer will know the answer already, so don’t think you’re going to fool her. You’ll just look like an ass when she runs back to the rest of her coworkers and tells them the absolute crap you tried to pass off as an answer. And if it was a really off the wall answer, expect to be the butt of jokes on that team for months to come, even if you don’t get the job.

Along the same lines, don’t be afraid to admit something you did that didn’t work. Bad decisions are inevitable. Being able to recognize and admit it was a bad decision shows you’re not too proud or full of yourself to not see the bigger picture. Just make sure you can justify the decision in the first place. You made the call for some reason, and hopefully at the time it sounded like a good one, so explain what that reason was.

Find out what you’re in for. In other words, ask questions. I know, this sounds like pretty generic advice. It’s especially tricky for your first job when you don’t really know what you’re asking. But you can still get a sense of how organized the team is. If the interviewer can’t give you a solid explanation of how the release process works, there’s a solid chance the team is run like a beer pong tournament. Sure, they are interviewing you to make you an offer on a position, but in reality you are also interviewing them to determine if you want to work there.

Be very careful with the buzzwords on your resume. There is a very tricky balance between the buzzwords necessary to get an HR employee who doesn’t know what they are doing to be interested in your resume and having so many buzzwords that the interviewer immediately thinks you are full of shit. My general rule of thumb is that less buzzwords are better than poorly chosen ones. I fully admit that I walk into giving an interview expecting to be much more harsh when I see the applicant claims MVC as a skill (lately, the abuse of the term SOA is my new call to arms).

Be very careful with the skills on your resume. Executing a select query against an Oracle database one time does not entitle you to say you are skilled in Oracle. Along the same lines, playing World of Warcraft and visiting Facebook does not qualify you as a Windows expert. If your job experience doesn’t mention a skill in your skills list, be prepared to justify yourself.

Proofread your resume. Seeing as it’s the de facto professional representation of yourself, it’s assumed you’ve looked over it a thousand times and are 100% happy with it. With that in mind, a typo speaks a lot about your professionalism, polish, and general care you put into projects.

Some interviewers are just assholes. They may throw stupid brainteasers at you thinking it will make or break the interview. It happens. Don’t get dejected, it might not be that you were bad so much as that the interviewer is poor at giving interviews.

AnandTech reviewed the Intel Core i7, the newest in Intel’s lineup.

In particular, the memory architecture strikes me as interesting:

“With a three-channel DDR3 memory controller, Nehalem requires the use of three DDR3 modules to achieve peak bandwidth – which also means that the memory manufacturers are going to be selling special 3-channel DDR3 kits made specifically for Nehalem. Motherboard makers will be doing one of two things to implement Nehalem’s three-channel memory interface on boards; you’ll either see boards with four DIMM slots or boards with six.”

The number 3 just strikes me as unnatural in computers. With the 32-bit memory limitation of less than 4GB, I’m curious if we’ll see a lot of packages that ship either 3 x 1GB or 6 x 512MB modules, which would fit nicely as 3GB total. The other possibility is that we’ll see a rise in the popularity of 64-bit operating systems to support the rather natural 6 x 1GB orientation, making 6GB the norm for more powerful computers.

Read the rest of the article here.