yes …you cheater 
Every problem is completely different, so learning how to read, comprehend, & solve algorithm challenges is almost its own language that starts to make more sense over time. Ultimately, it becomes more of a pattern-matching exercise of relating the current challenge to similar ones you’ve seen before.
When you aren’t familiar with what a given problem is asking you to do, it’s not trivial just figuring out how to properly extract the inputs and format the outputs. If you know nothing else, appreciate how conceptually all your solutions have to do is:
- extract the inputs
- transform that data
- export the outputs
I certainly remember overcomplicating the first ~10 problems I ever approached: they were only challenging because I didn’t understand precisely how they were (1) trying to feed me the inputs, and (2) expecting me to display my results (especially when they wanted me to handle multiple test cases).
Most people bite off way more than they can chew at first. I encourage you to think about solving algorithm challenges like lifting weights. Not everyone needs to lift weights, but if you decide you want to become stronger:
- Sign up on HackerRank (or LeetCode, although HackerRank has more “Day 1” stuff)
- Navigate to their “Algorithms” section
- Solve the absolute first, most basic warm-up question
- Approach the next, incremental challenge
- And another one…
Pro-tip: from here on out, some challenges may provide “boilerplate code” that handles the inputs and outputs before you’ve even touched the problem …I encourage you to completely wipe these crutches after your first few problems. From here on out, this is an awesome exercise for getting comfortable with different corners of your language, especially “handling I/O”.
This will introduce you to their text editor/environment, allow you to choose your language of choice, and begin building your confidence by dozens of small wins week after week. The best part about this for beginners is building your first base of competency. Confidence doesn’t come from being great at everything as much as feeling ownership over one specific thing, no matter how small.
The sooner you feel comfortable saying “I’m actually pretty comfortable/good with X language/tool/technique,” the sooner you’ll really start identifying as a developer. That identity-level shift is what makes all the difference so do everything you can to lower that barrier-to-entry, whatever that means for you.