• Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
    Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.

Entry Level Coding Interview Tips

D

Deinos

Gawd
Joined
Aug 25, 2011
Messages
556
Hello all. I am a Computer Science Major that is almost done with school. I am starting to prepare for the dreaded technical/coding interview. I have been reading a lot of tips from places such as Hacker News, etc., and I have to admit that I am feeling a little "inadequate." I see all of these interview tips and sample q's from Amazon and Google, and it made me wonder, "Do I have the chops? Am I just over-analyzing this and interviews at "regular" companies won't be as difficult? How are software dev interviews at non-software focused corporations (e.g. enterprise dev at companies like State Farm, large retail chains, etc.)?"

So, long story short, what are the experiences of veterans on the board? Do you have any tips or good resources for the first time tech interview?

Thanks in advance!
 
How confident are you? One of the main qualities they're looking for is being able to talk to other people and hold a conversation (but you will rarely see this as a prerequisite).

As you're going through your exams, I take it you're pretty good at writing down code with a pen and paper - so that works in your favour!

What projects have you worked on, have you done any internships, is any of your code on the web? As you're going after your first job your can't fall back on previous experiences/ references. So you need to push the projects you've worked, your favourite projects/ the aspects you most enjoyed.

Design patterns and version control are very much in fashion right now (I'm not even going to mention the A word). If you haven't covered these in Uni make sure you read of them.

Also, by having a CS degree. That puts you ahead of the crowd. You should be fine.
 
There was a thread here where mikeblas posted a bunch of good stuff.... really good stuff.

Perhaps he will post a link to it :D
 
people who conduct interviews actually ask for people to write code on paper? Never had to do that.

I say, if you can go in confident thats half the battle. If you have interships or stuff to show, then you only help yourself out even more.

Be excited also.
 
Bigbacon said:
people who conduct interviews actually ask for people to write code on paper? Never had to do that.

I say, if you can go in confident thats half the battle. If you have interships or stuff to show, then you only help yourself out even more.

Be excited also.
Click to expand...

I've had two paper interviews, one interview where I wrote code on a white board and one where I wrote code over a online meeting system.
 
I just graduated with a CS degree this past December. One book that might help is:

Programming Interviews Exposed - Secrets to Landing Your Next Job

I have the 2nd edition. This book is so worth it.
 
Practice doing some interview problems from books/blogs

Talk out loud while you're working the problems out, as if people were in the room with you
 
Some general thoughts...
- Talk with your professors about the upcoming interview, and see what suggestions they may have. Some schools offer interview training sessions; does yours?
- Get to know the company you are interviewing with. Learn about their history, line of business, head counts, etc. Show that you are genuinely interested in the job.
- Work through some problems in a coding cookbook. The refresher will help, and you will likely learn something new.
- Take some practice questions and have a colleague in Comp Sci or MIS ask them to you. Try answering live, and have the colleague critique your answers -- both for correctness (ie: technical level, scope) and clarity (ie: presentation, proper grammar).

Good luck!
 
5 years as a software engineer and I've interviewed people:
I want to know how you think. I want to know that you understand how to tackle problems. Anyone can program. If you're writing highly coupled code I don't want to talk to you.

If you want to work for a Google, MS, or Apple, be ready to derive sorting algorithms. Be ready to discuss software engineering models. I prefer the pair programming model.
 
To be honest, I've had several programming interviews and I've never had to write code. Now, I think that it would be a good idea to make a programmer write code in an interview. But, if I interview another person and ask him to write code I'll make it pretty easy just to demonstrate he has some clue what he is doing. We interviewed one guy who I asked a series of increasingly easier programming questions. I don't remember them all, but I do remember he couldn't tell me the difference between a linked list and an array, or what a thread was, or in the language he listed himself as expert, c++, how to free allocated memory (huge problems).

Anyway, If I were you I would study some basic questions, quiz yourself, make sure you can write that stupid fizzbang etc. and just make sure you aren't too nervous. I don't believe that you will definitely have to write code in an interview, but you should be prepared for it.
 
aL Mac said:
To be honest, I've had several programming interviews and I've never had to write code.
Click to expand...
Where did you interview? Which companies are hiring someone for a specific skill, but not having that candidate demonstrate that skill?

aL Mac said:
I don't remember them all, but I do remember he couldn't tell me the difference between a linked list and an array, or what a thread was, or in the language he listed himself as expert, c++, how to free allocated memory (huge problems).
Click to expand...
It would be a lot cheaper for you (and your company) to detect this during the screening process.

aL Mac said:
make sure you can write that stupid fizzbang etc.
Click to expand...
Writing code is only part of the problem. Discussing it, identifying how long it takes to run, and explaining how it might be made to run faster are also open topics. Software engineering (when done thoroughly) also has other activities: discuss how the code be documented and tested, for example.
 
Interview style varies by company. I'll give you my personal opinion, and what the general attitude of my company is.

1.) You're straight out of school. YOU KNOW NOTHING! Don't try to act smart, or overreach in your knowledge. Instead showcase your willingness to learn, and interest in solving problems. Make sure to have a good answer for "Why you like programming?".

