In an interview with a small video game company, should I comment about bugs I noticed in their game?

Question

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.

Answer 1

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.

Answer 2

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.

Answer 3

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).

Answer 4

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.

Answer 5

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.

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.

Answer 7

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.

Answer 8

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 do¹ - 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.}

Answer 9

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.