function contains(s, t)
{
for (j = 0; j < t.length; j++) // check each char in t
{
var c1 = t.charAt(j);
for (i = 0; i < s.length; i++) // now examine each char in s
{
var c2 = s.charAt(i);
if (c1 == c2) // match?
return true;
}
}
return false;
}

This is just a start of course. Next, I’d want to see the candidate look at error-checking. For example, what is parameters s and/or t are null or the empty string? By the way, many interviewers want to see error-checking immediately on questions like this, so if you defer adding error-traps, you should be sure to say something like, “I’m going to write the basic code first, then I’ll address error-checking issues.” Next I’d want to see if the candidate addresses performance vs. memory issues. The solution above could be recast to use a mini-hash table to search through either s or t (depending upon problem constraints) where the mini-hash table just maps the ASCII code of a character to a 0 or 1 value. Next, for a testing position interview, I’d expect the candidate to talk about testing this function. I’d also hope the candidate offers a O(n) analysis — if not, I’d specifically ask the candidate. I like this question as a small part of the interview process for testers. The problem is simple but realistic, language-independent for the most part, has multiple solutions, gives the opportunity for error-traps, and so on. In short, it’s a problem that would give me some insight into the candidate’s technical ability.

char temp = *front;
*front = *back;
*back = temp;

But you can also do a tricky in-place swap using the xor operator:

*front = *front ^ *back;
*back = *back ^ *front;
*front = *front ^ *back;

As always, a key to success is to articulate your answer (no matter what your approach) so that the interviewer knows the boundaries of your knowledge and can determine if you are a good match for the job he has open.

He uses this question for both software development positions and for SDET (engineers who write test automation) positions. The first thing he looks for is if the candidate qualifies exactly what this question means. As stated, it is (deliberately) ambiguous. He also gains some insight into the candidate’s communication skils at this point. Anyway, here’s what he means by the question. Suppose the input string is:

abbadbbeebb

The output should be:

abba
bbeebb

Palindromes are strings that read the same in both diections. For example, “aba” and “cddc” are palindromes. Notice that the output does not contain strings “bb”, “ee”, and “beeb” because they are contained within larger palindromes. The trick is to realize that to find the longest palindromes in a string, you have to work from the inside out. The middle of a palindrome will be either two letters which are the same (as in “cddc”), or a single letter (as in “aba”). Once you identify the midpoint of a potential palindrome, you work outward, checking to see if the two current end characters are the same. If the characters are the same, you keep working outward because you want the longest palindrome.

Once a candidate has figured out the algorithm, then they’ve got to implement it. Like most hiring managers, my buddy does really care if the candidate uses C, Java, C#, JavaScript, Visual Basic, or whatever. If a candidate gets this far, then my buddy will ask questions about the performance of the algorithm, including “Big O” questions.

public class Bumper
{
private string id;
private int pointValue;
private int reboundStrength;
// etc.
public Bumper()
{
// constructor code
}
// properties here
// methods here
}

The interview question really boils down to, “Explain OOP principles to me using a pinball game as a concrete example.” So, the interviewer wants to know about classes, constructors, data fields, scope modifiers, properties, and methods. Additionally, you would want to discuss the pros and cons of creating abstract base classes and using inheritance. A question like this could come in many forms. For instance, “How would you model a vending machine?” Or, “Model a poker game for me.” All of these questions are the same in the sense that they’re intended to determine the candidate’s experience with OOP. Familiarity with object oriented programming is not a Boolean, has-it-or-doesn’t-have-it, kind of thing. The interviewer is looking to see exactly what level of familiarity with OOP the candidate has.

=====
1. Not knowing your aim. Too often candidates think their purpose in an interview is simply to ask for a job. Your goals are to demonstrate how you are a good fit for the organization, and to assess whether the job is really right for you.

2. Being too needy. Neediness is probably the No. 1 advantage-killer in an interview. Remind yourself before walking in the door: you do not need this job. You do need food, you do need air, and you do need water. Keep things in perspective.

3. Lousy nonverbal communication. This is about demonstrating confidence. Your first impression makes the difference. When you enter the interview room, stand up straight, make eye contact, and offer a strong handshake with your interviewer. If necessary, jot their name on your notepad as soon as you seat yourself. Do the same for any other individual you are meeting with.

4. Compromising your position. You should always participate in the interview as an equal, not a subordinate, of the person conducting the interview. Often this is a subtle matter of self-perception, so remind yourself before the interview.

5. Falling into the answers-only rut. An interview is a conversation. Don’t just answer their questions. That’s why you’ve prepared stories to highlight your accomplishments, which will be your moments to shine. When you do answer any questions, make sure that you answer immediately and follow up with a question of your own, if at all possible.

6. Rambling. Telling your interviewer more than they need to know could be fatal. Your stories should be 60 to 90 seconds long and they should have a relevant point. Focus, focus, focus. Stick with your rehearsed stories, your research, and the questions you need to ask. Don’t fill up the silence with unnecessary talk.

7. Being overly familiar. A good interviewer will be skilled enough to put you at ease within the first 10 minutes of the interview. That doesn’t mean that they have become your best friend. Don’t let your guard down. You’re there to interview them and get answers to your questions. Treat this from start to finish as the professional business meeting that it is.

8. Making incorrect assumptions. Points are not deducted at the interview for asking questions when you don’t understand something. Don’t guess at what your interviewer means. Effective interviewing is all about collecting information in real time, taking good notes, and responding only to the actual facts you’ve collected. If you find yourself making assumptions or guessing about something that was said, stop and ask for clarification before you answer.

9. Getting emotional. At times the interviewer may hit a nerve or consciously try to provoke you into an “outburst.” Don’t fall for it. Clear your mind of any fears or expectations, so you can maintain a calm, open-minded perspective at all times. When emotions enter into an interview, failure follows.

10. Not asking specific questions. You want to find out more about what this job is really about and whether you want it. Arrive with a list of several prepared questions about the company, the position, and the people who work there. Ask questions that begin with “what,” “how,” and “why.” Avoid simple yes/no questions. Get your interviewer talking as much as possible, then take notes. Most interviewers are unimpressed by someone who has no questions.