Next he explained a few of the difference between working at a smaller scale company versus and large company. He recommended that we all start with smaller game companies for jobs. Not only are they easier to get into but they'll also be using your skills in many different aspects. This shuffling around will give you experience in multiple places in game development and maybe help you find you niche. Then once you have suitable connection it is significantly easier to migrate to a larger scale game company. Often times companies look at your completed projects and contacts before even looking at any sort of education you may have, if checking that at all even. Then out of all of the types of video games he said that mobile was the easiest to get into currently since that market is expanding more than most, then later you can consider transitioning into PC or a console based company.
So Ryan explained to us a few good ways to impress companies. The first way he said to impress them was to pick up an open-source API and build something cool with it. By doing that we'd be getting experience working with code that is not ours and showing that we can take something pre-made and develop something neat using it. The next thing was to improve your Server managing skills since many things are moving to Cloud-based, that way you can 'wow' the companies by being prepared.
Ryan discuss that in his personal opinion these were his priorities when deciding if he should hire someone:
- People Skills and Communication come first because if you can't communicate effectively it will be hard to work with you.
- He then checks how their brain works. If someone is of a similar mindset then they'll be more open to your ideas and easier to work with.
- Finally he checks their experiences and education, more oriented towards their experiences. He explained that companies want to see that you can complete a project rather than leave many half-finished.
A few extra side notes he left us with were:
- That readable code will always be superior to compact code. Just because your code has less lines in it doesn't make it any more coder-friendly. The few milliseconds you shave off with the compact code slows down the overall development time because other coders will have to decipher what's happening, rather than having the code explain itself.
- And then he listed a few goo areas for developers to get jobs.
- San Francisco
- Seattle
- Austin
No comments:
Post a Comment