Seems to be covered by countless web sites already.

The short list I know about are the standard items that have nothing to do with games:  Tell me about yourself; tell me about your strengths; tell me about your weaknesses; why do you want this job; why did you apply to this company specifically; why should we hire you.

Generally I'll also brush up on a few hours of writing some basic algorithms: practice making a linked list, a search, a sort, in-place string reversal, that type of thing.

Other than that, only brush up on a topic if you feel you need to. A skilled interviewer will ask technical questions until they hit the depth of your experience and knowledge and they can do it quickly.  They'll also focus not on determining if you know specific answers, but instead if they think you are smart enough to do the job well, and if they think you would fit within their culture. (I don't mean young white male, I mean for some groups hiring an assertive person or a boisterous person or a quietly thoughtful person could interfere with the rest of that group. It is a generally unspoken part of interviewing but sometimes there are personalities you want to avoid and other times there are personalities you want to find.  Sometimes a non-matching personality is exactly what you want to stir things up, other times it needs to be avoided for stability.)

Oh, please, please, whatever you do, don't ask people about their weaknesses, unless what you are looking for is the ability to manufacture bullshit. If someone asked me about my weaknesses, I would either walk out of the interview or tell them that my biggest weakness is not having any tolerance for ridiculous questions like that one.

Really, what do people expect to learn from such a question?

21 hours ago, DUDVim said:

I'm creating a list of good questions to ask the candidates to be able to judge the skill level they have. Good questions do not need to have a 'correct' answer, they should be as good starting point for further discussion and questions.

That reverses most of the question from candidate to interviewer.

Fortunately most of my earlier reply still applies. I stated what the candidate should try to give the interviewer, so just reverse your role between the interviewer with the candidate.  Particularly, this:

11 hours ago, frob said:

They'll also focus not on determining if you know specific answers, but instead if they think you are smart enough to do the job well, and if they think you would fit within their culture.

I think the definitive answer was the Joel on Software article from 12 years ago, 3rd edition.  That's the crux of my answer earlier, but from the candidates perspective.

As the interviewer you need to know what position you are hiring for.  You need to understand the job well enough that you can tell if the person can do the job or if they can't.  If you don't know those things, it is your responsibility to discover what the business needs before the interview.  

While you ask your questions think about the needs of the business.  While asking questions about what they have done before, ask probing questions about how much they did, what problems they solved, figure out what problems they couldn't solve, and work from there.

As for asking about weaknesses, most interviewers are hoping the candidate will blurt out something that says they aren't a good fit.  It rarely happens, but sometimes it does.  A candidate who talks about being chronically late may disqualify themselves if the company has strict standards on timeliness.

Always remember that interviewing is a process of exclusion, not inclusion.  Employers are looking for reasons to exclude candidates from the pool and reduce it to 1.

32 minutes ago, nhold said:

I don't like asking for really specific language questions or algorithm implementation anymore as that's really just testing memory, most of the time you should be testing problem solving or testing for the job they'll be doing.

Sometimes those language-related "memory" questions can have real design consequences, though. Consider: what does the following C++ code do?

class Singleton1
{
private:
  Singleton1();
  void frobnicate();
public:
  static Singleton1& getInstance();
};

class Singleton2
{
private:
  Singleton2();
  void collateLargeThings();
public:
  static Singleton2& getInstance();
};

Singleton1::Singleton1()
{
  Singleton2::getInstance().collateLargeThings();
}

Singleton1& Singleton1::getInstance()
{
  static Singleton1 inst;
  return inst;
}

Singleton2::collateLargeThings()
{
  Singleton1::getInstance().frobnicate();
}

This is abridged and renamed from real (legacy) production code, by the way. I would hope nobody is doing this in 2018.

I look at that code and I don't see anything that would help me make a hire/no-hire decision.

Playing "spot the pattern" and "find the bug" can be an interesting game, but is mostly about background knowledge (which can be learned in minutes on the web by a smart person) and code reading. It doesn't really tell me if the candidate is inherently smart, nor does it tell me if they can write good code.  

While it is nice to know that they have some background knowledge, their work/school history and their completed projects can state that clearly. I want to see what they write, not what they can read.

On 3/22/2018 at 10:09 AM, alvaro said:

If someone asked me about my weaknesses, I would either walk out of the interview or tell them that my biggest weakness is not having any tolerance for ridiculous questions like that one.

Kryptonite.

On a more serious note, ask for past responsibilities, recent problems they've encountered and how they went about trying to solve those problems. An extra interviewer in the room is also nice to have if you can spare one.

Also remember that an interview is a two way street, the perfect candidate might turn you down if you don't come of right.