superrad
The tutorial probably should have instructed you create box colliders for walls (giving a greater area for the physics engine to catch collisions) rather than a simple plane/quad which would lead to the exact issues you had, or at least explained why a box works better than a plane.
I guess you have to balance the necessary information with overload in your tutorial or at least have an aside or additional reading that really helps understand many of these internalized understandings.
Game development is full of domain knowledge like this because games need to make compromises ensure completing simulation updates at no lower than 30Hz.
Even without the incremental GC it's manageable and it's just part of optimising the game. It depends on the game but you can often get down to 0 allocations per frame by making using of pooling and no alloc APIs in the engine.
You also have the tools to pause GC so if you're down to a low amount of allocation you can just disable the GC during latency sensitive gameplay and re-enable and collect on loading/pause or other blocking screens.
Obviously its more work than not having to deal with these issues but for game developers its probably a more familiar topic than working with the borrow checker and critically allows for quicker iteration and prototyping.
Finding the fun and time to market are top priority for games development.
I get that it's less conventient to have to remember a bag but it's not some insurmountable task and it does seem to reduce the amount of plastic bags that get caught by the wind and blow around as trash.
For things like ship preorders on Star Citizen it's much more of a risk that the value will ever be delivered but it's still offers more than just a note of ownership of an abstract token on a blockchain sequence.
If someone decides to honor these tokens as proof of ownership of property/items in the real world/ a virtual world then they may offer some value but there's a very great risk that will never happen.
For your other points if you'd mentioned them in the interview you'd probably have been better received. Copying is really only that fast for POD objects (your objects copy constructors may need to do reallocation themselves or worse) so if you're suggesting a general solution you should be aware of that (or at least mention move constructors if they were available at the time) .
I would be surprised if any of the games you worked on actually shipped with an amortised resize of dynamic arrays (at least not for anything that didn't matter in the first place) so I don't know why you'd suggest it as a general solution in a game dev context.
There's also the cost of copying objects especially if you don't know if the objects you're copying from your original array to the resized array have an overloaded copy constructor. Why copy these objects and incur that cost if you can choose a datastructure that meets their requirements without this behaviour.
If you're holding pointers to these elements elsewhere re-allocating invalids those, and yes you probably shouldn't do that but games generally are trying to get the most performance from fixed hardware so shortcuts this will be taken, its a least something to talk about in the interview.
I can see why they were confused by your answer as its really not suited to the constraints of games and the systems they run on.
If your chip is too large it can even make it practically impossible to manufacture at scale due to the increased chance of defects as your chip size increases.
They surely can't get too much of a return paying people to check up on only potential licence 'evaders' so investing in a fleet of actual vans with drivers and operators would further reduce any return.
I mean its certainly better than the Titan X (Maxwell) which could only address less than half it's memory while running at 60Hz.
It just seems like an effort to inflate the price of the product without adding much value.
If a code base doesn't change too much in side or original intent then architecture and design (if it was good in the first place and is continued to be followed) will probably keep it fairly maintainable.
In a lot of cases though codebases slowly grow until they become of a size that requires a different architecture or approach to organising the code, especially if the number of collaborators increases too. It's quite a hard thing to spot and then address while that codebase is still quite active.
Rewrites are tempting to be able to apply that architectural change but often you can be quite bound by the implementation specific behaviour of the original system.
It might be interesting to look how the linux kernel has changed internally as it moved from a single person project to what it has become today.
vs
auto it = hashmap.begin();
I find auto useful for cutting down some of the verbosity of templates STL containers, but I can see how over use can lead to code requiring much more referencing if maintaining code that rarely defines types.
Do you get any meals subsidised from your university, and do you actually have some savings while being able to eat out or get drinks at least once or twice a month?