Stop telling people you are "old" then. Say you have 5+ years of experience. Shorten your work history. Don't lie anywhere, just don't say as much. If you are as desirable an employee as you think you are, and people are just discriminating based on age, then that should at least get you more phone screenings. It won't help so much when you get the in person interview, but you have to start somewhere.

For the Visual Studio example, most users won't need to escalate. The two things I can think of off the top of my head that would require escalation from Visual Studio are profiling and attaching to a process from another user (including the "real" admin). Compiling / linking doesn't require an escalation, and debugging an application that you launched doesn't require an escalation.

And as I understand it the Microsoft devs go one step above UAC. They usually run as a limited user, so that you can't just click the "ok" button, you have to type in the admin password to escalate.

Or maybe the gray colored process line is just the last selected process, which makes way more sense.

If you look closely, the first time the video shows process explorer, the PID of the parent chrome process is 1388 with integrity at "Medium", and a child chrome process's PID is 1928 with integrity set at "Low". After the hack, process explorer shows a child chrome process with PID 804 and integrity "Medium", all other processes except for the calculator are obscured. I can guess-timate that the original parent and child are still there though, as there is still a low integrity process somewhat near the bottom of the list.

After looking at the documentation for process explorer, the gray colored process line (most likely the parent chrome process) is suspended, which seems odd. I'm not entirely sure I'm seeing the correct part of the process explorer docs here.

Another thing to note is that the calc.exe process has no parent. That means that whatever spawned it has already died.

The video suggests that a fairly standard ASLR attack was made: guess and check. ASLR makes it difficult to reliably guess an address the first time. Most of the time, if a hack guesses wrong, the process dies and the attacker doesn't get another chance. It seems that the attacker found a place (or made a place) where they could "guess" repeatedly. Given the prior information, that suggests that the child process somehow caused the parent process to repeatedly spawn chrome subprocesses that had some attacker controlled information in it. Each time, that information is probably a little bit different until the attacker guessed "right", and successfully executed the right attack code.