(中文版本)

My name is NDark, a game developer in Taiwan who sees organizational behavior as the Holy Grail. Those who have been following my articles throughout the years know I care about organizational behavior (which entails team, management, and culture) as a soft skill more so than creativity, technical abilities, game design, as well as marketing. I have also given talks on related issues in community gatherings including: "fallacies in communication" as well as "colleagues who are inclusive of different ways of thinking." Many years ago, I once unapologetically said that: "(Taiwanese) Bosses do not understand how to manage employees, nor do employees understand how to be managed." After many years later, today I would like to further expand my statement with additional points:

"We should care more about management, that goes for not only higher management but also front line developers or employees. Management should not solely be the responsibility of managers, as employees you should also care about management. Ask how the team should function; ask how team members should work with each other; ask who your colleagues are. Moreover, these should be done with a perspective of diversity and inclusiveness.

Management is a form of applied science. There is no absolute correct answer. Nor can one simply replicate the methods of others. The heart of the project lies within people, that how to make sure that team members feel comfortable and supported, how to make it so that members of the team feel that they are in control of the project, and not the other way around. Only then can the team show commitment, and allow the project to proceed on schedule. In regards to team production and culture-related issues, back in late 2014 with the title "Game Outcomes Project" we published articles on team production as well as the effects of team culture on game development.

Throughout my time working in various teams, in recent years I started researching on how we should interview game programmers. Regardless of the scale of the company, I believe technical employee turnovers have actually significantly harmed project developments. Sometimes projects may end directly as result of turnover, whereas sometimes it would double the length of the development schedule. This is an important issue that project owners (e.g.: team members, investors, or bosses) should pay great attention to. However my society seldom talks about this.

Another signal which made me realize the importance of this issue came from my own personal blog. Eight years ago I wrote an article for beginner recruiters:. "An Introduction to New Recruiters", followed by "The day-off policy in my team." written four years ago. Surprisingly, these articles from my blog ranked numbers one and two according to the Click-through rate of search engine results (Organic Search Traffic). This made me realize: there are actually a lot of people who really need information in this field. Many managers are promoted due to their technical skills and rarely management skills. And only when those rookies start working do they begin to realize that they require such information. Yet, most companies have not invested enough effort to help strengthen those related skills so the managers can do their jobs. In addition, the "mentor-apprenticeship" system and politics in Taiwanese work environments would also prevent those rookie managers from learning these techniques while working in their respective organizations.

Before the article begins I quote from my article "An Introduction to New Recruiters": "The first thing that recruiters need to pay attention to is to understand the purpose/goal of their recruitment each time." To emphasize one important point in Management: "There is no so-called standard answer, only whether if the approach is appropriate or not. This also means that although an applicant may demonstrate excellent skills, he may not necessary be suitable for your team or project. This is because projects have their own different development stages, from designing, prototyping, to mass production and finally online product, all of which require different people. There are also different requirements for various programming positions, from gameplay, systems, tools, to Technical Director, Chief Technical Officer. Sometimes the problem is not just technical skills, but more importantly whether if the candidate is capable of working in teams and adapting to team culture. The professional development of a technical position is non-linear and can offer multiple possibilities. Some candidates are capable of dealing with unknown challenges; some are good at maintaining existing products; some are adept at research and introduction of cutting-edge technologies; and some are great at organizing and sharing documentation. Newcomers have their own advantages (like a blank piece of paper capable of accepting the influence its respective corporate culture) as well as disadvantages (unable to act independently and require instructions as well as scope). Whereas a veteran is the opposite that upon joining the organization he or she goes to work immediately with existing knowledge. However, that individual tends to bear burdens from previous engagements.  

Irrespective of what position you hold in your team, before you start reading, ask yourself these questions: "What kind of person is capable of acting as your teammate? Have members of the team encouraged mutual discussions and consensus among themselves in regards to this question?"

Performance

Let’s first talk about results, in this recruiting process, I interviewed about twenty-five candidates for client-side programmer. Only 12% or 3 of them successfully made it into the next phase (to be interviewed by the Producer). There are men and women among them, including experienced as well as entry-level candidates. Lastly, only one person was successfully recruited into my team. After this individual joined our team, he received public recognition within three months. To me, this is like the part where points were awarded to the students of Gryffindor. But since I was not in charge of this team member, I believe I only deserve half the credit for the outcome of this experiment. Please take my experience as reference and discuss among yourselves for more appropriate strategies.

