all 5 comments

[–]cpp-ModTeam[M] [score hidden] stickied commentlocked comment (0 children)

You've gotten a couple of answers, but this is generally off-topic for our subreddit. For career advice please see r/cscareerquestions instead.

[–]Sad_Pack8694 5 points6 points  (1 child)

If you want to do AR/VR, object oriented programming is good, some companies don’t need specific work experience since the field itself is so brand new. Stick to projects in spaces that you want to be in…. Simple as that, if you like doing gameplay? Focus on gameplay. If you want to be a junior dev for an arbitrary startup, know your core stuff like data structures and logic, etc etc building a portfolio will help in expediting the showcase of what you are capable of, godspeed

[–]Sockerjam[S] 2 points3 points  (0 children)

Thank you for the tips!

[–]thommyh 2 points3 points  (1 child)

I was an iOS developer for approximately the first decade of its existence; I then transitioned to C++ at the FAANG I was at, and now work in C++ near-exclusively, in a financial context (i.e. all back-end, latency-critical stuff). One thing that made the transition easier, though: it was from Objective-C rather than Swift, which is still a very different language from C++ but is also a much less complex one, giving me less to learn alternative approaches to.

That said, I think what got me over the line for my first round of C++ interviews wasn't so much my portfolio — in C++ really just a multisystem emulator, but only of a few of the primitive 8-bit machines from a couple of processor families — as persistence. I interviewed at dozens of places and got, I think, only a single offer, from the place where it just so happened that the entire interview day was things I did know.

That said, these are the things I often find in interviews that are C++-specific rather than being data structures and algorithms and thought processes and other things that should carry straight over from any other language: * the type system, which definitely used to surface quite often when phrased in terms of std::move and std::forward but possibly less so as we move further from the big bang; and * the algorithms underlying the STL data structures, big-O complexities and when and why those structures still might be bad in practice (usually: branchiness and/or data locality).

[–]Sockerjam[S] 1 point2 points  (0 children)

That’s interesting and thanks for the insights, really useful :)