Comment by thejo | Hacker News Reader

Comment by thejo | Hacker News Reader

These are very basic, but here goes -

* Most interviewers, especially at big companies, don't take the time to read a resume in detail. Also, it is usually difficult to access websites if all they have is a hard copy of your resume. Make it easy for the interviewer to access your work during the interview. Use a URL shortener and have links ready to - your online resume with links, rich info (images, charts) about your work etc. It helps to be prepared if the interviewer brings along a laptop. Talking someone through your work when they are looking at it is always better than just talking about it.

* Research the company before the interview. It's always a red flag if a candidate doesn't have any questions about the company they are about to work for. The more you can show the interviewer that you've done your homework, the more likely they are to consider you seriously.

* If possible, learn more about your interviewer before the interview. Google and LinkedIn are your friends. It helps to have some context.

All the best!

The first point really shows an employer that actually cares. To be honest, out of all the places I have interviewed, there was only one instance of being questioned about the specifics of an open source project; it was for a QA position, and actually just a Pick-from-List kind of question. Oddly enough, not too many of them seem interested in actual code I can show them.

The second point, I think, deserves some more discussion.

There's no denying it: I consistently fail at coming up with questions to ask when an interview nears its end. Although I do try and ask small questions along the way, after the whole thing is done, there's just nothing else I care to know about that's appropriate at this stage in the process. In terms of work environment, if it was interesting enough to talk about, the interviewer would have already given me a spiel or the topic comes up naturally. The actual work gets discussed in some detail regardless, so there's not much else there without actually working on it. Having some opinions about the product in question would be nice, but no such luck there either: they've all been doesn't-exist-yet, enterprise apps, and generally things the general public doesn't have enough access to to be able to have an informed opinion about. That said, if the other side cooperates, I generally try and make the interview into more of a conversation, and seem to leave a very positive impression on the interviewer. Doesn't really help with the having-a-question-to-ask at the end, though.

What sort of questions do you really hope a keener would ask?

Here are some of my standbys, if I'm stuck:

* What would you consider the average size of a working team, here? (You'd be surprised- sometimes the answer is '1', sometimes it is '50', and the discussion this generates is usually worthwhile. )

* What kind of kid buys Armor Hot Dogs? (Fat kids. Skinny kids. Kids who climb on rocks. )

* (to a developer) Tell me about what _YOU_ do. Could you describe your day-to-day routine to me? (It's open-ended, and certain answers, like 'rock back-and-forth, in the corner, in the fetal position, cradling a rifle' or 'ASP.NET programming' are sure signs that you might want to stay clear. Good answers include 'something different every day' and 'sneaking into homes to steal pens'.)

* What would you imagine that I would be doing, here? ("Mopping.")

* What are your opinions and policies on ongoing education, here? Do you have resources? Do employees attend conferences? (Some companies will laugh you out of the office, and/or point at their tiny 'reference shelf', many others support this sort of initiative. It's best to gauge this before you ask the question.)

* Try to identify things that your interviewers seem especially proud of, and ask them about those things - even if you already know the answer, they will be happy to talk about them. (Say, for example, the HR person repeatedly mentions the innovative "80/20" policy. Despite that you know what an 80/20 policy is, like the back of your freaking hand... ask questions about it, to show interest. )

* Who, exactly, put the ram in the ramma-lamma-ding dong?

* What sort of source control do you use? (This is seriously important. You might get stuck using something vile like CVS or SourceSafe. On top of that, asking this question demonstrates that you are aware of the importance of source control, a point that you could always drive home.)

A couple of more-precise but ultimately not-that-useful technical questions can help, too. If a company is doing web technology, ask them what sort of hosting arrangement that they have, whether or not they have a dedicated sysadmin, whether or not they have a development/production split, how changes get moved from development to production, if they do code reviews, what development methodology they prefer, etcetera, etcetera.

And you must always, always blow on the pie. I mean, ask at least one question. You must always ask at least one question.

Safer communities together.

Asking for a tour is always good(Not just the spot where you'll be working). You can pick up a lot of things from looking around. Coffee quality and the state of the server room are two particularly important areas to look at.

Comparing where any execs are working to where the devs are working is also pretty useful for getting a pretty good idea of how power relations work.

On the first point, you have to remember that the larger a company grows, the more impersonal it becomes. Interviewing in most large companies is usually seen as a chore, the outcome of which does not have a huge impact on the interviewer. This is different in a startup, where hiring someone may significantly impact your own work. Of course, if the interview is conducted as though it is a chore, then it just sucks and you have to start thinking about how badly you need the job.

On questions, you can always ask about -

* the team you'll be joining

* if it's a small company / startup ask about their business and competition. An engineer who shows that he understands how his work fits into the larger picture is far more valuable than one who is happy to just write code.

* learning opportunities - large company or small, dig into what it is you can take away from the job

Of course, there's no point in making it a formality. What would you like to know about something you might be doing for the next few years of your life?

Reply on news.ycombinator.com