Darkened Software

Software should help you learn...


The Interview Process for games:

1.  Find out which games they play, get them to list specific categories and specific games.  
If they do not list your type of game then stop there since they will not really be behind your game
and it will probally suffer for it.

2.  Next find out which ones they have finished, if they do not finish any games then you also have a problem.
Then find out what they liked about it and did not like about it, and how they would improve it.  If they do not
know this then although they play games and could make games they will not be actively ensuring your game gets
better.

3.  How many finished projects out of all the projects they did and if not 100% then exactly why did they leave.

General Programming Part:

C++ Questions:
1.  Rate their proficiency with C++, range 0 - 10

 0 - 2
    a.  Scope:
        1.  What happens when an instant of struct or class goes out of scope.
        2.  How do you reference global scope variables when there is a variable of the same name in a closer scope
    b.  Public / Private / Protected areas in structs and Classes
        1.  Explain the difference of Public, Private, Protected
        2.  In C++ what is the difference between structs and classes
    c.  Encapsulation
        1.  Explain what means
        2.  Why you want it that way and when not.
    d.  Fstreams
        1.  Explain the difference between the << >> operators and the .Read(), .Write functions
        2.  Why would you use one over the other
    e.  References
        1.  Explain why passing references is usually better that passing by value or pointer.  
        2.  Why should not class functions generally not return references.

2 - 4
    a. Function and Operator overloading
        1.  Why are classes and stucts allowed to overload the operator definitions
        2.  When you overload the constructor does the compiler stop doing for you.
    b.  Virtual functions, VTable, and polymorphism
        1.  What programming concept does virtual functions allow C++ to support
        2.  Why do you make base class destructors virtual.
    c.  Conversions, implicit, explicit
         1.  Why is the difference between implicit and explicit conversions
         2.  How do you stop implicit conversion from taking place in functions
    d.  C++ casting
        1.  What are the four types of C++ casting operators
        2.  Why should you use them instead of the C style cast.
    e.  References, data members and const data members, mutable
        1.  How do you initialize a reference or const data variable in a class.
        2.  How do you make class variables modifiable by member functions that are marked const
    f.  Friend functions
        1.  Why does C++ need friend functions even though it break encapsulation
        2.  How do friend functions violate liscoffs substitution rule

4 - 6
    a. Conversion operators and temp variables
        1.  Why is return by value and pass by value considered slow
        2.  Why is providing conversion operators for classes considered bad interface design.
    b.  Memory
        1.  Why should you call the new and delete over malloc and free
        3.  When overloading the operator new and delete for a class why must they static member functions
    c.  Inheritance
        1.  Explain the difference between public, protected and private class inheritance.
        2.  If you are building an "is-a" relationship which type of inheritance must you use.
        3.  What purpose do pure virtual functions in an abstract base classes provide.
        4  Why would you put a constructor in the private section of the class definition.
    d.  STL containers
        1.  After what operation on containers should you reset your iterator
        2.  How do you get STL containers to not use the global memory pool
    e.  Const Correctness
        1.  Why is const correctness important
        2.  Why would you need to cast the const away on a variable.
   
6 - 8
    a.  Templates
        1.  What is the difference between template classes and normal classes
        2.  Why does the implementation of a template have to be in the .h file.
    b.  Namespaces
        1.  What is the keyword for bringing namespaces into your scope.
        2.  Why do you usually not bring namespaces into scope in the .h files.
    c.  STL adapters, and utils
        1.  Why should you not put an auto_ptr object in a STL container
        2.  What is a functor object and why is it needed.
        3.  Why can you not have std::vector of bool's
    d.  Return value optimization, named and non named
        1.  What is non named return value optimization and how do you set up your return values so compilers can do it
        2.  What is named return value optimization.
       
8 - 10
    a.  Exceptions and nothrow
        1.  Why do you generally not throw exceptions from constructors and destructors
        2.  When catching error types that are inherited from a base error type, which catch block do you put first,
            the one that catches the derived or base error type
        3.  What is the penalty for using exceptions in your programs and what happens to uncatched exceptions
    b.  Inheritance scoping
        1.  How do you bring non virtual base class functions that have the same name as a derived class functions into the derived class public interface
        2.  Why is it not considered good to overload virtual functions.
    c.  Template specializations and partial specializations
        1.  Most general containers need at least one specialization implementation for data type?
        2.  What is partial template specialization?
    d. Namespace lookup issues
        1.  Why does the namespace lookup for arguments of a functions start in the namespace of the function rather than the namespace the function is being used in?
    e.  RTTI ( Run Time Type Information )
        1.  Why can you only use RTTI on classes with at least one virtual function

