If you were just trying to implement a particle system for the sake of getting it done, I'd recommend you keep it simple, and generate all four vertices on the CPU and submit as indexed triangles. In a simple 2D title, neither of the more complex approaches are likely to make any material difference to the final performance. However, it sounds like pushing yourself to learn new techniques is a big part of why you want to do it.

I think instancing doesn't bring much to the table for a particle system. Per instance, you'll need to send position, size, rotation, texture coordinates and it probably won't end up measurably faster than generating and sending all four vertices.

If I understand what you mean by the geometry shader/transform feedback approach, you're talking about using the vertex shader to update your particles using transform feedback and the geometry shader when rendering to expand a single particle into a quad. That sounds much more worthwhile both in terms of learning about interesting parts of the pipeline, and for getting some impressive particle throughput if you want to reuse the system for future demos.

I'd recommend you still start with the CPU approach first though, that way you have a reference point to check that your fancy rendering path is producing correct results, you have a fallback path for older graphics cards that you can use for your game, and you have a reference point to measure the speed boost against (in a job interview situation it's always nice to have solid performance numbers if you're talking about optimisations you made).

Geometry shading is one of those things that looks great on paper and works terribly in real life. You're better off driving particle systems from the CPU. Also I've found that once you move into production with actual art goals, instancing doesn't help a lot for particles either. There's too much you want to do and instancing isn't very helpful for performance. It's easiest just to keep a double or triple buffered VBO (two or three buffers marked GL_STREAM_DRAW and switched every frame), and write the vertices manually.

Here

I had seen the slides before but Valve released the video. First thing in the talk is a way to efficiently manage buffers for particle rendering.

The bad side is that the solution depends on ARB_buffer_storage. Which is a very, very new extension (as in only available in OpenGL 4.4 hardware). Though it explains why the conventional approach is slow, so you might get something out of it anyway.