I'll leave the attitude issue alone, but I'll also reinforce that you really do need to know how to work with others -- and I don't mean getting along with them, I mean working in a group setting collaboratively.
Firstly, you need be conversant in programming, which simply making some games doesn't prove on its own. It means when your mentor or lead says "Here's what I need you to do. I'd like you to use the Visitor Pattern." or "We don't use Singletons here." Those statements actually mean something to you, and aren't just giving you keywords to go look up. Extra research is fine when implementing things, of course, but you need to be able to talk about those kinds of things around a boardroom table in front of the studio head and not look like a fool.
Secondly, programming in a team is very different than programming solo. You need to know lots of little skills -- You need to know how to file a well-structured bug against another programmer for instance, how to use source-control software in general (Hopefully you are using one yourself already) but even with those basic skills, working in a repository with multiple people making changes and merging them together is much different than you making and merging changes all on your own. You also need to be able to deal with schedules, make good time estimates, and keep to them as well as you can -- when working solo and it takes longer to do something than you anticipated it sucks enough, but when you do that on a team you might be holding them all up too (protip: don't be the guy burning hundreds or thousands of your employer's money by holding everyone else up).
Thirdly is baseline skill set, knowledge base, and good coding style. These are the table-stakes of getting in, and if you don't have them, no portfolio will get you in no matter how good the results are. This basically means that you can talk intelligently about code and about design problems, that you have a good overview of contemporary and appropriate technologies, approaches, design patterns, and idioms -- that you can talk about them and recognize when to use them or not use them, and that you have a natural grasp of what good code looks and feels like -- and not just the code you write, but also the interfaces your code provides for others to use, and that should enable their code to look and feel good too. This also includes relevant areas of mathematics -- mostly linear algebra, and a smattering of quaternions, geometry, statistics, calculus.
If you've never collaborated on a project before, I suggest that's a good place to start. You can attempt to spin up your own project, but its probably easier to find a project that's looking for help and offer your services to them. Depending on what your skill-level actually is, you'll want to find a project that's at, or somewhat above your skill level if you can -- if your skills aren't entirely developed yet, you might find that some projects with a high-caliber team might not want your help, even for free. Just take that as something to aspire to, and a clear sign that you're probably not ready for an industry position anyways. Something at your level will let you develop the kinds of skills I talked about above, something a bit above your current level will do that too, as well as challenging you to grow your solo skills.