Soft Skills for hiring programmers:

 Talents:
     Behavioral traits that are hard wired.
     Striving: Why people do things
     Thinking: How people think
     Relating: Whom and how they relate with.
 Knowledge: What you are aware of.
     Factual: Things you know.
     Experiential: Understanding you have picked up.
 Skills: Known "how-to" steps that have been practiced.

Talents that make good programmers:
Striving:  
1. A naturally driven person, if they are driven to be the best there is in there area of expertise they will perform way harder and just get stuff done better than people that are just around for the paycheck, fame, or because they think game programming is cool.
  2. A naturally curious person, they research topic, always want to learn and bring in good info into the team. They do not stagnate a fall into old repeating patterns.

Thinking:
  3. A naturally focused person, if they tend to gain focus for long periods of time they are 10 time more effective and productive that the average programmer.
  4. A natural finisher, follows all leads to conclusion, finishes all games and even stays around for the sequel once in awhile. These people do not leave your code base hanging undone, they track down bugs better, they research idea's better and do not start down paths without being somewhat sure it can work out. They stay around with code that they designed and wrote and learn what about it worked and what did not so they can improve for next time.
  5. A naturally wary and unassuming person. They defend their code against misuse and verify everyone else results and assumptions. Their code naturally detects and flags errors.
  6. A naturally creative person, these people will naturally find solutions to problems, and waste much less time than other programmer who have to find other people who have solved the same problems and such.
  7. A natural organizer, develop system for recording what they do, when they do it, how long it takes them. Notes they leave to themselves to get started again, bugs they have encountered.
  8. Naturally calm under pressure, when the going gets tough do they remain at their post or flake out and become unproductive.

Relating:
  9. How do they feel about and relate to other programmer, can they easily communicate with other programmers or do they like to be left along.
 10. How do they feel about and relate to Artists and designers, can they communicate with them or do they have troubles, do they respect what they do and their part in the game development process or do they look down on them.
 11. How do they feel about their past leads and producers that control their schedules. Do they respect authority, leadership, can they follow direct orders for the good of the project or do they have to get their way every time?
 12. Naturally good willed, they share knowledge or hoard it, they help everyone learn, or put other people down. 

Questions to test for these types of talents:

Striving:
 1. Ask them about publications they read, web sites they know about, books they read, classes they are taking.
 2. Ask them what they like most about the type of programming they do and what draws them to it.
 3. Ask them what their goals over X number of years are.
 4. Ask them about projects they do in their spare time, they should be working on things at all times, writing papers, giving back to the community, posting on newsgroups.

Thinking:
 5. Ask about the work environments they like and why, if they like quite environments without interruption for large parts of the day then they have the ability to focus and know how to take advantage of it.
 6. Ask them about games, demos and other projects they have finished. If they have not finish stuff in the past, it is unlikely they will start now.
 7. Ask them about tough problems they have faced and what their resolution was, if they did not deal with the problem, it is a bad sign.
 8. Ask them about working with other libaries and how they like dealing with it. If they talk about isolating for errors, validating data and results verifying their own data that they pass in then they are  wary and unassuming.
 9. Ask them about how they build libraries for other people to use. If they talk about design by contract interfaces, type safety, assumption testing and such then they are naturally unassuming.
 10. Ask them about solutions to hard problem they have faced in the past that had no known solutions, if they give you good resolutions then they are creative. If they play musical instruments, paint, hold patents, they also might be creative.
 11. Ask them about their daily schedule is set up, how it changes during alpha and beta. This while let you know how aware and organized they are. Also routine in the morning when they get to work and when they leave at night, do they do check in's at night or on Fridays?
 12. How do they approach tracking down bugs, memory leaks and approach optimizing code. If it is methodical then they might be organized.
 13. What documents do they generate while designing code. If they have specs, and interaction diagrams and the such then they might be organized. 14. Ask about then they performed the greatest and did the best designs and when they did the worst. If the worst is always in crunch mode then they do not do well under pressure.