2.) Never say you like this tech over that tech, or this language over that language, or "I don't do database". Be humble and open. Just say you're not familiar or don't have experience with it, but wouldn't mind learning. Companies aren't looking for what you know, they're looking to see what they can teach you.

3.) Side projects will give you a major major boost. Even if they're simple, meaningless things. They showcase your desire to learn more, outside of what's required by your school. Reinforces on 1.)

4.) Make sure you're familiar with major developer portals like GitHub, StackOverflow, and other good tech sites. Coming to [H] was a good start.

General people tips:

5.) Be normal. Don't mention weird hobbies, or other eccentricities. Developer teams are very tight groups of people and they have to be convinced you can blend in.

6.) Don't act overly casual. A lot of dev teams are casual, and your interviewer might give off a very friendly relaxed vibe. Don't let your guard down and say foolish inappropriate things. Always maintain a professional demeanor.

But again the main thing is 1.) They know you're inexperienced, and they will be gauging you more on your interest and ability to learn, rather than previous knowledge.
 
Thanks for all of the advice so far. I think spending too much time on Hacker News, etc. started to freak me out. I feel like I know my stuff well enough, but was feeling really inferior reading some posts, etc. I started to feel like everyone was being judged like they had a million projects sitting on GitHub and went to MIT. I am overly self critical as it is, so that didn't help :)
 
Mike,

It's a small company, we've interviewed a total of three guys since I started. This particular case was about 2-3 months after I started and I don't think that any of the software guys had approved his resume or anything before the interview was setup and I was straight out of college. They simply asked us to come "ask him some programming questions". So we did, and he failed miserably.. Now I know better at least, the interview was very uncomfortable for him, but I guess I don't feel too bad because his resume was completely bogus.

Nowadays, if we were looking to hire someone new I believe things would be much different. They'd most likely run all the applicants by us and we'd be able to screen them out and like I said before, I'd ask them to write something at least.

Last, I've interviewed with maybe 5 companies in my life but none of them asked me to write any code. The company I work for now did ask me to discuss various technologies but the interviewers weren't software engineers. My wife writes software too and I don't think she has had to write code in an interview before. Do not misunderstand me though, I would expect to be asked to write and discuss code in an interview, but I've not seen that happen.
 
The biggest piece of advice I can give any entry-level coder for interviews is to show genuine interest in your craft

This means you should be somewhat passionate about software solutions or technologies. You should have a side-project of some sort. You should be interested in producing code and what makes good and bad code.
 
Deinos said:
I feel like I know my stuff well enough, but was feeling really inferior reading some posts, etc
Click to expand...
You'll want to do what you can to get over this. It can be tough, but in any large field, there's going to people who know stuff you don't know and can do things you can't do. In a healthy environment, everyone understands that and can explain and teach and exchange information to help. But there's just as much obligation on you to be receptive and helpful.
aL Mac said:
Last, I've interviewed with maybe 5 companies in my life but none of them asked me to write any code. The company I work for now did ask me to discuss various technologies but the interviewers weren't software engineers. My wife writes software too and I don't think she has had to write code in an interview before. Do not misunderstand me though, I would expect to be asked to write and discuss code in an interview, but I've not seen that happen.
Click to expand...

