Features of a Successful Internship

Between my MS and starting a PhD, I did a few internships. One in particular stood out as a fantastic experience, and I've been thinking about what they did so right.

Things my mentor did:

When I showed up, he had a starter project in mind for me. It was a relatively concrete feature request that even had an interface stubbed out, which allowed me to get started immediately. It was also very well chosen as an entry point to the codebase - by the time I'd finished this project, I'd learned a lot and was in a much better position to work on production code.
My boss explicitly told me to ask for help after being stuck on anything for 15 minutes. Left to my own devices, I'll always struggle for longer than that, and I found that having an explicit guideline like that made me more productive.
My boss pointed me towards two things he wanted me to help improve (one in the simulation infrastructure, one in the production code), but I had a lot of freedom in deciding what the final solution should look like. He was also very receptive to suggestions I had for side projects: refactoring code, adding a related simulation feature, developing/improving library utilities, etc. I'd go to him for help prioritizing my work, but what I found interesting was also an important factor.
At the end of my internship, my boss made me give a presentation. It was a pain, and preparing it ate up the better part of a week. However, I treated it like a job talk, and it was a great chance to show off what I'd gotten done. Better yet - it was well attended, including by people outside of my direct team. This was yet another example of the whole group making it clear that the work I did as an intern was valued.

Project Culture:

Code reviews! I care a lot about writing clean code, and it's awesome to have other people look at what I do and suggest how to make it better. This is not exactly something that's emphasized in most corners of academia. This particular group cared deeply (obsessively?) about the state of their codebase, and were always willing to explain why they thought a particular design was better. I learned a lot about writing production quality c++.
They created a safe space for asking questions. Whenever I got stuck and went to somebody, they were patient and helpful. There's a huge difference in tone between "you don't know how to \<foo>?!?" and "Oh! let me show you how to \<foo>!", and I always encountered the second. After Hacker School, I've become much more aware and appreciative of such differences.
As soon as I was pointed towards a piece of the production code to try to improve, the whole team quickly gave me ownership - bug reports, questions, and hallway conversations came directly to me.
It didn't matter that my technical suggestions came from an intern - if they were good and I could back them up, they got implemented (and people were generous with credit for ideas!).
People consistently made a point of pointing out not only what needed to be fixed, but also what had been improved. After relatively minor fixes to some code, I got comments from the testers, my boss, my boss's boss, and my boss's boss's boss.
I found it particularly telling how well people reacted to my committing code that introduced faulty behavior during crunch time. My boss's boss was very matter-of-fact when he emailed me about it. The general tone of our discussion was: "Yeah, bugs are going to happen. What could have protected us from this one?", and my boss tested and committed the quick fix I sent in from home. There was an utter absence of any blame, shaming, or other pressure.

Company-wide policies:

While they wouldn't tell me any details about what I'd be working on while interviewing, I at least knew who my boss would be and a rough idea of what his team was responsible for. Without knowing what I'd be working on, I wouldn't have been interested.
On day 1, I had access to just about the entire company's codebase. This practically screams "we trust you." I've had friends in internships where they weren't ever allowed to see the main codebase - they were put in their own sandbox, and their mentors were responsible for merging in any changes. From now on, I'll be asking about this, and a case like the 2nd company would be an absolute deal-breaker.
They paid competitively. Not that I even looked at this when considering internships, but it seemed correlated with how the company regards interns. And, you can bet that it's one of the first things I mention to other students who ask about the lower-paying internship I had: "The people were nice, but you should know that Company B only paid 1/2 of what Company A did. So, if the projects are equally interesting to you, you can do better!"

I think that most of my points boil down to working with genuinely nice people, who made it clear that they respected and valued my contributions. Within the general priorities set out by my boss, I had a lot of autonomy, and at no point did I feel like my role or responsibilities were limited by being just an intern. In writing out this list, it also struck me how many of these were things a mentor doesn't have direct control over - most were at the team or even project level.