We've hit the home stretch. You're about to dive into the Timed Mock Assessment, and honestly, the hardest part isn't usually the syntax—it's the clock. When you're racing against a timer, your brain tends to revert to the most basic patterns you know, even if they aren't the "Kotlin way."

To get your head in the right space, let's walk through a problem I recently saw in a technical screen. It’s a classic "Core Kotlin" challenge: taking a messy list of data, filtering it, and transforming it into a clean result set, all while handling nulls without crashing. Let's try to solve it together as if we were in the middle of that test.

The Instinctive (and Clunky) Loop

The prompt is simple: "Given a list of User profiles, return a list of uppercase usernames for all users who have a verified email, ignoring any users who are missing a name."

If I'm rushing, my first instinct is often a for loop. It's safe, and I know it works. I'll start like this:

data class User(val name: String?, val email: String?, val isVerified: Boolean)

fun getVerifiedUsers(users: List): List {
    val result = mutableListOf()
    for (user in users) {
        if (user.isVerified && user.name != null && user.email != null) {
            result.add(user.name.uppercase())
        }
    }
    return result
}

I run this, and it works. But here's the problem: in a core Kotlin assessment, this is "Java written in Kotlin." It's verbose. If the test has ten of these problems, I'm going to run out of time because I'm writing too much boilerplate. I need to lean into the standard library.

Cleaning up with Functional Chains

I want to flatten this. I'll try to use filter and map. This is usually where people start feeling more "Kotlin-esque."

fun getVerifiedUsers(users: List): List {
    return users
        .filter { it.isVerified && it.name != null && it.email != null }
        .map { it.name!!.uppercase() }
}

Wait. Look at that !!. I just used the "not-null assertion operator." Even if I know the filter caught the nulls, using !! in a mock assessment is a red flag to any reviewer. It says, "I'm forcing the compiler to trust me," which is the opposite of why we use Kotlin. If the requirements change and I move the map before the filter, the whole app crashes.

The "Core Kotlin" Elegant Solution

Now, I'll adjust. I remember that mapNotNull is specifically designed for this pattern. It lets me transform the data and discard the nulls in one single pass. I can also combine the verification check into a filter.

fun getVerifiedUsers(users: List): List {
    return users
        .filter { it.isVerified && it.email != null }
        .mapNotNull { it.name?.uppercase() }
}

This is much better. I've eliminated the !!, I've reduced the lines of code, and I'm using the safe call operator ?.. If name is null, uppercase() isn't called, and mapNotNull simply drops that entry from the resulting list.

When you take this mock assessment, keep this progression in mind. If you find yourself writing if (x != null) inside a loop, stop for a second. Ask yourself: "Is there a mapNotNull, a filterNotNull, or a let block that can do this more safely?" That's the difference between passing the test and mastering the language.

📋 Practical Task

The High-Pressure Transaction Sanitizer

You are tasked with building a data cleaning function for a financial app. You have a list of Transaction objects, but the data is "dirty"—some amounts are missing, and some descriptions are null.

Requirements:

• Filter out any transactions that are marked as isPending = true.
• Discard any transaction that has a null amount.
• For the remaining transactions, create a list of strings in the format: "AMOUNT: [value] - DESC: [description]".
• If the description is null, use the string "No Description" as the fallback.
• The final list should be sorted by the amount in descending order.

data class Transaction(
    val amount: Double?, 
    val description: String?, 
    val isPending: Boolean
)

fun sanitizeTransactions(transactions: List): List {
    // Your code here
}

Goal: Implement sanitizeTransactions using a functional chain (avoid for loops and avoid the !! operator). Test your solution with a list containing a mix of pending, null-amount, and null-description transactions.