For each applicant, I interviewed them with the same existing evaluation methods. In addition I also used the same scoring standard so that I may evaluate the results after the process. Basically, I confer points to each evaluation criterion when interviewing applicants, and I would check to see if the outcome complied with the pre-defined line, except under special circumstances [1] where we would apply an additional method. Scoring evaluation is objective. However, the content is usually subjective depending on the recruiters. For the content, I used in-depth interviews as well as cross-questioning in order to understand whether if each individual candidate is suitable. And lastly, as "Joel on software" said, the end result would be reported to my supervisor (Producer) to decide either "pass" or "reject." Upon acceptance, the manager will begin the next stage.

There are 3 parts to the whole procedure, including a psychological test, interview of candidates’ past experiences from previous projects, and a technical test. The whole process takes at least approximately 1.5 hours, thus, normally from the process would begin from 10 o'clock in the morning and continue until noon. The respective details are as follows:

Technical Test

The technical test is used to test the technical proficiency of applicants. The test itself is actually not the most important part, but a required safety measure which we can use to flush out dishonest candidates, meaning people who although may be able to present a pretty resume, and handle interview questions with ease, but cannot actually handle source code. I know most software companies and game studios frequently use the following tests to evaluate their candidates: syntax test of programming languages, APIs, data structures, algorithms, practice coding questions, assignments, or even an intelligence test. Some are conducted on-site, online, or done remotely within limited time. However I have decided not to use any of them, because first of all, from my point of view these tests do not necessarily reflect actual project developments. Honestly, I do not understand if being capable in "double/triple pointer operation", memory accessing, implementing and comparing all kinds of sorting algorithms, or even reciting those object-oriented principles have much to do with the success of the actual project. These criteria would only prove that the candidates have worked hard to handle textbook questions and Leetcode. Secondly, these tests take hours to design and to be practiced. For each of those applicants, the outcome of the interview may mean life or death, and thus to ensure that they have the correct answers, most of them would attempt to reaffirm their answers, making the process exhausting and inefficient for both parties.

Instead on the contrary, I attempted to visualize how we can design the technical test from a realistic perspective. This also means whether if I can design a simulated environment that emulates what we do every day. The purpose of the test is also to verify what I expect from those candidates. This echoes with what I mentioned earlier: "The first thing that recruiters must do is understanding the purpose of the interview."

To every Programmer reading this article, ask yourselves this: "Do those algorithms, OOP, syntax, or API matter to your development?" "Do they matter to a point where you use them in every day development?" Even if the answer is yes, I think they would only take up a minimum amount of time (maybe one week each month where we actually handle those architecture and algorithms). Seriously, what do we actually do most of the day? I think the number one thing we spend the most time doing is debugging, with some bugs self-made, others made by fellow colleagues. Therefore, for most of the time we are actually not designing algorithms, nor designing architecture, but debugging, especially when we spend lots of our time reading other people's code, and try to figure it out what's wrong, as well as how to continue modifying those source code.

The answer shows that my technical test was designed with this in mind: that is I want to design an environment in which the applicant is required to read source code and discover bugs or bad code with me. What’s more important is that I want to observe what kind of attitude and rationale candidates would use in order to solve problems. I will even use words to see if a programmer can communicate logically with people next to him/her while under pressure and interference. Moreover, can the candidate accept other people’s ideas?