Are you interviewing at companies that are tech companies, or companies that run businesses in other sectors but host some engineers for internal systems and websites and so on? I suppose they might be more prone to making this mistake if they're not used to interviewing for engineering positions, even though they'd probably think nothing of it for other skilled technical positions.
 
I haven't worked or interviewed with a software-focused company. The company I currently work for is more of an embedded electronics company. Our software runs the devices and the devices' user interfaces. We also have some applications to support the devices for regular computers. They see themselves as more of a hardware company, i.e. the software is free as long as you buy the hardware. But, they are getting more involved with software, there's really no way they can avoid it in my opinion. There is already a lot of software involved in their products, probably a lot more than hardware.

Considering the other places I've worked or interviewed with, software was used for exactly what you said: Internal systems, some engineers, etc. Most of them had an engineering department, but were not a software company. Actually I forgot about two interviews. One of them did consulting/contracting, software for machine controls in manufacturing. The other was a defense and aerospace company out of Huntsville.

But anyway, I guess what I'm trying to say is this:

How are software dev interviews at non-software focused corporations (e.g. enterprise dev at companies like State Farm, large retail chains, etc.)?"
Click to expand...

Don't be surprised if you do not have to write any code in this style of interview, but of course always be prepared. Companies like this may be likely to ask typical HR questions. They will probably have someone from an engineering or software department ask you technical questions and interview you about your skills. If you apply for Google, Microsoft, Facebook, game development, or some software focused company, I'd fully expect to get asked to code during an interview.
 
I wouldn't want to work (as a programmer) for any place that hired people but didn't have any kind of coding tests or have programming as part of the interview.
 
robvas said:
I wouldn't want to work (as a programmer) for any place that hired people but didn't have any kind of coding tests or have programming as part of the interview.
Click to expand...

That's understandable. Nevertheless, it is possible that they would have good people. It can also be a great opportunity for you to help them improve their software engineering.
 
My number 1 tip: turn off your computer and take a problem, then write the solution from beginning to end, narrating out loud what assumptions you're making and your thought process. Writing code on paper feels (and is) completely different than typing into a text editor (even notepad or a forum window).
 
Much of this advice has (and many of these opinions have) been mentioned previously but for what it is worth...

1. Side Projects

Side projects show off your love for what you do and make you far more attractive as a candidate, even if you have had previous work experience in the field. Side projects also add to your programming and design experience, as well as help to keep your skills sharp and current.

If you do not currently work on any side projects, find a problem close to you which is calling out for a solution and write new code to solve it. The problem can be anything. You can write a combat log parser for a video game you play which aggregates data, performs analysis, and presents the results in a browser. Or you can see if one of the sites you frequent features a public API and write some code against it. The subject does not matter (so long as it is work appropriate), but make sure that your code is interesting and showcases a thought process.

Also, said code should be available online to your interviewers. If possible, get your interviewers links to hosted code samples as early as possible. If your only contact is an HR representative, send him or her the links and s/he will be sure to pass them along. (One other note, only send samples to those persons you have been invited to contact. HR is, of course, generally always fair game.) This way, not only will you lend credibility to your resume, but you will also provide the interviewer(s) with a direction or directions for questions and discussions which will often result in your favor.

Lastly, new code is generally better than old code, and I would advise against offering up anything written as part of your schoolwork. In my experience academic code is usually sloppy versus any code you write in your free time, and generally speaking, you are constantly growing as a programmer, so your newest code is often your best code. Some exceptions can be made, of course, such as if you have a piece of code from your past which is particularly interesting. Just be aware that you may not own the rights to make public any code written as part of your education or written with the use of school resources.

2. Practice

Practice writing code and working out problems outside of an IDE. Some employers will want the hand-written code to compile without errors and other more extreme examples, but this piece of advice isn't about that. When interviewing in person, the interviewer may think up a question on the fly in response to something which was said, and s/he will not always have a spare computer for you to use. It is very common for the interviewer to flip over a piece of paper and ask for you to write some code and/or work out a problem.

Practice writing code and working out problems on a whiteboard with a friend (or friends, even better!) asking questions.

