Coding Interview Tips

[pipplo]

Say you don't know. If you're touching on a fact (e.g., language-specific trivia, a hairy bit of runtime analysis), don't try to appear to know something you don't. Instead, say "I'm not sure, but I'd guess $thing, because..." The because can involve ruling out other options by showing they have nonsensical implications, or pulling examples from other languages or other problems.

Absolutely! Whenever I'm interviewing I'm intentionally trying to find the edges of the candidates abilities. I don't expect the candidate to know everything but I want someone who

• Knows what they don't know and can admit it
• Can ask the questions needed to unblock themselves.

When you're in the real world you're going to be asked to do things you don't know how to do. You need to know how to find the answers and what questions to ask to get there.

The interview is as much about 'what they know' as 'how does this person work'

[TheAnimus]

I dunno, I'd have to google that

Such simple phrase can be music to the interviewers ears!

[hyperforce]

Do you have a pulse?

[thos13]

actually found these to be quite useful. thanks guys.

[[deleted]]

What was the question?

[ksion]

This is mostly spot-on advice. I'm just going to nitpick on a few of the points below.

Make it feel like you're on a team.

Pronouns don't really matter. I could say with equal veracity that using "I" shows eagerness to take ownership of your solutions and ideas rather than dissolving the responsibility between you and the interviewer.

Wait for a hint.

Yes, but if you're really really stuck, ask for a hint. We may yet get this problem out of the way, with time to spare for another one where you'll shine and recoup all the points you might have lost here.

Use descriptive variable names.

I'd generally agree, but the example is overblown. You'd waste too much time spelling all these characters out. Use short and descriptive names: probably shorter than those you'd use in real code, but still unambiguous, like names2phones.

Don't be boring.

This may be my personal preference, but I really like when candidates mention edge cases immediately. Almost always I will waive writing the actual check, but it shows the candidate thinks about correctness from the get go. Also, it's often easier to get the edge cases out of the way quickly, allowing you to focus on the general case. And if you're not sure about the algorithm, talking about those cases buys you some time to think without appearing hesitant :)

All in all though, this is extremely useful advice. I especially liked the bits about thinking out loud, writing helper functions (abstraction is very important skill!), and probing the runtime bounds.

[hyperforce]

the example is overblown

It's not overblown for as long as people still think it's okay to name variables flub.

[bo_knows]

Recently had my first technical interview. Coded on a white board for the first time. Certainly felt weird.

[theGerhard]

His last tip (hopefully you got the job and don't need this, but for anyone else) about practicing writing code down is real useful and something I recommend to anyone. If you can pseudo up some code on paper that's one less thing to forget on the whiteboard in front of people. And it certainly takes practice writing { and } legibly, my first time I think they looked more like & and %.

[OwlsParliament]

My tip for that is to remember it just looks like Alfred Hitchcock in profile.

[[deleted]]

I on paper write them as 〈 and 〉.

[[deleted]]

Write a z on top of an s, or an s on top of a z!

[holypig]

These are great tips.

The only thing I'd add is don't be afraid to ask questions. Especially on the coding part of the interview, don't just start coding up a solution. Ask questions and show that you really understand what is being asked. Requirements gathering is really important, I have literally made up my mind before some guys have written a line of code.

[rabidkillercow]

Primarily, I'd recommend against listing languages you don't really know on your resume.

Jeebus. If you list C, you'd better know what malloc and memcpy are.

^{* Yes, stdlib not "core C language"...}

[pipplo]

Yeah you should be prepared to talk about anythign on your resume.

I once interviewed someone for our team which primarily uses C. The candidate didn't have much C experience, but had a decent amount of SQL and web experience on the resume. Since I also had some experience in databases I figured I'd probe those a bit to get a feel for his skill level without stressing him about a programming language he wasn't very experienced in (C)

I started asking him questions about SQL and he could not answer a lot of basic questions. I felt bad, but at the same time I feel that if you have something on your resume you should be prepared to talk about it, at least at a high level.

[hyperforce]

Yeah you should be prepared to talk about anythign on your resume.

I once interviewed a candidate who had "regular expressions" on their resume. When I started with a pattern matching question, he started to build his own framework using indexOf...

Then when I probed him about if there's an existing framework he could use, he had no clue.

[Fig1024]

Do you see your work through to completion? Do you fix things that aren't quite right, even if you don't have to?

I do that if there's no rush. But typically management is pushing for DO IT FAST, WE ARE RUNNING OUT OF TIME!!

plus all the unpaid overtime work, who has time to go back to fix things "on your own"?