Q134: BigInt, Number Precision and Safe Integers

What Interviewers Want To Evaluate

This question checks whether you understand JavaScript numeric limits. Interviewers want IEEE 754 numbers, floating-point precision, Number.MAX_SAFE_INTEGER, safe integer checks, BigInt, money handling, IDs, serialization, and mixing numeric types.

Senior answers should connect precision to real product bugs in payments, analytics, database IDs, and API contracts.

Short Interview Answer

JavaScript number uses double-precision floating point, so it can represent decimals approximately and integers safely only up to Number.MAX_SAFE_INTEGER. Values beyond the safe integer range can lose precision. BigInt represents arbitrarily large integers, but it cannot be mixed directly with number in arithmetic and is not JSON-serializable by default. For money, use integer minor units or decimal libraries rather than floating-point arithmetic.

Detailed Interview Answer

JavaScript has one main numeric primitive for most code: number.

typeof 42; // "number"
typeof 3.14; // "number"

It uses IEEE 754 double-precision floating point.

This gives a wide range, but not perfect decimal precision.

Floating-Point Surprise

0.1 + 0.2 === 0.3; // false

The result is close to 0.3, but not exactly.

This happens because many decimal fractions cannot be represented exactly in binary floating point.

Safe Integers

JavaScript can safely represent integers only within a range.

Number.MAX_SAFE_INTEGER;
Number.MIN_SAFE_INTEGER;

Safe means integer comparisons and increments remain precise.

Number.isSafeInteger(value);

Use this when parsing large integer IDs or counts.

Precision Loss

Number.MAX_SAFE_INTEGER + 1 === Number.MAX_SAFE_INTEGER + 2;

This can be true because precision is lost beyond the safe range.

That is terrifying when the value is a database ID, order ID, or payment amount.

BigInt

BigInt represents large integers.

const id = 9007199254740993n;

The n suffix creates a BigInt literal.

typeof id; // "bigint"

BigInt Arithmetic

const total = 10n + 20n;

You cannot mix BigInt and number directly.

10n + 20; // TypeError

Convert explicitly if needed, and do so only when safe.

BigInt and JSON

JSON.stringify does not serialize BigInt by default.

JSON.stringify({ id: 10n }); // TypeError

For API transport, large integers are often sent as strings.

{
  "id": "9007199254740993"
}

The frontend can keep it as a string unless arithmetic is required.

Money Handling

Do not use floating point for precise currency calculations.

0.1 + 0.2;

For many apps, store money in minor units.

const cents = 1999;

For complex financial calculations, use a decimal library and backend validation.

Rounding

Display rounding and calculation rounding are different concerns.

new Intl.NumberFormat("en-US", {
  style: "currency",
  currency: "USD",
}).format(19.99);

Formatting is not a substitute for correct calculation.

IDs and Precision

Large backend IDs may exceed JavaScript safe integer range.

If an API sends such IDs as numbers, precision may already be lost before your code sees them.

Prefer string IDs for large numeric identifiers.

Common Mistakes

A common mistake is parsing every API ID with Number.

Another mistake is using float arithmetic for payment totals.

Another mistake is converting BigInt to number without checking safe range.

Senior Trade-Offs

Use number for normal UI counts, dimensions, percentages, and approximate calculations.

Use string IDs for identifiers.

Use integer minor units or decimal libraries for money.

Use BigInt when integer arithmetic beyond safe range is actually required.

Code or Design Example

function parseSafeCount(value) {
  const number = Number(value);

  if (!Number.isSafeInteger(number) || number < 0) {
    throw new Error("Invalid count");
  }

  return number;
}

This protects code that expects safe integer arithmetic.

Debugging Workflow

When numeric bugs appear:

check floating-point decimals
check safe integer range
check API IDs sent as numbers
check BigInt and number mixing
check JSON serialization
check money minor units
check rounding rules
check backend contract

Interview Framing

Start with number as double-precision floating point. Then explain safe integers, BigInt, JSON limits, and money handling.

Revision Notes

JavaScript numbers are not arbitrary precision decimals. Safe integer range and decimal precision matter in real systems.

Key Takeaways

Numeric correctness is a data contract issue. Use the right representation before formatting or calculating.

Follow-Up Questions

1. What numeric format does JavaScript number use?
2. Why is 0.1 + 0.2 surprising?
3. What is Number.MAX_SAFE_INTEGER?
4. How do you check safe integers?
5. What is BigInt?
6. Can BigInt mix with number arithmetic?
7. Can JSON serialize BigInt by default?
8. How should large IDs be represented?
9. How should money be represented?
10. When is a decimal library needed?

How I Would Answer This In A Real Interview

I would explain that JavaScript numbers are double-precision floats, so decimals and huge integers need care. Then I would discuss safe integers, BigInt, string IDs, integer minor units for money, and explicit API contracts.