In a whiteboard interview, your goal should be to convince the manager that you will be a positive influence on the team and contribute to the team's success. This guide will help you set the right mindset, ask the right questions, and showcase your strengths.

1. Greythorn Career Suite
Whiteboard Interview
Guide

2. Greythorn Career SuitePreliminary Thoughts
Your goal should be to convince the manager that you will be a positive
influence on the team and contribute to the team’s success. Each
manager has ideas about where you may fit before you meet them.
Emphasize your strengths, but if you are unsure of an answer, offer a
possible approach to reaching the solution.
Share information in real-world scenarios, as if the questions you are being asked are on the job. Save
the coding details for technical questions and focus on real-world application of the concepts at hand.
Mindset
Non-Technical Questions to Ask
• Where are you in the SDLC?
• How many bugs have been found and what is
their nature?
• What is the curent team workload?
• How many positions do you have open?
• How solid is your code base?
• What are the immediate and long-term needs
of the team and the project?
Frequently Missed Questions
Why do you want to work for us?
An excellent answer revolves around aligning your goals with those of the team/company and project.
Remember to make your answer pertinent to the success of the company and yourself.
What are you passionate about?
Discuss your projects, roles, challenges, milestones, etc. in detail and this will equate to passion.
Have you ever written code with errors?
You should always be truthful and explain what the bug was, and how it was fixed. This will
demonstrate your problem solving abilities and expertise.
“I’m a fast learner.”
Avoid this statement altogether.

3. Greythorn Career SuiteInterview Framework
Preparation
For each technical question, you should think of owning the mini project and apply the SDLC to the
question. Each question will most likely be vague with multiple possible solutions that vary based on
requirements gathering.
Document everything on the whiteboard. Typical questions include, “how would you remove duplicate
integers in an array,” “insert and remove an item in a healp,” or “search for a node in a binary tree.”
You will probably be asked detailed technical questions regarding the field or the job itself, such as C#,
.NET remoting, SQL, C++, mobile, web, web services, etc.
There will be five phases to the interview, which we will walk you through.
Phase 1: The Question
First, write the question on the whiteboard. It’s vital you do this to ensure clarity. After you’ve written it on
the board, it is a good idea to turn to the interviewer and verify this is the question asked by the
manager. If needed, more details will be given to further clarify the question. Whatever you do, don’t
generalize.

4. Interview Framework
Phase 2: Requirements Gathering
This is a crucial ste in the interview. It is also where most candidates miss important details.
Your Key Goal: Ask qualifying questions so you can correctly implement code based on the
requirements.
There are many ways to code if you generalize--which is what you should avoid. Managers will not im-
ply, they will state the information clearly. If they do make implications, you should ask a detailed ques-
tion in order to get 100% clarity. Here are some examples of questions to ask:
• What are the inputs/outputs?
• Speed v. memory
• What is being passed?
• How should it handle errors, exceptions, etc.?
• Is this a resource constrained system?
• Is this production code or is this something for
one-time use?
Document the answers to all questions on the whiteboard This phase may last longer than the others.
Don’t be fooled into thinking that the manager cares about syntax as much as design.
Phase 3: Design & Analysis
Draw pictures and have a discussion with the manager to think through the processes aloud.
Add and define variables to make sure your solution(s) fulfill the specifics you gathered.
Phase 4: Implementation
Write the code. If you are unsure of whether your design is optimal or not, do this is pseudo code first,
taking into consideration the logic and flow. Then, implement/code in the language required. You will
test it afterward, so be precise.
Portions: Variable declaration//check for passed parameters//special cases//main loop//

5. Interview Framework
Phase 5: Testing
Offer test cases and walk through the code with the manager. Usually, test cases are the inverse of
requirement gathering items.
Document your test cases - 0 elements, 1 element, null, dups, no dups, null pointer to array, negative
size, etc.
If the code used an array c-h-r-i-s-/0 and “i,” “j,” “array[i],” you may have a table like this:
i j array[i]
j 0 c
Doing this will allow you to assess if you need to re-factor or de-design what you coded. This is a very
simple example, but keeping things clear will only help you.