Therefore, I used our online programming language (C#, I even built the corresponding C++ version as well) in addition to the developing environment (i.e.: Unity), to deliberately design a series of problematic code. I would then have the applicant read the code and ask the candidate to find the intentionally created bugs or bad code. For each individual, I would first introduce the purpose (requirements), and let the candidates read those lines of code (this is to test candidates’ ability in reading other people's code), followed by cross-questioning discussions on the code (to test communications skills). I would attempt to reveal clues to those responsive candidates to guide them through. This is to see whether if the candidates can successfully pass the imposed challenge, and see if they can discover clues through communicated hints. Irrespective whether if they have passed or not, for those who have communicated successfully, I would explain the characteristics of the bad code to responsive candidates, whereas I would just skip those who have not communicated whatsoever and end the session. I might not even reveal the answers to them.

Please remember problem-solving skills are not the only indicators, what is more important is how candidates interact with their recruiter for it means how they will overcome challenges after they join.

The number of test cases conducted is determined by the amount of available time. On average I conduct five cases including 1~4 programming skill-related, 1~2 Unity-related. Normally it takes from half an hour to one hour, with one case requiring ten to twenty minutes. (To be honest, these test cases didn't take less time to complete than the written test) I did not time this round of cases for the most part as I did not wish to see slower applicants perform below expectations due to time constraints. However, perhaps in the future I might attempt to simplify the content to allow better control of time.

A Small-Scale Psychological Test

With exception of the other two parts which both take one hour to complete, this psychological test only has one question, and usually takes less than five minutes. I also did not score it, meaning pass or fail has nothing to do with the outcome of the psychological test. There are two purposes to this test, and the first is to weed out liars. Should there be an obvious discrepancy between the responses during the interview and the responses from the psychological test, then the outcome will be seen as a red-flag, prompting me to probe deeper. Secondly, I wish to find out what essence of the team or the company matters to the candidate the most. This is so that should we continue as a team, we can provide the chosen candidate with support in that aspect.

This psychological test was designed in accordance to a manga titled "女医レイカ" and the background was basically replaced with career anchors. To be frank, I find the criteria to be quite accurate.

Interview on Past Experiences

The most important part of the three tests is actually the interview concerning past working experience. This part would usually last for about one hour. I would attempt to understand the tasks handled by the candidate in past projects, and then meticulously ask the candidates how they carried out their tasks. Likewise with the technical tests, the interviews serve as simulations of the future working environment and conditions. The following is a few principles used for the interviews:

And then I would list questions that I would usually ask. At the same time I would explain my logic as well as reasons why.

Q&A from Candidates

After recruiters complete the three parts, we can then answer questions that candidates may have towards the vacancy. I’ll spare you the details, because I only interview for technical positions, I only answer software-skill questions relevant to the team, including: composition of the technical team, what tools do they use? Current division of labor, potential development tasks in the future etc. I would hereby suggest, besides non-disclosable items, be honest and inform applicants of the team’s status, such as overtime, team atmosphere etc. Because since applicants are asking those questions, it shows that they care about these aspects. Even if you choose not to tell them, once they discover the truth, they can leave without prior notice within the first three months (according to Taiwanese Labor Law). The damage will still be suffered by the project, the team, as well as the company. Thus, it is more preferable to be honest instead of being disingenuous. If parts of your development require immediate remedy, please consider outsourcing.

Conclusion: Compatibility

Here I must reemphasize career anchors. In my speech I once mentioned that I can recognize 8 kinds of programmers according to the theory of career anchors, and each programmer has his or her own individual career viewpoints. However, they may all be technically qualified experts. If we only base technical qualifications as the criteria, then we are simply treating employees as machines, machines that work well once oiled and calibrated, then there wouldn’t be so much drama in the world. We may also be gambling on whether if we can change in order to accommodate this newcomer. I hereby present a modified version of Carly Fiorina’s quote: "I have seen many different programmers, some of them I respect, some of them I would never want to work with again." However, I believe each programmer has his own matching project and company. There is no absolute good or bad applicant, just whether if the candidate is suitable for the position or not. Of course, it is difficult for an applicant to acquaint himself with a company in just one or two hours. By the same token, it is difficult for the recruiting company to understand the applicant’s background. But since we are gambling, we should also use different approaches to increase our chances of success. Human resource is an important topic for amu team and company. During this process each individual should utilize every opportunity to discover the true corporate culture of their respective firms, as well as discover employees who can integrate with the culture. Only then can a multi-win outcome be achieved.

Lastly, each recruiter has his own recruiting methods. Now, I would suggest that you place greater emphasis on "compatibility" (or compatibility with team culture in other words). I am a Programmer, which clearly means that I use scientific methods o try and establish rational evaluation mechanisms. But as I have mentioned previously in the section pertaining interviews on previous experience, we should be more inclusive of other approaches. I also believe to certain experienced developers, whether recruiting by instincts or seeking like-minded individuals, the point is finding developers who identify with the same cultural background. Using instincts is not a wrongful approach, but regardless of which method you use, try experimenting and amend your individual goals and methods. Try not to let "every day sentiments" or "the pressures from work and life" affect your judgment in recruiting of potential talents. Choose someone incompatible, and the project may not only be impeded, it may even be set back. Please be cautious.

[1] Remedies Under Special Circumstances: When dealing with applicants who have never made games before or are recent graduates, since they have no previous game development experience, it is difficult for us to use in-depth interviews to understand their methods applied in previous projects (hard to ask questions for they have no previous experience to share). If we encounter a situation like this, we would ask during the interview whether if the applicant is willing to accept an assignment (to help them attain a simplified project experience). Should they choose to accept, only then will work be assigned. As for the assignment: It involves a full work cycle, and includes a scene and operations among the scene. This is to see whether if the applicant can understand the requirements. Applicants can write to us to discuss, with no time limit set (this is actually a method of entrapment). After the assignment has been submitted, we will then arrange a second interview where we would engage in heated discussions over code. This is to simulate a full typical work cycle at our company. We use this to test applicants (usually inexperienced) to see if they can handle the conditions. See if the designed environment is just as the applicant imagined. As for developers who have previously worked at a game company or have developed projects before, should they fail previous evaluations, they won’t be given such special treatment.