Relating:
 15. How do they like to work with other programmer, do they talk directly or only like to go through the lead programmer. Do they consider working with other programmer to debug stuff a waste of their time.
 16. Do they like to deal with artists and designers directly or do they only want to deal with their leads or have everything filtered through the programmer lead. Do they consider working with art and design a waste of their time.
 17. Do they consider doing code reviews and design reviews with other people or their leads a waste of their time.
 18. Do they take schedules seriously and consider missing milestones a non issue, do they have a problem bringing delays and such up with their leads. Examples of doing so in their past.
 19. Do they feel ok about bring group or people issues up with the lead, producer, higher if needed, or to other people and have they done so in the past.

Experience that makes good programmers:
Do they understand that you spend 10 times more debugging and adding to code that writing it in the first place. Therefore you should spend some of your coding time making it easy for you do debug later.
Do they understand that documentation of the engine and test cases are the only way that engines live past one game and people lose the fear of making big changes in the engine.
Do they understand that code optimization and profiling can not happen in the last stages of the game and has to be designed as you go. That monitoring the performance of the game from start to finish is the only way to bad code does not get put in and then built on top of until it is impossible to remove.
Do they understand the mythical man month theory.
Do they understand the importance of daily build and source control and configuration management.
Do they understand the importance of sticking with the base design methodology the engine is started with and not trying to change mid stream.
Do they understand the importance of bug tracking software and putting everything in there since you often see the same bug more than once during the life cycle of a project. And it is the only way you know when a project is really done.
Do they understand the importance of letting the lead know what they are doing and tracking personal time and progress and ensuring it is on the schedule.
Do they understand the importance of being able to estimate their progress and how long it will take them to complete tasks.
Do they understand the importance of reviewing there designs and code reviews.
Do they understand what makes good code in the first place, easy of debugging, reuse, extensible, encapsulation, error handling systems, commenting, change propagation, code duplication, exception safe, unit testable, speed and ease optimize.

In Person Interviews:
    Get them to talk on a 5 min subject of their choseing about something they have done.  See their comunications and recall skills
    Get them to design a piece of platform independent code for some small task like dumping data out to an unknown archive ie file, net.  Judge the code
        based on encapsulation, change isolation, flexablitlity, error handling, debugging ease, exception safe, self documenting, reusable, typesafe.


Advanced Interviews for leads and such:
1.  Programming Projects
    a. Overal goals for what they designed, what did you like or dislike
    b. Patterns or methologies used ie Waterfall, Iterative, what did you like or dislike
    c. Unit testing suites, automated regression testing?
    d. Any debugging tools built into the app, how so
    e. Build any tools for build project,
    f. How was maintence / extend of designed / built or was it a one shot
    g. Automated Builds, Daily Builds?
    h. Source Control System?
    i. Code Review, formal or informal by lead
    j. Size of teams used, years of experience of lead
    k. How long was team together before project and on project
    l. How long was the project, how long were you on.
    m. Was there multiple releases done, were you on it.
    n. Lead scheduled tasks or your own schedule, like it or how did you do it
    o. Were you working from home or remote, what did you like it, dislike

2.  Design Projects
    a. Find out about all Projects they worked on and Level of design they were involved in
    b. Ever did SQA, SCM, or other releated engineering task, what did you like or dislike   
    c. Ever did lead or management position, what did you like and dislike

3.  Game Projects
    a. Quick run down the art pipeline, have you ever worked on it, tools wize, personal wize
    b. Quick run down the design pipeline, have you ever worked on it, tools wize, personal wize

4.  Personal Projects
    a. Play a musical instrument, Art, drama, martial arts or other creative activity,
    b. Books they have read on programming, project managment, list three current
    c. Monthly publications they get, assosiations they belong too.
    d. Have they taught any courses, tutored, are they published, gave talks
    e. Awards they they won, programming contests, reconistion by the industry
    f. Projects you are doing at home while you work.
    g. Technology or Area you are most interested in.
    h. Long term career goals ( 5 - 10 ) years and why
    e. Have you ever started own company or shopped for a publisher.