Choose what to work on
The best place to start is with something that personally affects you: for example, a small bug or glitch in a piece of KDE software that you use, or an idea you have for a new feature.
The personal angle will impart more motivation to get started, push through challenges, and finish your contribution to KDE. This isn't a requirement, but it's a strong indicator that you'll be able to complete the task as a brand new KDE contributor.
If everything works great for you, here are some other ideas for starting points:
Improve awkwardly-worded messages and labels that are written in English. This is a great way for non-programmers to contribute! If you can compile software and have a good grasp of English, you can make a big difference here.
Work on Junior Jobs, which are small tasks that are suitable for beginners (both bugs and features). You can find them available both on Bugzilla and Gitlab.
Work on bugs related to KDE's Usability & Productivity initiative, many of which are small and easy.
Work on 15 minute bugs, bugs that can be found within 15 minutes of using Plasma.
There are many other lists of issues you can take a look at:
The Usability and Productivity goal wiki page mentioned before has its own list of easy bugs you can tackle.
The Bug Triaging team has many search queries that can be useful to search for bugs.
The Gardening team has a stale merge requests list full of old merge requests with interesting but unfinished ideas. You can ask their developers if it's okay to take over the work on them.
Try not to start out by proposing or working on major features or significant design changes. These can be controversial, and the smoothest way to get going is by working on relatively non-controversial bugfixes. Start slowly and build trust!
Once you've got a general idea about what you want to work on, you can get in touch with the existing developers and they can help you out by pointing you to the right place in the code and providing advice about how to tackle the problem.