Limited Time Offer:Up to 25% off Hello Interview Premium

Your Dashboard

Interview Coaching

Mock Interviews

1:1 Mentorship

Salary Negotiation

Practice

Learn

System Design

ML System Design

Low Level Design

Code

Behavioral

Salary Negotiation

Interview Guides

Blog

Community

Interview Questions

Interview Experiences

Peer System Design Library

Ask The Community

Discord

Refer a Friend

Pricing

Become a Coach

⌘K

Pricing Become a Coach

⌘K

Tutor

Get Premium

Leetcode 65. Valid Number

Asked at:

DESCRIPTION

Determine whether a given string represents a valid numeric literal according to specific grammar rules. The literal consists of an optional sign (+ or -), followed by either an integer or decimal (formats like 123, 123., .123, or 123.456), and optionally an exponent part (e or E) with an optional sign and digits. For example, "-123.45e+6" is valid, but "123." with no digits before the dot, or "e5" with no base number, are invalid.

Input:

"123.45e-6"

Output:

true

Explanation: Valid decimal with exponent: integer part 123, decimal part 45, exponent -6

Constraints:

String length: 1 ≤ s.length ≤ 1000
String contains only digits, +, -, ., e, E, and whitespace
Leading/trailing whitespace should be ignored
At least one digit must appear before or after the decimal point
Exponent part requires at least one digit after the sign

Understanding the Problem

The challenge lies in validating multiple optional components with interdependencies: a sign can only appear at the start or after e/E, a decimal point requires digits on at least one side, and an exponent requires both the e/E marker and subsequent digits. Edge cases include lone dots (.), incomplete exponents (1e), multiple decimal points (1.2.3), and invalid character placement (+-5, 1e+). A robust solution must track state transitions through the string, ensuring each character appears in a valid context.

Building Intuition

A naive approach might use multiple string splits or regex patterns, but this becomes error-prone with overlapping rules (e.g., distinguishing between the initial sign and exponent sign). A state machine approach is cleaner: track whether we've seen digits, a decimal point, or an exponent marker, and validate each character based on current state. For example, after seeing e, we must encounter an optional sign followed by digits, and no decimal point is allowed afterward.

Numeric literal validation is fundamental to compiler lexical analysis, JSON/XML parsers, and data validation systems. Understanding this pattern helps implement tokenizers, input sanitizers, and configuration file parsers that must distinguish valid numbers from malformed input.

Common Pitfalls

Forgetting to trim whitespace before validation—wrap the core logic with s.strip() preprocessing

Allowing multiple decimal points—track seenDot flag and reject if already true

Accepting empty exponents like "1e"—ensure at least one digit follows e/E and optional sign

Permitting signs in wrong positions—signs are only valid at the start or immediately after e/E

Implementation

State Tracking Variables

Initialize boolean flags to track what components we've encountered: seenDigit (at least one digit in current number part), seenDot (decimal point), and seenExponent (e/E marker). Also track seenDigitAfterExponent separately since the exponent requires its own digits. For example, when processing "123.45e-6", after the e we reset digit tracking to ensure the exponent part -6 has valid digits.

Solution

# State Tracking Variables
seenDigit = False
seenDot = False
seenExponent = False
seenDigitAfterExponent = False

Character-by-Character Validation

Iterate through the trimmed string and validate each character based on current state. For digits, set seenDigit (and seenDigitAfterExponent if after e). For decimal points, ensure we haven't seen one already and we're not in the exponent part. For signs, verify we're at the start or immediately after e/E. For exponent markers, ensure we haven't seen one already and we have at least one digit in the base number. For example, in ".5e2", the dot is valid (no prior dot), 5 sets seenDigit, e is valid (digit exists), and 2 sets seenDigitAfterExponent.

Solution

# Character-by-Character Validation
for i, char in enumerate(s):
    if char.isdigit():
        seenDigit = True
        if seenExponent:
            seenDigitAfterExponent = True
    elif char == '.':
        if seenDot or seenExponent:
            return False
        seenDot = True
    elif char in 'eE':
        if seenExponent or not seenDigit:
            return False
        seenExponent = True
    elif char in '+-':
        if i != 0 and s[i-1] not in 'eE':
            return False
    else:
        return False

Final Validation Check

After processing all characters, perform a final state check: ensure seenDigit is true (at least one digit in base number) and if seenExponent is true, ensure seenDigitAfterExponent is also true. This catches cases like "1e" (exponent marker without digits) or "." (no digits at all). Return true only if all conditions pass.

Solution

# Final Validation Check
if not seenDigit:
    return False
if seenExponent and not seenDigitAfterExponent:
    return False
return True

What We've Learned

Pattern: State machine with boolean flags elegantly handles complex grammar rules with optional components
Use Case: Apply this validation pattern to lexical analyzers, configuration parsers, and input sanitizers
Edge Case Handling: Separate digit tracking for base and exponent parts prevents accepting incomplete exponents
Whitespace: Always trim input before validation to handle leading/trailing spaces uniformly

Problems to Practice

Valid Parentheses

easy

Stack

Both problems involve validating string formats against specific grammar rules. Valid Parentheses requires checking if brackets are properly matched and nested, which shares the pattern-matching and state-tracking aspects of validating numeric literals.

Practice

Decode String

medium

Stack

This problem requires parsing a string with nested structures and handling different character types (digits, letters, brackets), similar to how Valid Number must parse and validate different components (signs, digits, decimals, exponents) in a specific grammar.

Practice

Decode Ways

medium

Dynamic Programming

While using a different approach, Decode Ways also involves validating whether a string follows specific numeric rules and handling edge cases around valid digit combinations, providing complementary practice in string validation with numeric constraints.

Practice

Question Timeline

See when this question was last asked and where, including any notes left by other candidates.

Company

Level

Region

Late September, 2025

Senior

Leetcode 65. Valid Number But without the exponent condition. All the other conditions were valid.

Mid July, 2025

Comments

Your account is free and you can post anonymously if you choose.

Hello Interview Premium

Recent interview questions

System Design Guided Practice

Exclusive content

Learn More

Leetcode 65. Valid Number

DESCRIPTION

Understanding the Problem

Building Intuition

Common Pitfalls

Implementation

State Tracking Variables

Character-by-Character Validation

Final Validation Check

What We've Learned

Problems to Practice

Question Timeline

Comments

Questions

Learn

Links

Legal

Contact