3. General Suggestions and Observations

You can generally expect 1-2 phone interviews, and at least one of these will be a technical phone interview. In person interviewing is expensive and time consuming, and these phone interviews exist to thin the heard. Generally (but not always) the technical side of these interviews will be definition based and answerable using a textbook or an online search. This next part may differ depending on your interviewer, but with me, I hate it when people look up answers as I ask questions. Don't do this, please. We can tell if you do.

There is a lot of stuff that any programmer should know by heart, and if you happen to have forgotten something, say so, and then offer to work out an answer. Also, we know what stuff should be known by heart and what stuff can safely be looked up as needed. Ideally you should know everything, but if you do not, that's OK. Just be honest.

This holds true for in person interviews as well. If this is your first position, we do not expect you to have a one hundred percent correct answer for every question. What we do expect from you, however, is a capability to be flexible and learn on the job. At the entry level we are looking for persons we can mold into productive employees. Most new employees I have worked with take six months or longer to be fully productive.

So what should you do if you do not know the answer to a question? Say so. A good interviewer will then try to help you to a solution. Take advantage of this, and be open about your thought process as you work towards the solution. Just be mindful of the interviewer's body language and prodding and be sure to be ready to go with the flow if the interviewer wishes to move on.

And if you think that you are right and the interviewer is wrong, do not fight the interviewer. Instead, ask to offer up your solution.

4. Be Professional

a. Be mindful of what you can and cannot say when interviewing; stick to topics relevant to the position at hand.
b. Be mindful of and respect the clock, but do not fidget and look at the clock every minute, etc..
c. Dress the part, and when in doubt, wearing a suit is safer than going without, etc..
d. Be respectful of the interviewers, receptionist, etc..
e. Everything you do and say during an interview can be held against you or in your favor. Taken out to lunch? That's an interview, too.

5. Resume

Be honest about your experience. Maybe you have known C++ or Java since middle school. OK, but in all likelihood you are still nowhere close to mastering the language. You are fresh out of school, and chances are that you know far less than you think you know. Programming languages are full of minutia and oddities, many of which are never discovered until code you are working on is doing something seriously strange and unexpected.

Try to avoid listing every language, program, and skill you have been exposed to. Focus on your strengths, and if you must list 10 different languages, do not list them as proficiencies; they are familiarities. Also keep in mind that you are fresh out of school, and unless you have a PHD or perhaps a master's, your resume should never go over a single page. Space is at a premium. Use it wisely. Listing 10 different languages in place of detailing experience in the stuff you really do know well is not a good plan.

This last bit of advice is a bit of a personal red flag for me...
You are not a DBA, and in general be careful about how you rate yourself in regards to anything in SQL land and storage technologies in general.
 
Last edited:
You should know the fundamentals. Most people have touched upon it already. Knowing about certain problems or techniques are less likely to help you in my experience than having a solid understanding of the fundamentals (mathematics, algorithms, data structures, computer architecture, etc).

What I would like to tell you is that they're not the only ones doing interviews. You should be asking your potential future employers a lot of questions. Try to get a feel for what kind of environment they have and the kinds of people that work there. It's likely to be your only chance to get to know them before actually working for them. You don't want to end up working with a bunch of people who don't know what they're doing or the environment isn't conducive to doing great work and learning from great people.

Be vary wary of people who don't take their software seriously. I did the interview loop at quite a handful of companies, including some very large tech companies, and there's a huge difference between those who build software as their core business and those who simply need a few people to develop some internal house software. A few of the places I interviewed at were asking all the wrong questions. Some of them offered me a job, but I was never going to work at a shop like that. The questions were basically trivial or not very relevant to the task they were looking to hire for.

The places that offered me a job and I wanted to work for, those guys all had some very intelligent people and during the interview, they asked me interesting and challenging questions. If you don't feel during the interview like these are people you'd love to work with or get asked questions that are simply too easy, then you probably shouldn't work for (with?) them.

Edit: Let me also add that if they don't ask you to code at all, don't work for them. If their hiring standards are that low, they're not worth it.
 
Ask them some questions:

The Joel Test

