100

I have a short interview next week at a small videogame company for a programmer position. They are currently working on a new game, so I downloaded the demo and played through it. There are some bugs and a few objectively bad design choices. For example, enemies' names are displayed above them in black text, so when they are over a black background their names are rendered invisible.

I took screenshots of the errors I found (around 10). Should I comment them to my interviewer? I intend on explaining how I could solve the problems, so as to show I know about game design and software, and that I took the time to know their game and analyze it for improvements. I am also going to apologize in advance since maybe they have already solved them. But maybe it is seen as just criticizing and my comments end up having a negative impact. What should I do? The main creator of the game is not the interviewer by the way.

Edit 1: thanks everyone for your input, it has been very helpful. After the interview I'll comment how it went, so as to help others who stumble upon this question.

Edit 2: I had the interview, and it went great. Having read the comments here about how negative it could be to bring up the bugs and point out some design choices, I decided the best would be not to say a word (unless the interviewer wanted me to share my thoughts about the demo, and comment if there was something wrong about it or that could be improved). The interview was more focused about what my skills are, what would I want to do at the company, my studies, and my personality. Had the subject about the demo been brought up, the best approach would have been, like @Old_Lamplighter said, to rephrase any comments in a more positive way, while pointing out the good things. Thanks everyone for your help.

  • 3
    Does this answer your question? Is it acceptable to join a bug report to a job application? – gnat Aug 2 at 16:27
  • @gnat you're pointing to a duplicate of a closed question, neither of which have useful answers – Old_Lamplighter Aug 2 at 16:40
  • 1
    @Old_Lamplighter neither of that suggests that the same question has to be asked again. As for the usefulness, upvotes and accept contradict to how you describe the answer – gnat Aug 2 at 16:44
  • 23
    @gnat Thank you for time to help. But the other question is asking about WRITING a bug report to include in a job application. My case is different, I have been selected to be interviewed, and I am sure they expect me to TALK about the company's products and my input on them, and how can I be useful for the company. – ffff Aug 2 at 17:01
  • 3
    @gnat. and it was not the same question. Believe it or not, SIMILAR != SAME – Old_Lamplighter Aug 3 at 11:27
155

I can tell you that such an approach would be very brave, and by brave I mean it in the sense that running into the woods to fight a bear with no weapons or protection would be brave, and would net similar results.

If you went on an interview for a Chef's position, you wouldn't want to walk in the door and tell them everything wrong with their menu, which is what you would, in effect be doing. It would be better if you could point out bugs in their COMPETITOR'S work.

That shows that you can spot bugs without saying anything bad about your prospective future employer. If you MUST talk about their beta, point out what they have done well, and how you KNOW it's done well. If you are pressed for any negatives, begin in a positive way.

Well, I noticed that the game play is very smooth, and the AI works very well. If I had to pick something to change, I might either pick a different color for the names, or have the names change color if they move to an area where the colors match.

Notice how I didn't say it was a bad choice, but something that could be improved, and HOW? That's the approach you want to take in an interview.

| improve this answer | |
  • Comments are not for extended discussion; this conversation has been moved to chat. – Neo Aug 5 at 13:28
59

If you are applying to a QA-type role, then there is a lot of value to pointing out bugs in a beta. You instantly demonstrate your keen eye for detail and you can show your style of bug reports. Feel free to show off what you see as flaws to the game, but bring your justifications.

However, if you’re applying for a developer role, slow down. Developers always have outstanding bugs they haven’t gotten around to yet. If you just happen to nag an interviewer with one of their own outstanding bugs (and do so insensitively), that could make them hate you and you can say goodbye to the job. It’s possible to bring up a bug to an interviewer whose bug it is, but just remember to tread lightly. It is not a good look to tell your interviewer they did bad work, even if by accident.

EDIT - Adding more advice....

One thing game developers love doing is adding Easter eggs and charm to their game. For example, in the latest Animal Crossing game, the piranha has a default swim cycle around its tank in the aquarium. However, if you stand up to the glass, it chomps at you some. This is completely inconsequential to gameplay, but you can tell the folks who put that in did it with love. Go through the demo and try to find things like this that you really like about the demo and bring those up instead of bugs. It still shows initiative and interest in the product, but you're more likely to elicit a strong positive response from an interviewer when you discuss things you like rather than things you found wrong.

