How to study for a programmer job interview exam?

December 28, 2012 11:00 AM

There will be an exam as part of my interview for my first programmer/developer job. It will be on J2EE and PL/SQL. Can anyone advise on what to expect and what to focus my studying on?

I am going to study my ass off for this. The exam will be an hour long and will be multiple choice. I have never seen or taken this sort of 'programming aptitude' exam. In fact, in the program I have just graduated from, we rarely wrote exams; everything was lab-based (so, hands on).

I just took a J2EE course and took an Oracle course the previous semester. But I am worried because my head is jumbled with numerous syntaxes (C#, Objective-C, PHP, various SQL versions). For J2EE we focused on the Hibernate API as well as Spring Framework for a lot of things and I am afraid of mixing stuff up. We didn't do EJB - we did Spring beans.

On the plus side, my school is the preferred one for hiring junior developers and employers in my city are generally very familiar with our curriculum.

In a nutshell, I am worried. Any advice for studying and what kind of questions to expect would be greatly appreciated.

posted by kitcat to Work & Money (7 answers total)

I've never taken a written exam, but I've been quizzed in a lot of tech interviews.

My general advice would be to focus on the simple things. I've almost never been tripped up by failing to know very complex things, but I've lost track of the number of jobs I didn't get because I forgot basic commands or concepts I use every day. (For one embarrassing example, I once couldn't remember that you sort things in SQL by "ORDER BY." Of course I don't do database stuff and the guy was a complete and utter dick about it but I digress.)

What I usually do is print out the wikipedia or other basic reference pages for the languages I'll be tested on, and study the crap out of those. That way I get a refresher in the basics and am less likely to forget under pressure. Since there's no way to know what complicated things they might ask about, there's no use fretting too much over that.

(Your other option is to seek out someone who has taken this test before and ask them what's on it, in a general sense.)
posted by drjimmy11 at 11:15 AM on December 28, 2012

Also keep in mind the questions are just as likely to be about concepts as about writing actual code. For example, "Tell me the difference between a GET and a POST" is a classic that's asked in just about every web developer interview.
posted by drjimmy11 at 11:17 AM on December 28, 2012 [1 favorite]

For most small to medium sized shops, a test like this is just a screening mechanism to qualify someone for a face-to-face interview. As such, it is going to be treated as a pass/fail and the questions will be unambiguous and easy to grade quickly. Think of it as the coding equivalent of a driving test at the DMV. If you know your stuff, it won't be a challenge. Some of the big companies in the tech space (Microsoft, Google, Amazon) are famous for their tests; if the company you are interviewing with is one of those or on par, you'll want to do a more specific search for info on their testing protocol.
posted by kovacs at 12:59 PM on December 28, 2012

The fact that it's multiple choice tells you a lot about what to expect, or at least, it tells you what not to expect. Open-ended questions like "Tell me the difference between GET and POST" obviously won't work in that format, however, a question like:

Choose the preferred method for uploading a file to a web server from a client browser:

A) GET
B) POST
C) PUT
D) FTP

... Could be made out of the open-ended one. I'd make sure you're familiar with the syntax of both Java and SQL and the meanings/uses of all reserved keywords (in other words, you need to know what transient means and when to use it). Familiarize yourself with generics and annotations in Java (since you're fairly new, you probably are used to these versus the older method of casting things, but still). Since they specify J2EE you are going to want to familiarize yourself with its specific APIs and features (among them, JSPs, Servlets and JDBC). You might also expect to see 'read this code snippet now answer these questions' sorts of set-ups, where they give you a chunk of code (and the DB tables it touches) and ask questions about the effect of running the code... for example, given that the DB table EMPLOYEES is in state X, and we execute the lines of code in Y, what is the state afterward (actually, 'which of the following is true about the state afterward')?
posted by axiom at 1:39 PM on December 28, 2012

Response by poster: I should have said this above: the HR person I spoke with said that the test would be used to determine which team I would be placed on. Nevertheless, I imagine that if I blow it I'm not getting the job. Or, I imagine that rocking it could make up for weaknesses in the actual person-to-person interview.
posted by kitcat at 3:08 PM on December 28, 2012

Most of my technical interviews have been with people who know me personally (or know of me from past co-workers) and know the quality of work that I do. These tend to be informal and focus on the specifics of the position.

The few technical interviews I've had outside of those tended to ask lots of general CS 101 questions about asymptotic complexity, bit shifting in C, and other such trivia. As a junior programmer, these are topics you should be prepared to discuss, though senior candidates who aren't planning to do systems programming could reasonably view them as evidence that the interviewer never bothered to read your resume (and thus should apply elsewhere).
posted by tomwheeler at 11:24 PM on December 28, 2012

I am not a programmer, but a friend who is told me that it was important to practice writing out code on a whiteboard.
posted by The corpse in the library at 7:46 AM on December 29, 2012