The following article originally appeared in DZone's Web Dev Zone.

Update: For companies hiring developers, *this* is how you should write developer job postings and conduct interviews. The content below is for developers to prepare themselves for most scenarios, but not all of them are the ways that companies *should* be conducting interviews.

There's a dirty little secret about all those "Interview Questions and Answers" articles on various programming topics that so many inexperienced developers search for. They're almost all trivia style questions.

They're not questions to test how you think. They merely test memorization skills. Articles about interview questions are actually more like study sheets used for getting up to speed with a topic for the first time, not something you should be scrambling to learn before an interview.

That's because in most real interviews, you won't be able to accurately predict and answer all of your questions just by reading articles online. The worst thing about interview question and answer articles is that they imply that you can succeed in your interview with a static knowledge approach. But what every programmer really needs to succeed is an adaptive, creative approach to problems they encounter, built on a solid foundation of programming concepts.

If you do get a series of trivia questions in your interview—for example, maybe they ask for a bunch of definitions like you would see in a standardized test—then the person interviewing you may not be a developer, and you'll want to find out if you can talk to one so you can better understand what the position will be like, because those kinds of questions might indicate that the organization doesn't have good hiring practices, or that they may not have good development practices. Find out, because if you ask any veteran of the developer community the same questions you find in those interview question and answer articles, they'll think it's a joke.

This article is an attempt to undo some of the damage done by the majority of "interview questions and answers" posts aimed at various types of programmers. It's going to show you where you might need to develop your fundamental programming skills so you can reliably apply to any programming job, because you'll be able to get up to speed quickly regardless of what technology stack the company uses. You won't just be a Ruby developer or a Java developer, you'll be a developer.

The Programming Interview

If you are interviewing for any programming position, you're going to need to show that your fundamentals are solid. Most companies can work with that, even if you don't have all the specific skills they want right now. Companies that are good at doing developer interviews will screen for programming fundamentals right off the bat, and they'll do it with online tests and streamlined phone screens—two interview methods that won't waste a lot of their time—so that they can quickly see if you can actually program.

By compiling the interview techniques discussed by Steve Yegge, Chris Sells, Dave Fecak, and Jeff Atwood, this article gives you a framework that WILL prepare you for the practices generally found in software industry interviews. You may encounter some differences, and most interviews probably won't include all of these steps, but if you do some practice in each area, you won't be surprised by anything.

Portfolio

Let's start by talking about you. Can you learn new technologies quickly? Do you enjoy challenging problems? Have you ever pushed technologies beyond their limits because it seemed like it would be a fun experiment? If you honestly answered yes to some of these questions, then you've probably got what it takes to be a good developer. Now the only thing left to do is prove it. For that, you need a portfolio—a collection of code projects, an online presence, and a brand as a developer.

Side Note: Not all developers need a portfolio.  They're mostly useful for junior level candidates, people who have been with one company and one technology for a long tenure, or people with few demonstrable or individual accomplishments.

I know this was supposed to be about interviews, and the portfolio isn't technically part of the interview, but many companies will want to see code and content you've already written and use it as an unbiased way to form a first impression of you. Half the battle of getting hired is simply coding every day and exhibiting those traits mentioned above in a publicly visible way.

Every developer needs to know how to market themselves. Here are some of the primary methods you want to use:

• An open source code repository

• A blog

• A Stack Overflow profile

• Networking

• Social Media

Your Repo

The open source code repo (e.g. your GitHub page) is the most crucial piece. Nobody will know if you've coded something great if it's not out there on the web for everyone to find. Put your stuff out there, even if it's something small or silly that you made for fun. Usually, the people hiring you won't care about what the code is for, but whether you are excited about what you worked on and can talk passionately about it. It also doesn't hurt if the code shows that you have worked on something relevant to their business. So showcase all your best code, even if it's not perfect (always go back and refactor if you can though). If you have code that you can't put online for some reason, then make sure it's all well-organized in a ready-to-send zip file.

Your Blog

A blog is another major tool in your career advancement arsenal. You can fake your knowledge in topics sometimes by memorizing a few interview questions, but you can't fake a blog. It showcases your development skills, personality, and engagement with the wider programming community. It's also an opportunity to advertise (and improve) your writing and communication skills, which can sometimes be a key factor in whether you're hired during a close race with other candidates.

