Greythorn Career SuiteWhiteboard Interview Guide

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.

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.

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//

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.