Leetcode 2

Leetcode offers three difficulty levels: Easy, Medium, and Hard. Solving harder problems obviously gives you more rating points. But right now we don’t care about the rating — we care about how the company you’re interviewing with views your profile.

To recap: we focus on real skills and abilities, not on a rating to show off. So we solve problems for ourselves, not for appearances.

The reaction from the company — or, more often, from the person running the interview — to your profile can vary:

• some will decide that a high count of Easy problems isn’t a sign of strong preparation and will expect at least Medium-level work from you;
• some will say “great, I’ve solved fewer than that” — and that’s a case where your engineering chops matter more than the algorithms;
• some will recommend solving Medium and Hard problems — most often a fairly useless piece of advice.

Let’s address one negative aspect that’s hard to leave unsaid when discussing the algorithms section: in the interview you’re expected to compute two’s-complement codes in your head, while in real day-to-day work you’ll be shuffling uncompressed jsons over kafka. Unfortunately, this happens fairly often. It’s a hiring-process problem that’s hard to influence from the outside.

Back to difficulty levels. None of the problems is genuinely simple on its own. The obvious solution isn’t always the correct or optimal one. Many people don’t read the constraints and the problem statement carefully — and that matters a lot. Your solution will be judged by a computer, not a human. So it’s important to pass every test case, and they can be very unpredictable.

Whatever level of problem you choose, always:

• read the problem statement carefully and make sure you understand it;
• check the constraints on the output;
• have a precise idea of what time complexity (the O(n) you’re aiming for) your code needs in order to stay within the time limit.

When submitting a solution, if you don’t want to spoil your stats — the percentage of accepted solutions — use the Run button instead of Submit to verify it; that runs your solution against the test cases shown in the problem’s examples. You can also add your own test cases there. Self-checking via Run is also very useful when your compiler’s version differs from the platform’s. It often happens that a more recent language version lets you omit certain things, but the solution still won’t be accepted. Here’s a Kotlin example:

fun maximumValue(strs: Array<String>): Int =
  strs.map { s ->
    if (s.all { it.isDigit() })
      s.toInt(10)
    else
      s.length
  }.max()

But the Kotlin version on Leetcode requires explicitly returning an Int:

fun maximumValue(strs: Array<String>): Int =
  strs.map { s ->
    if (s.all { it.isDigit() })
      s.toInt(10)
    else
      s.length
  }.max() ?: 0

Both solutions compile, run, and behave as expected. But Leetcode will only accept the second one — the first won’t compile there.

Before the algorithms section, you’ll most likely get a few pieces of advice:

• solve Medium problems;
• use the timer; it’s built into the platform itself;
• try to fit within 25–30 minutes.

This advice is genuinely useful, but only as you prepare for the interview itself. You’ll have a limited amount of time — sometimes an hour, sometimes two. And in that window you’ll need to solve a particular set of problems.

But while you’re studying algorithms, I suggest dropping the timer entirely and not solving for speed — only for understanding. That’s exactly why I always lay out the test set before solving, try to add my own edge cases to it, and only then dig into the problem.

Don’t ignore other people’s solutions either. They’re often left not just in the Solutions tab but in the comments too. Most aren’t anywhere near reference quality, but some can help you understand the problem and the approach — maybe even find a more expressive solution than the one that came to mind first.

Don’t shy away from working through Easy problems. They’re simple enough to teach you the topic, and tricky enough that you can still mess them up. Problems at this level help you cement the topic.

Medium problems are a step harder; they require applying the patterns you practiced on Easy ones. You’ll often need to combine them or learn new algorithms. That’s a good step forward — but only once you feel confident with the simpler problems.

Hard problems and challenges I think we’ll save for the very end. They’re genuinely difficult, and very few people will need the ability to solve them.

In the next posts we’ll move on to discussing solution patterns. Thanks, and talk soon!