It doesn't matter if barely anyone reads it. As long as you try to submit it to some link sites and share it on social media, you'll get a few views. You just want your blog to convey that you're interested in various development topics and that you have a passion for the space and sharing knowledge. One thing to remember is that that having a blog that hasn't been updated in many months can be a detriment to your perceived value, because it might imply that you let tasks fall to the wayside when you get busy. To combat that tendency, just remember to have fun and write about multiple topics that interest you, not just programming. Try not to let blogging feel like work.

Your Network

Networking with other professionals in your industry is almost always the best method for getting interview opportunities. Very often it's much better to get an interview through the backdoor. Many job openings (maybe a majority of them) never get posted. They're filled by people who current employees have already met and chatted with. In fact, if a job is already posted, your likelihood of getting it goes way down because now you're competing against a much bigger group.

Luckily, networking for developers is easy. There are countless user groups and meetups around the world on various sub-topics within the development industry. Find several that might be useful and go talk to people. Make friends, get their contact info, and get back in touch once in a while. Talk to them about the interesting code you're working on. Email bloggers that you like and connect with them on LinkedIn. If you keep building relationships in the industry—online and in-person—eventually someone will notice your work and help you get an interview.

Your Social Media

Twitter is one of the best ways to connect to the developer community. As long as you're not rude or offensive, you should be able to show your honest personality on Twitter and your passion for programming topics and news. Use Twitter to network and have interesting conversations about coding. Try tweeting at your programming idols once in a while too. Unlike mainstream celebrities, they might actually respond. There are a lot of ways you can use social media sites to improve your online footprint and brand.

