What do Array.prototype.at() and String.prototype.at() do differently from bracket indexing, and why were they added?

Q: What do Array.prototype.at() and String.prototype.at() do differently from bracket indexing, and why were they added?

**Target Audience:** Engineers preparing for JavaScript fundamentals interview questions. **Difficulty:** Easy > **How to read this doc:** Concepts are explained in plain language first, then tagged with 📌 Interview term: . Every result below was actually run on Node.js v24.19.0 — the printed output is real, captured output, not illustrative sample text. ## 1. Why This Even Matters — A Story First Picture reading a numbered list of names and being asked for the last one. Counting from the front means first finding out how many names there are, then counting all the way down to that number — extra work just to reach the end. Counting from the back means simply saying "the last one," without ever needing to know the total length first. `.at()` is exactly that second option applied to arrays and strings: a negative index counts backward from the end directly, without ever touching `.length`. ## 2. The Core Idea 📌 **Interview term:** `Array.prototype.at(index)` and `Stri

The problem

Question presented to candidate: "What does .at() actually add on top of regular bracket indexing for arrays and strings, and why did the language add a whole new method just for this?"

What a strong answer should cover:

.at(index) accepts negative integers, counting back from the end: at(-1) is the last element, at(-2) is second-to-last, and so on.
Bracket notation does not support negative indices at all -- arr[-1] does not throw, it just looks up the property named "-1" on the array, which does not exist, so it returns undefined.
Both a valid negative index and an out-of-range index (too large positive, or too negative) return undefined for .at() with no throw.
at() is defined generically across indexable built-ins -- plain arrays, strings, and typed arrays all support it with the same semantics.
Motivation: before at(), getting the last element required arr[arr.length - 1], which recomputes/re-reads length and reads awkwardly, especially when arr itself is the result of a function call that would otherwise need to be invoked twice.

Clarifying questions expected:

"Should I also cover TypedArray.prototype.at(), or just Array and String?"
"Do you want me to compare this against .slice(-1)[0], which was the common pre-at() workaround?"

Code / implementation expected: Yes -- a runnable comparison of at() against bracket indexing for both positive and negative indices, including out-of-range behavior.

array
string
at-method

Try it yourself

Sketch your approach before you read the solution. That is what the interview tests.

Stuck? Get a hint.

A short nudge toward the approach. It will not give the answer away.

Solution

Target Audience: Engineers preparing for JavaScript fundamentals interview questions. Difficulty: Easy

How to read this doc: Concepts are explained in plain language first, then tagged with 📌 Interview term:. Every result below was actually run on Node.js v24.19.0 — the printed output is real, captured output, not illustrative sample text.

1. Why This Even Matters — A Story First

Picture reading a numbered list of names and being asked for the last one. Counting from the front means first finding out how many names there are, then counting all the way down to that number — extra work just to reach the end. Counting from the back means simply saying "the last one," without ever needing to know the total length first. .at() is exactly that second option applied to arrays and strings: a negative index counts backward from the end directly, without ever touching `.leng

The solution is hidden so you can try first

6 min read · 8 sections

Run the code

Edit the code and run it here. Each console line with an expected value becomes a test.

JavaScriptArray.prototype.at() and String.prototype.at() vs bracket indexing (run directly)