| improve this answer | |
  • 31
    Especially with something basic like the text being plain black; they might be waiting on the art department to deliver the backing nameplate, or the custom black-with-white-outline font for them to plug in and fix the issue, and are just using a stock-font (e.g. Arial) without a background as a placeholder. – Chronocidal Aug 3 at 8:04
  • 7
    I am a beta tester for a large company, and (private) beta versions often come with comments like "Feature XYZ is incomplete, so we do not want you to comment on it in this version." But of course developers and internal QA testers do sometimes miss "the blindingly obvious" simply because while focused on testing low level features, they carefully checked 1+1=2 and 2+3=5, but never tried 2+5 and discovered the program thought it was -93, not 7! – alephzero Aug 3 at 13:19
  • 9
    re"Developers always have outstanding bugs they haven’t gotten around to yet" -- A lot of people forget that in the tech debt metaphor, some level of debt is okay. The same way you go into debt to buy a house and pay it off, you may have to take on tech debt to get out a playable beta. I realize that UI issues are not "tech debt" but I think the same idea applies here. Also, especially since this is merely a beta, getting something playable to test the more subjective elements like gameplay balance is a much more immediate concern than some names being unreadable on some backgrounds. – Captain Man Aug 3 at 18:14
  • Good point. It is not for a QA job, but a developer one. I guess it's best after all to slow down on those comments like you say. I didn't get the chance to find easter eggs, that could have been a golden point. Thanks! – ffff Aug 7 at 13:47
48

Assume they already know about all the bugs you found.

Their app is in Beta. They have QA testers. They know about the bugs, and probably more that you haven't found. They shouldn't be using candidate interviews as a means of testing their own app, and it's highly likely they are not.

So if you do decide to bring up a bug, do so with this in mind. Remember that you are telling them what they already know, and they are definitely much more familiar with their app than you are. The point of telling them becomes a demonstration of your own ability to notice detail, and you can do this by pointing out holes in other apps too, ones unrelated to theirs. I don't suggest you bringing up a bug unless they ask for it.

If you'd like to tell them about the bugs you found, use the bug logging system they suggest (usually with a Beta, they'll post advice on what to do if you find a bug. Follow that).

| improve this answer | |
  • Yeah, yeah. I remember dozens of bug reports of every WoW expansion alpha with hundreds of confirming comments that stay with us until the buggy system is scrapped completely for next expansion. You're giving too much general praise to devs. It is strictly on case-by-case basis. And then, if they DID put beta up - it is exactly to gather bug reports. Whats wrong with complying with that? – Oleg V. Volkov Aug 5 at 22:20
  • @OlegV.Volkov absolutely they are wanting to gather bug reports in their preferred method of doing so which is probably going to be Q/A and some kind of user feedback form/bug logging system. They won't be gathering bug reports by interviewing candidates. – stan Aug 6 at 7:31
27

I worked in video games for several years. I recall getting the first build, playing it, and immediately speaking with my technical lead about some things I perceived as bugs. This wasn't pre-interview; it was in the first week of my being on-staff. My lead was totally open to the conversation, but not everything was accepted as a real bug.

I would say that 10 separate items is definitely too much; don't expect to expostulate on all of them. At most, have 3 such points ready to discuss.

But more importantly, focus on what skills the job expects you to have. Spotting and filing bug reports may or may not be a major job activity there. (Where I was, there was a dedicated Q/A department that took more of a lead on that.) The core skills you'll be expected to bring to the table as an engineer are the ability to fix bugs and develop new features. If you have examples of code you've developed or worked on, or any coding questions from the interviewers, those will be far more important.

Feel free to have 3 such items to possibly show your attention and interest in the product. You can look to see if it comes up in the interview semi-naturally. But don't force it, and focus on the more priority issues like your development skills.

| improve this answer | |
13

If you want the job, you should focus on making the other person feel great about hiring you so bringing up bugs on your own is treading very thin ice.

If you get asked, how would your skill set help this team/game/company, then you can bring it up; but don't call it bug or obvious design error. Bring up your ability to finish stuff that's currently in alpha/beta and your ability to polish.

Say something like:

I spotted several areas that would benefit from polishing, e.g. "insert X here". If you bring up the black names, acknowledge that this is minor.

This likely got spotted already and prioritized low. As this is not relevant to core gameplay, this will likely be done late in the project.

The core thing you should be conveying is that you believe in this game, and that you could help make it better. Engagement is a good thing in employees. Critical thinking is a core skill for a developer. A lot of managers are not developers, so you will greatly benefit from conveying your criticism in a more positive manner.

It's also super important to learn that unfinished products are exactly that: Unfinished. You don't criticize them for minor details. These minor details will (hopefully) be ironed out.

| improve this answer | |
6

I think this is a good idea. It's definitely an unorthodox approach. Personally I would wait for him to describe the company and their current product.

So if the conversation was like this:

.... Interviewer (I): "Did you do any research into our company or what we do?"

You: "Yes, I notice that you currently have a game called X available on Y. I went ahead and downloaded and tried it myself."

I: "Oh yeah, what did you think about the product?"

You: "It is very well and I like it. However, I noticed some bugs on it especially within the area of X, Y, and Z. If I was a developer, I would try to look into the A, B, C and would attempt to do D, E and F."