Stack Overflow is the one website you absolutely need to be on (and you probably know this and have already used it if you've ever run into a tough problem programming). But don't just consume help, make some time in your schedule every once in a while to find some questions to answer. Not just so you can improve your karma, but so you can very clearly show potential companies what kind of communicator and problem solver you are in real-word situations. Stack Overflow can also be a valuable place for networking in the developer community.

Your Narrative

All of these pieces of your portfolio are important, but the main thing you want to try to do with all of them is build a public narrative of yourself. In all of these channels you should convey yourself as a person who keeps up with changes and conversations in the industry, takes on challenges, and can teach others. A good technical interviewer knows that it's more important to find out if a candidate can pick up new technologies over time, rather than simply having a candidate who's resting on the laurels of knowing their current technologies well. So use these channels to show that you've put in the effort to gain a deep understanding of various technologies, because that shows potential employers that you can probably do this again with a new technology at their company.

Resume/CV

I wanted to add one last footnote to the portfolio section to address resumes, even though they can often seem like a pointless exercise in the hiring process. It's true that showing somebody that you've done something is much more compelling than simply saying you did it, but many companies need the resume just to filter out people who don't even claim to have the skills for the job (unfortunately, this can mean that you have to cook up some keyword soup). For this section I'll just leave you with some links to helpful resources that should help you build an effective and relevant developer resume.

• How I Read a Technical Resume - Dave Fecak

• Why Technical Resumes Need a Profile - Dave Fecak

• Ten Tips for a (Slightly) Less Awful Resume - Steve Yegge

• How HR Reads Your Resume vs. a Developer [Humorous, but with kernels of truth]

The Interview

Now onto preparations for the interview. Like any skill, interviews are won in the wee hours of the nights that you spend working on becoming a better programmer. They're won in the meetups, blog posts, and other activities that you do to improve your communication and writing skills. So basically, if your interview is tomorrow and you haven't been working hard for several months nurturing these fundamental skills, no amount of interview practice is going to save you.

With that being said, it can help an awful lot if you know the types of questions you'll be encountering in an interview. You shouldn't feel like you need to go memorize answers. Instead, you should be looking up exercises to help you brush up on the fundamentals you already have. You need to be able to adapt to questions and know the answers because you've actually coded things that taught you about the underlying principles of a question. Memorizing answers without having any real experience with the underlying principles won't get you the job, and even if it did, would you really be able to do it?

These next few sections will be helpful at laying out the general types of questions you're likely to get in a programming interview. While some of these sections won't be a part of every interview (some might be fairly rare, in fact), knowing about each one will prepare you for most developer interviews.

Online Pre-Screen Test

This portion is not as common as the phone screen, but if you encounter one, just know that it's basically a pre-screen to see if you make it to the phone screen. Some companies can't spare enough people to do a large amount of phone screens, so they use an automated online test to prove whether or not you have the basic knowledge requirements. This is important because a surprising number of applicants have some major holes in their fundamental knowledge of programming. The tests should feel simple to you, and if they don't, the requirements for the job might be too high for you right now. Most of the time this is just a sanity check to see if you know basic programming.

You can go see what these online tests might look like by trying a free trial test from one of these companies that actually offer these online pre-screen tests as a service. Interview Zen and Codility are two examples.

Phone Screen and In-Person Technical Interview

Some companies will have you do a phone screen before they commit more time to an in-person interview. While the phone screen could potentially include any level of question difficulty, most are focused on fundamentals and understanding your thought process. Interviewers are not looking for the perfect answer. As you already know, many times in programming there is no one correct answer, only different options with different trade-offs.

If you run into a question that you don't know the answer to, don't worry. First off, part of reason why interviewers ask tough questions is to see if you can handle them calmly and logically without getting lost or breaking down. They also just want to see that you have a solid thought process that indicates experience with solving difficult programming problems. Here's a good template for how you can answer questions you don't know the answer to:

"I don't know how to do that, but if I ran into that problem in a project, here's how I'd go about figuring out how to make it work..."
-- Mason Wheeler

You've now turned it into a question that you can answer. Because (again, you probably already know this but…) programming is a constant struggle with questions you don't know the answers to. You should also read Alan Skorkin's How to Answer a Programming Interview Question and Look Good Doing It.

5 Common Coding Questions in an Interview

There are about five areas that Steve Yegge believes are essential to address in a phone screen (but these could also come in the technical interview). Here they are:

1. Write Some Code

You'll want to show that you can write code with correct syntax to make a simple program. Some of the common tests include:

• FizzBuzz

• A function to reverse a string

• A function to compute Nth fibonacci number

• A function that prints the grade-school multiplication table up to 12x12

• A function that sums up integers from a text file, one int per line

• A function to find the largest integer value in an integer array

• A function that formats an RGB value (three 1-byte numbers) as a 6-digit hexadecimal string

You'll want to be sure that you can handle concepts like recursion and do simple file I/O. You can test yourself on all of these exercises and a bunch more at hackerrank.com.

2. Model an Application

This is something you can practice with just a piece of paper and a pencil. If you're modeling the design of a hypothetical application in-person, you should probably request a whiteboard or piece of paper if they have it. Object-oriented design is the go-to style you'll want to use here, unless the job specifically requires something else. Here are some tests that Yegge suggests:

• Design a deck of cards that can be used for different card game applications.

• Model the animal kingdom as a class system, for use in a virtual zoo program.

• Create a class design to represent a filesystem.

• Design an OO representation to model HTML.

These are a little more difficult than the basic coding question examples we just looked at, but usually the interviewers won't be looking for comprehensive, low-level OO design. This is just an exercise to show that you have a strong grasp of basic OO principles, and there are plenty of resources out there to help you practice problems like these as well.

• Building Skills in OO Desgin

• Brett Schuchert's Monopoly

• Bob Martin's Bowling Game Kata

• Jeff Bay's Object Calisthenics

• Martin Fowler's famous Coffee Maker problem - Additional content 

3. Solve Scripting and RegEx Problems

You should have some experience building applications that use scripting and regex. Here's another specific problem that Steve Yegge used (and apparently 25%-35% of candidates can't solve the problem):

Last year my team had to remove all the phone numbers from 50,000 Amazon web page templates, since many of the numbers were no longer in service, and we also wanted to route all customer contacts through a single page.

Let's say you're on my team, and we have to identify the pages having probable U.S. phone numbers in them. To simplify the problem slightly, assume we have 50,000 HTML files in a Unix directory tree, under a directory called "/website". We have 2 days to get a list of file paths to the editorial staff. You need to give me a list of the .html files in this directory tree that appear to contain phone numbers in the following two formats: (xxx) xxx-xxxx and xxx-xxx-xxxx.

How would you solve this problem? Keep in mind our team is on a short (2-day) timeline.

This question might be considered a trap question, but it brings up a good point to remember: Interviewers don't want you to reinvent the wheel in your interview. If there's a tool or command out there (in this case, "grep" was a perfectly reasonable answer), say in your answer that you would use a particular tool. Don't feel like you have to know how to translate anything into regex. We all use tools for that. If interviewers say that you can't use certain tools for the purposes of the question, then they're just trying to see if you understand how some software or process works under the hood.

4. Know Your Data Structures and Algorithms

