When you go on a job interview for a programming job, what are some of the scenarios you may be asked to mock up on a chalk or dry-erase board?
This is a question for interview givers and former interviewees alike.
I am a senior systems analyst for a mega-corp who does lots of interviewing. My interviewing style to to allow absolutely no BS on either side. We just talk and the interview goes where it goes. I will ask for clarification if something is too vague or if it seems an applicant is exaggerating or outright lying.
Afterwards, we give a written test that is so open ended that it is almost ridiculous yet it is very effective. We deal with many very large databases so much of it is about SQL. Applicants can answer the questions in any version of SQL that they want regardless if it is Microsoft products, Oracle, or others. The questions are very easy on their face but more in depth answers help. Answers can even be written in English if they want and syntax is mostly ignored.
We test for CONCEPTS with the idea being that anyone can whip out a manual to find proper syntax and weird tricks aren’t that transferable. I am the one who “grades” these tests for a group of about 500 people. I put that in quotes because there is no answer key or minimum score. It is just based on my impressions of mastery which are very generous on their own. After all of those allowances, the failure rate is above 80% and this is for people that claim database mastery and ten years of experience. It is shocking really. We give them every chance to pass and want them to and many can’t even explain the basics of how a join works.
That said, I have probably gone to about 100 interviews myself over the years and there is absolutely no standard whatsoever - none. Some may be interested in how well your interpersonal skills will fit into the organization. Others will lock you in a room with a complicated 50 question test covering many areas with a strict answer key and a proctor that is more robot than a person.
Just do your best and remember that you are interviewing them as much as they are interviewing you. Companies have very different personalities just like people do and any given one may be a terrible fit for you while others are perfect for you.
I’ve probably had a couple dozen programming interviews in my life. They were all different. Some asked about language-specific details. One gave a domain-specific problem. One gave some simple C programs to write. Some were most interested in my prior work history. Some asked about my inconsistent marks. Some of asked more touchy-feely-type questions(Tell me about a situation in which you did not handle a workplace conflict well). One asked general problem-solving questions(what features would be required to completely automate airplane flight and eliminate pilots?)
I’m not sure how much you can do to prepare for an interview if you don’t know what kind of things they’re looking for. Be prepared to do some quick thinking.
Thanks guys. I’m just paranoid that they’re going to be asking me very syntax specific questions and asking me about concepts that I’ve never dealt with before.
This is good advice, and it’s the mindset that I’ve been trying to adopt to psych myself up. This is my first real interview, though I’ve done plenty for co-op positions as part of the Drexel coursework. But those co-op interviews never really grilled me on anything technical as I know this upcoming interview probably will.
I tend to be a nervous wreck with this kind of stuff, so I’m hoping that the whole “I’m interviewing them” mindset will help calm me down and give me a sense (even if it’s a false sense) of dominance. An air of “I don’t really need this job, prove to me that this is where I should be.”
The thing I always tell people who ask for my assistance is imagine when you are being asked the question that it is some less skilled co-worker asking you the question. They aren’t asking because** they** know the answer they are asking you because you know the answer and they want help. So politely and cheerfully help them, explain what they need to know.
It is the right kind of “zen” and stops people using the cocky “I don’t care” philosophy that plays really poorly in interviews.
I think this is more appropriate for IMHO than GQ.
Colibri
General Questions Moderator
I’m sure you’ve heard this and don’t really believe it, but: if they do that, you probably don’t want to work for them anyway.
I’ve only done a half-dozen interviews, but the ones that I bombed on… it would have been a really bad fit. The company I work for has a very difficult test (both written and coded), but the written test is abstract logic/data structures, and you’re provided with language references for the coding test. The point should be to see if you can think and are familiar with how to structure a working program, not to trip you up on technicalities.
We used to ask programmers to write a function in C to reverse a string. We wanted to see how they thought about the problem, how well they knew C, and how well they understood how to optimize speed vs. memory. It was surprising the number of programmers who didn’t know squat about anything other than Windows APIs.
I would expect one of two types of coding questions:
-
You are asked to do an easy task that anyone could do in order to prove you can program. Example: “Write a function to reverse a linked list.” In these, it’s important that you go slow and scrutinize everything as if it’s going to be compiled and run when you’re done and getting the job depends on you not leaking memory, having a logic error, or blowing up because of an uninitialized variable. You should step back and look at the code and actually make a mental test pass on it to make sure it’s going to work. Then say, “yeah, I think that works.”
-
You are asked to do a harder problem which may be challenging because it’s underspecified (checking to see if you ask the right clarifying questions), open-ended (checking to see if you make an appropriate stab at solving the problem to a point and discussing how it could have gone further), really tricky (making sure you’re smart and know how to solve hard problems), or maybe testing knowledge of a particular area (e.g. a question specific to an area of graphics in which you claim knowledge). Example of the open-ended variety: “Write a wiki.” These are less about the actual code you write and more about the approach you take to solving the problem.
When I’m asked a coding question in an interview, I try to quickly decide which of these it is. If it’s so easy I’m thinking, “there must be a trick…nobody could possibly not know how to do this,” then it’s probably just a question from category 1, so I go into meticulous mode and whip out a solution. If it seems like something I don’t have time to write completely, it’s probably going to fall in bucket 2, but I’ll give it a good long think as a category 1 problem because on occasion, there are really hard sounding problems that turn out to be an astoundingly small amount of code, and they really do expect you to write them to completion. For problems that end up being in category 2, I start sketching out the pseudocode and break the problem down into appropriately-sized chunks which I can then fill in with real code. I save myself time with statements like, “I’ll assume I don’t have to reinvent X, and that I have an X library with an API like <this>”, so long as X is something reasonable; you don’t want them thinking you’re just trying to get out of solving the problem. Some interviewers will let you break the problem down into chunks and then pick one of the chunks and have you do a thorough implementation of just that portion (in which case it’s reduced to a category 1 problem).
Hope that helps.
Been a software engineer for 25+ years now, and been on both sides of many interviews. I think the thing that most inteviewers are looking for when they ask programming questions is mainly “is this guy BSing, or has he really had experience programming ?” That is, a lot of people can claim to be “programmers”, but may have only done minor mods to someone else’s code - more maintenance stuff. So the questions that I’ve been asked have tended to be really basic kinds of things: linked lists is a common one (inserting nodes, deleting nodes, etc.), and for some reason, character array manipulation seems to come up a bit as well (parsing a string for another string, etc.). I think I was asked to do a binary search once.
So they’re looking for familiarity with some basic programming tools - stuff that anyone who has done programming has probably come across at some point (be it in school, or work).
The other thing, as has already been mentioned, is that they want to see how you think (if you can) on your feet. So it is not important to get each line correct. But as you think through the solution, if you realize you made an error on an earlier line, that is fine - so long as you recognize it and go back and correct it.
If anything, exact syntax is the last thing on their minds. I’ve done most of my examples in some hybrid pseudo-code. It’s the logic/algorithm that they’re interested in.
As for interviewing (programmers) in general, I have found that communication skills are extremely important. If you think about programming/engineering, communicating requirements, design, whatever is crucial to a successful project. Likewise, being able to communicate YOUR understanding of the requirements, design, whatever is crucial to the project lead knowing that you know what needs to be done. So if you are asked about your school projects or whatnot, it is important to be able to discuss them clearly. They are likely not as interested in the projects per se, but about your ability to describe them.
Lastly, be honest. There are so many aspects of programming out there these days, it is not reasonable to expect that any one knows ALL that a specific job may require. If you have not worked with some technology/language, whatever, just say so. You don’t want to get caught trying to answer questions about something you don’t really know about. What IS important is that you can emphasize your ability to learn new technologies.
Hope this helps.
The people I get have degrees or experience. The ones right out of college I ask for very specific details about projects they claim they have done. I’ve found quite a few who have blown up trivial programming exercises into big deals, or who haven’t really done it. We need people who can work independently, so just knowledge of syntax isn’t nearly enough.
The second question I ask is what their toughest bug was, and how they fixed it. Anyone who claims never to have put a bug in their code is lying. We don’t have close supervision, and I’m a big fan of Weinberg’s egoless programming. I want someone who will cheerfully admit to screwing up, and who knows how to fix it.
I once interviewed for a job that was part Linux systems admin, part programmer. One of my questions was some overcomplicated find scenario (like find all files fitting this regex modified between x and y dates). I didn’t know the exact syntax, so I told them I’d start with “man find”. If you aren’t familiar with Linux, I told them I’d RTFM and figure it out, they loved that answer.