Hi guys,

I am just about to graduate from Humber College (Toronto, ON) with an Advanced Diploma in Game Programming.

I would love some feedback and advice regarding my attached resume and my portolio linked below:

http://www.rohun-banerji.com/

My primary targets are Ubisoft and Gameloft as they are the largest studios in Toronto, as far as I know. Failing those, I wouldn't mind working at a Unity shop, although most of the other studios in Toronto are small mobile studios, which I am not very keen on.

Any advice and feedback would be greatly appreciated.

Thanks.

My thoughts:

• I am generally not a fan of "about me" sections or sections where you list out a bunch of "relevant skills" with "years used" values. I consider them to be content-free space-fillers. I assume you are interested in games since you are applying to a game development studio, and I assume you have at least a basic proficiency in programming (which I will likely test on my own). Years using a tool doesn't really convey useful information about your abilities; I want to see what you can do with a tool (and I expect to see that covered under your projects), not how long you've used it.
• I like that you call out leadership/mentorship roles in your education section. Expect to be asked about them.
• It's good you provide links to actual code on your resume (for R2DEngine). However, you should use a .gitignore to clean up all the user-specific and/or transient junk files in your repository (mainly the .psess and .vspx files with generated names, along with the .tmp files). It looks sloppy, like you don't care.
• The project entry for R2DEngine is the best one; it provides details (although more details would be better) about how and what you did what you did. The other project listings are less good; they just list extremely high-level tasks you performed without details on what that involved, why it was cool and why I should be interested in or impressed by it. I'd suggest fleshing those sections out.
• When you say that you "implemented something using the X design pattern," that's a red flag for me. It suggests you think about design patterns as pluggable pre-built solutions to problems rather than simple vocabulary. It's a hallmark of an inexperienced programmer, in my opinion.
• I don't think any of your "work experience" is necessary.

I'd suggest fleshing out each of your project sections with more details on interesting tasks you accomplished and why they were challenging or unique. Drop the "about me," "skills," (you can work these in by mentioning them in the projects section) and "work experience" sections if need be. Link to more source code if you can -- your R2DEngine code is a good start but after poking around the code randomly, I see several red flags that I'd probably ask you hard questions about at an interview. Consider dropping less interesting projects in the name of making your resume fit on a single page.

Thank you for taking the time to go through my resume and the advice. I will definitely make some changes based on them.

I am curious about the red flags that you came across in the R2DEngine project. I am in the process of developing my C++ knowledge, so I would appreciate any advice.

Are there any trends of incorrectness that you noticed or some specific things? (Other than the extraneous files - I will fix the gitignore to clean up the repo).

I poked around the repository a bit on the train ride home. Mostly randomly. Some things I think you should consider (you don't have to actually respond to these, but they are indicative of the sort of questions I'd ask in a follow-up conversation were I actually interviewing you). None of them on their own are serious enough to make me want to bail on the interview, but it's possible you could answer them poorly.

• The game ("RocketCommand") and the engine ("R2D") seem to be conflated in the repository which claims to be for the engine. On the surface this obfuscates the entry point to the engine.
• The base game class deletes copy and move operations. Why impose such a draconian restriction? There's nothing in the base class that requires it.
• A few other types seem to arbitrary force no-copy no-move semantics.
• Similarly, there's a lot of friendship here. Friendship isn't bad, per se, but it often raises questions as to the robustness of the APIs involved. Lots of friendship makes for messy coupling management.
• R2DGame::Update is virtual, but appears to do some pretty important stuff. This means subclasses need to call the base-class version or reimplement the functionality. Why not use a non-virtual-interface idiom to remove that sort of burden from the user?
• There's a lot of std::shared_ptr use all over the place. Why? Does it make sense to actually share the ownership of all these things? What are potential downsides, from a technical or semantics standpoint, of defaulting to std::shared_ptr?
• Why is RDebug a class instead of a namespace (not the only occurrence of this problem)?
• What is the point of RString when the standard has std::to_string, which you are actively using?
• How do you tell the difference between an empty file and a failure when calling FileManager::readFile?
• Why did you choose to implement "scripting" via C++ classes? How could you hot-reload these "scripts" as you might with other, more traditional implementations of scripting systems built on Lua or Python?

This is very helpful. I will definitely do some refactoring and thinking about the code.

Thank you for taking the time to go through it.

You have a lot of good things on the PDF, but some bad things too.

On your resume, the "technical skills" section is often a bad thing. At best it is mostly meaningless. At worst it is a terrible strike against you. There are people who cite many years with a technology that they only marginally used. Others use a product for years but only for the smallest tasks, never coming to an understanding of the technology. Still others use the technology only briefly, but deeply study the manuals and inner workings. CUT, and make sure the words are used next to the actual experience they go with. It looks like you already did this, such as putting "Unity 3D" and "C++ & SDL" in your projects.

Sometimes it can make sense to include all those in a "keywords list" at the bottom of a resume, especially when it will be processed by automated HR software. That is fairly common among very experienced individuals with 3+ pages of projects. Not so common for a fresh college graduate.

Your education section looks odd. All you did was get a scholarship? You didn't do any interesting projects in school that you want to call out? You write that you were a group leader for several group projects which can be good, but did you actually do anything notable as that? If so, call it out yourself rather than waiting for the interviewer to do it. Peer tutor may be good, but you tutored them for what? Math tutor? English tutor? List some amazing projects you did, or subjects you did amazing at, not just "President's Letters" which mean nothing to me. That is a good start, but can be much better.

Your "Game Projects" section is extremely strong. You will be asked questions about the details, as was just done.

So my advice is to remove the Technical Skills sidebar, probably remove the About Me section, fix your margins to traditional sizes, then reorder the sections into Game Projects, Education, Work Experience. Expand with some actual projects and results for academic projects.

I've made some updates to the resume based on the suggestions. I've removed the About Me and Skills section. I've also moved the Projects up and fleshed it with details.

How does it look now?

Better, but I still see cleanup needed.

Everything you have on there should fit on a single page.

Amazingly you have both too much and too little white space. I feel like it is all crammed all against the left side of the page. Breaking out the ruler, I see 1cm of space on the left, 4cm of space on the right. I see line breaks that are over 1.5cm tall. Tighten that up. Change the wording, get rid of the half-empty bullet lines, or modify the layout if you must, but get that down to a single page.

Despite your projects, you are still entry level with zero professional industry experience. Your projects give you a strong entry-level resume, but it is still entry level. One page.

Okay- down to one page. Hopefully the Projects section doesn't look too cramped, while providing as much detail as possible.

Thanks again.