Openai·Software Engineer·Technical Phone Screen·Intermediate

Intermediate

May 2026

Summary

Interviewed for a software engineer role at OpenAI and got a coding question around IP address handling, specifically extending an IPv4 validator to support CIDR notation.

Questions Asked (1)

Given a function that validates IPv4 addresses, extend it to also handle CIDR notation (e.g. 192.168.1.0/24).

Algorithms & Data StructuresTechnical Trade-offs

Author's notes

Felt fine about the base IPv4 part but the CIDR extension tripped me up a bit.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying the requirements: should the function validate both IPv4 and CIDR, or only CIDR? Then outline a modular approach: split the input on '/', validate the IPv4 part using the existing function, and validate the prefix length as an integer between 0 and 32. Discuss edge cases and potential trade-offs, such as strictness of validation and handling of non-canonical representations.

Pro tip: Mention that you would reuse the existing IPv4 validation logic to avoid duplication, and consider using a well-tested library for production code, but implement it manually if asked to demonstrate coding skills.

1. Clarify Requirements

Ask whether the function should accept both plain IPv4 and CIDR, or only CIDR. Also clarify if the IPv4 part must be a network address (e.g., 192.168.1.0/24) or any address with a prefix.

2. Design the Validation Logic

Split the input on '/'. If there is no '/', validate as plain IPv4. If there is one '/', validate the first part as IPv4 and the second part as a valid prefix length (integer 0-32).

3. Handle Edge Cases

Consider cases like multiple slashes, empty prefix, non-numeric prefix, leading zeros in prefix, and IPv4 addresses with leading zeros. Decide on strictness (e.g., reject leading zeros in IPv4 octets).

4. Discuss Trade-offs and Extensibility

Talk about whether to enforce that the IPv4 address is the network address for the given prefix (e.g., 192.168.1.1/24 is technically valid CIDR but not a network address). Mention potential use of regex vs. manual parsing.

5. Test and Validate

Propose test cases: valid CIDR (192.168.1.0/24), invalid prefix (192.168.1.0/33), missing prefix (192.168.1.0/), extra slash (192.168.1.0/24/24), and plain IPv4 (192.168.1.1).

Key Points to Mention

Reuse of existing IPv4 validation function to avoid code duplication.
Prefix length validation: must be an integer between 0 and 32 inclusive.
Handling of edge cases: multiple slashes, empty prefix, non-numeric characters.
Strictness: whether to allow leading zeros in IPv4 octets or prefix (e.g., /024).
Trade-off between using regex and manual parsing for performance and readability.
Consideration of whether the IPv4 part must be a network address (all host bits zero) for the given prefix.

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.