Do you use source control?
Can you make a build in one step?
Do you make daily builds?
Do you have a bug database?
Do you fix bugs before writing new code?
Do you have an up-to-date schedule?
Do you have a spec?
Do programmers have quiet working conditions?
Do you use the best tools money can buy?
Do you have testers?
Do new candidates write code during their interview?
Do you do hallway usability testing?
 
( Just making sure that the OP doesn't take an uncited reference out of context... )

robvas said:
Ask them some questions:

The Joel Test
Click to expand...
Joel's article is very good, and is worth reading. But the OP needs to weigh some factors against that blanket statement:
- The context of Joel's article,
- Whether you are interviewing with a software company (ie: established team) or as an alternative to shotgunning contractors, and
- Acknowledge that very few shops can pass all factors of the Joel Test.

You may pass on an job opportunity based on your view/preference of the company, but you don't want to come off as rude during an interview. Higher-ups talk.
 
Last edited:
I've seen the Joel test and most of them are great things to ask, but some of them don't apply in every situation.

edit: I guess this one seems to be the least important to me if you work on a small team

"Do you make daily builds?"

But, yeah if you have a decent size group working on a project I can see how this becomes much more relevant.
 
Last edited:
aL Mac said:
I've seen the Joel test and most of them are great things to ask, but some of them don't apply in every situation.

edit: I guess this one seems to be the least important to me if you work on a small team

"Do you make daily builds?"

But, yeah if you have a decent size group working on a project I can see how this becomes much more relevant.
Click to expand...
I think daily builds are a huge thing. It's a pain when people break shit.

Yes, it's rare that any company is going to pass all of them, or maybe even almost all of them. But it's a good way to raise red flags.
 
Yeah, just the project I work on only has two people.. we never have broken each others shit before in any meaningful way
 
I've got my first phone interview tomorrow morning! I definitively know exactly what you're feeling. Good luck!
 
robvas said:
*** snip ***
Do you use the best tools money can buy?
*** snip ***
Click to expand...

I would never use those exact words. Nevertheless, the answers this question is fishing for are definitely important.

I would not want to work for a company whose development PCs have been passed around for the better part of a decade and are still running XP with two gigs of RAM. Nor would I wish to be limited to .NET 2.5 because they have not updated their Visual Studio license and/or their servers are still running an old version of Windows Server.

Also, yes, asking questions is exceedingly important.

Another a few more bits of advice:

Try your best not to let one bad interview ruin the rest of your scheduled interviews for that day. No matter how badly you may think you botched some whiteboard algorithm question, it is highly unlikely that one poor performance will discredit other accomplishments you have made that day. This often holds true even if said poor performance would be critical to the position you are applying for.

Always remember that employers are rooting for you. They want you to succeed at your interviews. Finding good personal is difficult and interviewing is costly. Even if you are found to be a poor fit for the position you applied for, most companies will try to find something else to offer you if enough interviewers stick up for you at your wrap-up.
 
Honestly its all about being the man. I want to say be overconfident even if you don't know the answer, know that you can figure it out. Don't be stupid or swear or anything. I landed both of my jobs without ever needing to code for someone. People just loved my snarky personality that i was the guy that got things done. I can code too, and no one has ever questioned it.
 
I just got off the phone with my interview. They started with things like, what are the modifiers for java functions (private, final, etc) and explain them.

Then things like, explain the difference between heap memory and stack memory

Then some algorithm questions. This is just a quick recap, the whole thing was 45 minutes.

Wasn't too too bad TBH, but hoping that it went well!
 
Devastadus said:
Honestly its all about being the man. I want to say be overconfident even if you don't know the answer, know that you can figure it out. Don't be stupid or swear or anything. I landed both of my jobs without ever needing to code for someone. People just loved my snarky personality that i was the guy that got things done. I can code too, and no one has ever questioned it.
Click to expand...

It's not about "being the man". It's about showing you know your stuff and that you can get the job the employer wants you to do can be done by you. I've grilled lower classmen at my school before I graduated to help them with interviews, and there's always someone who thinks they are a hotshot and try to BS their way out of questions they clearly had no idea what the answer was. If I ever interviewed someone who boasted confidence without providing me any evidence that confidence is backed up by actual experience and ability, I would just write that candidate off as a no-hire. How do I know you can actually do anything I want to hire you for if I don't make you do it during the interview?

If you don't know the answer to something, I think it's likely that most employers would rather have you state you don't know the answer, but then work through some possible avenues to a solution. If you BS around, they won't be impressed (or at least, I wouldn't be). If you say you don't know the answer, think carefully about the problem and then logically come to a solution (doesn't even need to be optimal), you've just proven to your potential employer that you can take a problem that isn't familiar to you and come up with a workable solution. Better solutions could come later, but you've shown them you can think about something and get a reasonable outcome. This is often far more valuable than a simple fact check that many interview questions tend to be.
 
Devastadus said:
Honestly its all about being the man. I want to say be overconfident even if you don't know the answer, know that you can figure it out. Don't be stupid or swear or anything. I landed both of my jobs without ever needing to code for someone. People just loved my snarky personality that i was the guy that got things done. I can code too, and no one has ever questioned it.
Click to expand...

I have.
 
Devastadus said:
Honestly its all about being the man. I want to say be overconfident even if you don't know the answer, know that you can figure it out. Don't be stupid or swear or anything. I landed both of my jobs without ever needing to code for someone. People just loved my snarky personality that i was the guy that got things done. I can code too, and no one has ever questioned it.
Click to expand...

mikeblas said:
I have.
Click to expand...


+1 to Mike.

Nobody gets hired here without writing some code. To be fair, though, if a rock-star applied we would likely make an exception; I wouldn't ask Jon Skeet for a coding sample.
 
The Irony being that Skeet openly admits to being around much smarter people than himself. There's quite a difference between knowing your ability and thinking you have ability...
 
Wiseguy2001 said:
The Irony being that Skeet openly admits to being around much smarter people than himself. There's quite a difference between knowing your ability and thinking you have ability...
Click to expand...

Skeet may not be the smartest guy in the office in which he works. All I'm saying is that I wouldn't ask him to code during his interview here.
 
TESLA said:
1. Side Projects

Side projects show off your love for what you do and make you far more attractive as a candidate, even if you have had previous work experience in the field. Side projects also add to your programming and design experience, as well as help to keep your skills sharp and current.
Click to expand...

This is big. Lots of applicants can talk, or say they worked on this or that. But when you can actually present something you've made, that says a lot.

On the other hand, it says a lot. Are there lots of errors in the product? Does the code look like crap? Is it easy to work on?

There are a lot of smart developers who can figure things out. But I'd rather be working with one who's already built something similar to what I'm hiring for, since they've been down the road at least once already.
 
I don't put much weight in side projects. Say you're interviewing me and you ask me for some code.

First, you're assuming I've got code that I can give you. If I'm working for money, anything I write is owned by whoever was paying me. (There are exceptions, but they're very far in between.) If I'm working hard at my job, I might not have time or inclination to take on personal projects. Maybe I'm not even interested in releasing my own code because I think it's interesting or leads to a proprietary idea.

But say I do provide some code.

What code can I provide for you? Maybe it's something you don't think is interesting or novel at all. Even if it's perfectly written, it doesn't give you any insight into my skills ... the majority of which I'm spending on my daytime work. It's far more likely to figure that a tool I'll write for myself is a place where I'll cut corners -- after all, I'm the only guy to use it and see it -- so it's okay if I skip some steps.

The only real value of writing code for most people is to learn something -- probably something new. If I'm just cutting my teeth on a new tool, API, or technique, you're getting an inaccurate assessment of my overall skills.

I'm also writing code to constraints and requirements that you don't know or understand. Sure, you could ask about them, but anything I say is going to sound like an excuse about prioritizing this over that. You might think something is a bug when I either don't care about it or think it's a feature, in an extreme case.

You don't know if I wrote the code in question, or if it was easy or hard for me to do so. Did I spend 10 years on a ten minute problem? Did I shotgun through the whole process? Did I copy pasta from the web?

At the end, my code samples really don't tell you much about my coding skills.
 
You must log in or register to reply here.
Back
Top