You can't get very far in programming without knowing your data structures, and you won't write very good code if you don't understand the intimate relationship between data structures and algorithms. Yegge's suggestions offer more detail, but you'll need to know at least the basics of these data structures:

Arrays - structures with a fixed number of contiguous elements, each accessed by a separate index.

Vectors - like arrays (and backed by arrays), but can increase or decrease the number of elements as needed.

Linked lists - sets of boxes with two compartments each: one containing data, the other containing a pointer (or rather a generic reference) to the next item in the list.

Hashtables - maps of keys to values (picture a table with two columns), with collision handling (in case the function that outputs a value given a key outputs the same value for more than one key). 

Graphs - sets of things (called "nodes") connected to other things (called "edges"), sometimes restricted in specific ways (e.g. nodes and edges can be ordered, typed, named, etc.).

Trees - graphs whose nodes are related to one another only as parent to child or vice versa (e.g. one node can't contain a pointer to the child of its parent's parent that isn't also its own parent).

You need to at least know about these six data structures. Obviously there are more, and it's great if you know about those too. An awesome way to learn these if you're a visual learner, is to go to VisuaAlgo, a site that visualizes a ton of data structures and algoritms through animations.

For each of these data structures you should know how to use them in real world examples, how to iterate over each one's elements, and why you would choose one structure over another in a given scenario.  This is where some knowledge of big-O performance for each data structure's operations (know what operations each one has too) could come in handy. Big-O notation is just a way of representing how many operations an algorithm performs given an input of a particular size. There are books and wikis that can help you brush up on this.

5. Know How to Count Like a Computer

You don't want to be running into integer-overflow errors all the time or not know how to decode serialized objects, so you need to know what bits and bytes are and how to count in binary. Let's look at Steve Yegge's example questions one more time:

• Explain how to test whether the high-order bit is set in a byte.

• Write a function to count all the bits in an int value; e.g. the function with the signature int countBits(int x)

• Describe a function that takes an int value, and returns true if the bit pattern of that int value is the same if you reverse it (i.e. it's a palindrome); i.e. boolean isPalindrome(int x)

Some things you might want to brush up on to be stronger in this area include:

• Being able to count in hexadecimal and convert between binary, octal, and hex representations of a number.

• Knowing the fundamentals of AND, OR, NOT and XOR (e.g. what's the difference between a bitwise-AND and a logical-AND?)

• Understanding why 2^16 is a special number

• Being able to estimate the probable sizes of the primitive data types for a standard 32-bit (e.g. Intel) architecture

Some of these concepts will be more important in some jobs than others, but it never hurts to be prepared, and knowing these things can set you apart from any candidate that doesn't. It will be harder to get caught up on some of these topics if you haven't studied computer science, but the resources and online courses are certainly out there to get yourself up to speed.

Puzzlers

Brain teaser questions are now being shunned by the bastions of the software industry. Even Google, the company that was well known for it's impossible puzzlers a few years ago, has moved away from the practice.

“Brain teasers are a complete waste of time. How many golf balls can you fit into an airplane? How many gas stations in Manhattan? A complete waste of time. They don’t predict anything. They serve primarily to make the interviewer feel smart. … Results matter, riddles don't."
-- Laszlo Bock, the Sr. VP of HR for Google

But unfortunately, some segments of the industry are lagging behind and have yet to expunge this tool from their hiring practices. The only value in these questions is just to see how you handle a difficult (often unsolvable) problem. These are not coding questions. They're crazy, high-level questions like, "what method would you use to move Mt. Fuji?" The best strategy is to just try to be creative and handle the question as logically as possible. The interviewer just wants to see how you think, and maybe they're hoping you'll come up with something exciting and innovative (which is kind of a stupid thing to expect). You can prep for these if you want by checking out some of Google's old questions.

General Guidelines

• Always approach problems from a logical angle.

• Ask questions to solidify vague requirements.

• Properly use any features available to solve a problem (if there's a whiteboard, use it!).

• Point out any shortcuts or limitations of the medium you're using to accomplish a task in the interview.

• Understand the "why" behind your answers as well as the "how" and be able to explain each clearly.

Anecdotal Questions

Aside from coding questions, you'll also encounter anecdotal questions. Basically these are questions where, rather than being asked 'what would you do in this situation?" you're usually asked to describe what you did do in a certain situation. So before the interview, you'll want to take note of some notable situations in your career (both positive and negative) and determine how you'll retell that story while emphasizing the important themes. Be ready to have a back-and-forth discussion about these questions and explain how certain strategies worked, what you learned from the experience, and how you might do something differently next time.  

If you haven't encountered a situation like the one they describe, ask questions to get more details and then explain what you would do and why. These questions are mostly designed to see how you handle work situations like deadlines, conflicts, and interactions. It's usually not about code but how you handle yourself as a professional and whether or not you would be a good cultural fit with the team and the company as a whole.  More on that in the next section.

Cultural/Team Fit Interview

In most cases, you'll be working with a group at your prospective company. They're going to want to know what kind of personality you have, how you communicate, and how you handle difficult situations. Many of these questions will be anecdotal style questions that try and discern how you actually handle various situations. Try and predict some of the questions you might be asked relating to the specific work environment and organizational style of the company you are interviewing for. Some general question examples from Chris Sells include:

• What's the right process for gathering requirements?

• How do you deal with vague requirements?

• How do you convince someone that you've got a good idea?

• What do you do when you can't convince them?

• What happens if you're asked to do something you don't agree with?

• (If you're interviewing at a startup) How do you like the idea of quick decisions, hard work on short deadlines, light process, and tight purse strings?

• (If you're interviewing at an established company) How do you like the idea of getting buy-in with a set of stakeholders, making sure we don't ship anything until it's done, following an established process, and sticking to a budget?

• What's more important: the customers or the business?

• What kinds of activities are most important to you? Do you like to be focused on your set of tasks or do you like to do a lot of different things?

• What makes you as productive as you can be?

• Where do you see your career path taking you?

A really cool (and smart) company will actually take you out for dinner or drinks with the team to see if you generally get along with the team and are a generally nice person.

Don't forget you're interviewing them too though. Talk! Take an opportunity to lead the conversation sometimes. Ask good questions and see if this company and it's culture are a good fit for you.

Coding and Presentation Projects

Instead of having you write some code to solve a generic, abstract programming problem, the main coding portion of an interview will usually require you to build a complete utility or module from scratch. Sometimes these will be take-home projects or you'll do them at the interview. Sometimes you'll be asked to pair program with another employee of the company. These "auditions" may even take an hour or two to complete, but the project will usually be fairly small.

A company that really knows how to hire programmers may even give you an actual unit of work from their product, and they'll pay you for your time (if they don't, you might want to reconsider joining the company).

One final interview scenario you might run into is a required presentation. Jeff Atwood has his own ideal interview strategy:

Have the candidate give a 15 minute presentation on their area of expertise. I think this is a far better indicator of success than a traditional interview, because you'll quickly ascertain …

• Is this person passionate about what they are doing?

• Can they communicate effectively to a small group?

• Do they have a good handle on their area of expertise?

• Would your team enjoy working with this person?

While this ideal of Jeff Atwood's is rare in most developer interviews, you should appreciate the chance if you ever get to do one of these presentations and have fun with it. This is the type of pitch you'll have to give often in your career in order to suggest new technologies and directions for projects, so you can only improve your value by practicing for this interview scenario as well. The optimal way to practice would be to offer to give a presentation or lightning talk at one of your local user group meetups about a technology you think would help a lot of people in the group.

How to Practice for Interview Questions

Now that we've covered the most common developer interview stages, all that's left to do is to practice for it. There are so many great resources online that can help you do this. So many, in fact, that you'll probably never complete all of the puzzles and katas out there, but that shouldn't stop you from continuously sharpening your development skills with these coding challenges, even after you get the job.

GitHub Repos With Interview Question

• Just do a GitHub repo search for "interview questions." You can filter these by the language that's relevant to your job search – Front-End Interview Questions is a great example.

Koans

• rubykoans.com started the trend, and now there are Koans for just about every language and several other tools.

Katas

• Jeff Atwood - The Ultimate Code Kata

• Search "Katas" on GitHub

Code Challenges/Practice Questions

• HackerRank

• Java Puzzlers

• Interview Cake

• Kate Matsudaira's Epic List of Interview Questions

Books

• Cracking the Coding Interview (6th ed.) by Gayle Laakmann McDowell

• Job Tips For Geeks: The Job Search by Dave Fecak

More Interview Prep

• Read EVERYTHING YOU CAN on Dave Fecak's blog archive under Resume Tips, Interview Tips, and General Career. Interview Prep For Geeks and How and Why to Backdoor Into Jobs are must-reads.

Good luck on your interviews! You're going to do great!