It might work. I think they're looking at you from the viewpoint of a developer/tester not a consumer leaving a product review. So with you being a programmer, I think knowing the bugs and what they might be is a good approach. If it is open source, perhaps even coming in with code might be a good bonus.

Now just to tell you the "I fixed the breaking part" is a bad idea. I recall a while back a story of a teenager who was interested in working for Apple. So what he did was hacked into the server and he either downloaded something or changed something. Apple was not amused by it at all and he got into big trouble but given his age, he was given a pass.

Then outside of that there is the story of the out of work plumber. Apparently his street had some sort of issue and he took it upon himself to fix it. He actually ripped open a natural gas pipe and was killed instantly.

Now during the pioneering days of the 80s and 90s when everything was brand new a lot of times companies would enlist hackers or people who broke their products. They're not looking for someone who just changed a bit but rather people who had a deep understanding of the underlying exploit and how to use it. I don't think that approach is a good way anymore. I don't even think the people during this timeframe was looking to get hired this way but rather just was curious or didn't realize their deeds would do so much damage.

So in all though, I think the "I fixed your broken product" is a honest approach, but risky. It's risky because you're trying to impress them by fixing a broken something and it might cause confusion or even anger to some degree depending on how you fix it. Best to just say you downloaded it, and give some insights as oppose to trying to fix it by doing anything bad like reverse engineering it or hacking into their stuff.

| improve this answer | |
  • While this answer is a bit rambly I agree with the sentiment - and which is not a popular approach given the other answers. I guess I think differently than most people. More interested in facts and less interested in touchy/feely. Someone gets their feelings hurt by having bugs brought up? Why is that?? But it's instructive to see just how pervasive that attitude is. – javadba Aug 3 at 19:32
  • I agree with Dan, specifically that it takes tact. I earned a development job this way, specifically by - towards the end of the first interview, after having already made a good impression - mentioning that I didn't want to hurt that impression, but felt responsible to disclose I had discovered what appeared to be a serious security flaw in their systems that was subtle, but quite public. More interviews, a job offer, and months later I was introduced to the CEO by this story, being "that guy saved us, now he works here, ta-da!" – CodeShane Aug 5 at 6:04
  • +1, I have been involved in a few job application talks on the employer side (non-game-related). I would probably be impressed. Not only did you take the time to test our product, you also made a presentation about it and are able to pinpoint problem zones. Maybe focus on the design choices instead of the bugs. If I was looking for a developer, I'd want someone who is motivated and able to proactively make our product better. If this is an interview with the tech lead and not HR, this could lead to an interesting discussion and give a good impression on whether or not you are a good fit. – Cerno Aug 5 at 14:57
  • I don't get what's wrong with "I fixed the breaking part". The problem that Apple had is somebody getting in their system - it is absolutely different to fixing openly available code. – Oleg V. Volkov Aug 5 at 22:23
5

Most of the other answers are far too negative, this is a great idea but it needs to be done properly. It would be easy to come across as "you guys are a bunch of bozos and I could do a better job", you want to show empathy and interest.

So you say something like "I downloaded the demo of XYZ it's great I really enjoyed using it especially ABC, I appreciate it's early days and you guys probably have these in your bug tracking system but I noticed (issue a) and (issue b)." Preferably these are not glaringly obvious bugs or graphical issues (often the last thing to get sorted) but something that shows you took some genuine time and interest to test it all out.

| improve this answer | |
  • You are right, that positive way of explaining the issues is what would work best. – ffff Aug 7 at 13:59
2

For the most part I agree with all the other feedback that you want to leave a positive feeling from an interview, so giving criticism is risky at best. Additionally the interviewer probably isn't even the right person to share such things with, so it wouldn't even work if they're open to it.

BUT, an alternative which I could see working is that if they are asking for community feedback at the moment - which some, but not all pre-release games do1 - to send in what you collected and during the interview try to find a spot to casually mention you did so. Best case a nice situation presents itself and it leaves a good impression, worst case you won't mention it or they just won't care.

1 The reason they might not be interested at all is that they already have a backlog of known issues and they will only start collecting feedback once they reach an RC stage.

| improve this answer | |
0

The closest I would get to mentioning issues in an interview is to highlight you played the game though enough to have thought about their design decisions. Maybe from there you could lightly tread on things you would like to be different. Those comments need to be carefully wrapped in positive energy. You want to communicate that you'd be excited to learn from the developers why they did things, not that you feel qualified to second guess them.

Bringing up outright bugs in an interview is corporate suicide. Shoot, bringing up bugs is super sensitive even for senior employees. Any time you're working with other people and bringing up a problem, you should consider that a) the person you're talking to already knows, b) they've tried to find resources to fix the problem, and c) they're pissed at someone that the problem is there. I'm considered a very straight shooter, and I've watched people lose their minds in anger when I confronted them over what turned out to be a well known problem in their software. Learning how to approach those conversations is a serious career skill.

| improve this answer | |

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .