I'm having a onsite interview for QA engineer with Startup. While phone interview the person said he would want to test my JAVA, JUnit and SQL skills on white board with more importance on Object-oriented skills, So what all can i questions can i expect ?
One more important issue : How do i overcome the fear of White board interview ?. I'm very bad at White board sessions, i get fully tensed. Please suggest me tips to overcome my jinx
Your more important question is key. How to avoid getting tense?
Let us be clear. Tension is a killer in interviews. Tension is associated with stress, which causes the release of adrenaline. Adrenaline prepares us for a fight or flight response. This shuts down your digestion, improves blood flow to your muscles, and shunts blood in your brain from irrelevant parts (like, say, the bits that are responsible for advanced logic) to key parts (like the ones that process vision). This is almost exactly the opposite of what you want for any kind of intellectual activity.
This is one of the key reasons why things that we think should motivate us do a bad job of actually motivating us. Watch http://www.youtube.com/watch?v=u6XAPnuFjJc if that sentence surprises you.
The key, therefore, is find a way to go through the interview experience and avoid stressing. If you avoid stress then your brain is likely to work better, which will make you appear better. And don't judge your performance. Frequently you go in for a 45 minute interview and get asked two questions. So when you're asked a question and have no immediate idea how to do it, that's normal. That's normal, even for the right candidate. Start exploring the problem, talking aloud, and see how far you can get.
What makes this possible for me is creating a positive "frame" around the interview experience. Odds are that you are currently at, OMG, I want the job, they are going to judge me, I need to do well! Try to avoid that. What I use instead is, I've got the opportunity to make friends with a bunch of nice people, and let them know what I am like. Absolutely critical to my frame is that I am trying to show them what I am like, and not what I'd like them to think I am like. So, for instance, if they ask if I know X, Y, and Z, I have no problem in saying immediately that I only know Y. If I can figure out an answer to a question, great. Otherwise, oh well. That is who I am. I'm a nice, capable, person. I can do no better than to make "me" be clear, and hope that will shine through. There will be things I don't know, but I can learn, and as long as I convince my interviewer of that, things are likely to turn out OK.
How much does this attitude matter? A lot. It turns out that a bystander can judge how most interviews will go from a 30 second video of the interaction when the interviewer walks into the room. When you approach that 30 seconds with the attitude, "I'm about to meet a friend" it goes much better than if you are stressed and nervous. And once one thing goes well, the next thing is likely to go well in turn.
This takes practice. If you can, try to get actual friends of yours to make you do practice interviews. Have them engage in role-play. Actually be at a whiteboard. You will get better.
A final tip. The first few times you try this you'll inevitably slip back into your normal patterns of thought. Have patience with yourself. This is normal. When it happens take a mental deep breath, and try to center yourself. If you can, create a moment of space. Go take a drink of water. (Or ask for one if one is not there.) If you could use a bathroom trip, ask right then to take one. Even a small break can get your mental composure back, putting you back on track.
Good luck.
One common approach is to have the candidate implement a function or a whole class and then design test cases. Depending on the scope of the problem and the technical skills you're being asked to demonstrate, you might draw a diagram of the object or write out code or both. The best way to get comfortable with this is to practice by yourself or in front of a friend. Talking aloud through your thought process might not be something you're accustomed to doing, but it's a crucial skill for technical interviews.
Some examples:
Simulate a vending machine (Exercise P16.9)
You might also browse advice for people who are conducting QA interviews to see how they will be evaluating you. Google will find you lots of examples, but you can start here on StackExchange:
Since it's a QA position, I wouldn't expect hardcore Java or SQL puzzles. Obviously, solve (or resolve) classic tasks like FizzBuzz question, Fibonacci sequence, factorial.
As for SQL - understanding JOINs is very important, as well as GROUP BY, remembering difference between HAVING and WHERE, etc.
As for JUnit - get any open-source program in Java and cover it with unit tests in JUnit.
Focus on writing simple Junit tests with more emphasis on parametrized test cases, you may be asked to code a function and write corresponding Junit test case. Please google about writing good JUnit test case
I would consider becoming familiar (at least at a basic level) with Dependency Injection and frameworks that support it (like Spring, Guice, etc.). A lot of places use them
A general idea of the common approaches in UI testing (if the company has products with UI) can't be bad either.
