A really bad analogy (still gets the message across):
If GPU APIs were programming languages OpenGL would be Visual Basic. You're shielded from 90% of the more difficult aspects of accessing the GPU, for a performance cost. Vulkan would be akin to C.
For example: if you use OpenGL the GPU driver will tons of things (costing performance) to make sure that you don't update a texture while the GPU is using it - even if you know what you are doing (e.g. updating a portion of the texture that isn't being used for the render). Vulkan will get right out of your way and let you do what you want: even update a texture while its in use and potentially cause a bug/driver crash or other issues.
The interviewer made this assumption in the second question:
> Vulkan will “replace” OpenGL
Which given my above explanation you will see is probably not true. OpenGL is incredibly valuable because it's so simple - Vulkan and OpenGL simply don't compete with each other, they solve slightly different problems.
The OpenGL API no longer matches how the hardware works. As a result drivers are huge, unreliable, unpredictable, and slow. Mantle, DirectX 12, and Metal all cut away layers of abstraction and let applications drive the hardware more directly, without drivers getting in the way as much. OpenGL is getting left behind and Vulkan is the response to that.
OpenGL puts a lot of unnecessary burden on a CPU, while it is possible (now, on a modern hardware) to shift a lot more of the things a driver is doing to the GPU side. A new API is needed to reflect this.
tldr: OpenGL is great. But, the hardware model it is based on is long outdated. The mantra for the past decade has been "Do your work in huge batches if your want peak performance". But, modern hardware is very capable of getting great perf out of lots of small batches if they are set up correctly. Unfortunately, doing that in OGL requires complicated extensions to work around the old design (AZDO).
That's the big driver. But, there's also a lot of good improvements over OGL that can be made given the past 30 years of hindsight. Not the least of which is a much simpler, more consistent, more reliable, more maintainable driver model (ex: Don't ship a custom, rushed, underfunded compiler in every OS update of every Android device and just point at the spec doc when people complain that they each parse the same code slightly differently from each other.)
