Why a Weak JavaScript Answer Doesn't Always Mean Rejection

Candidate A
- Answers every question, all at definition level
- No mistakes, no reasoning shown
- Coding task: correct, written in silence
- Feedback: "Knows the words. Unsure of depth."

Candidate B
- Gets the const question wrong
- Takes the hint, corrects, explains why
- Coding task: talks through plan, finds own bug
- Feedback: "One gap on const, picked it up fast.
  Strong reasoning. Recommend."

JAVASCRIPT ROUND - INTERVIEWER NOTES

Fundamentals      [1] [2] [3] [4] [5]
  scope, closures, async, objects, types

Problem solving   [1] [2] [3] [4] [5]
  clarifies, plans, codes, tests

Communication     [1] [2] [3] [4] [5]
  clear, structured, thinks aloud

Coachability      [1] [2] [3] [4] [5]
  uses hints, accepts correction

Red flags: ______________________
Overall: Strong yes / Yes / No / Strong no

const user = { name: "Ravi" };

user.name = "Ravi K";   // allowed - object changed
user.age = 24;          // allowed - property added
console.log(user);      // { name: 'Ravi K', age: 24 }

try {
  user = { name: "Other" };  // not allowed - reassignment
} catch (e) {
  console.log(e.name);       // TypeError
}

const frozen = Object.freeze({ name: "Asha" });
frozen.name = "Changed";      // silently ignored (TypeError in strict mode)
console.log(frozen.name);     // Asha

// Note: freeze is shallow. Nested objects can still change.

Interviewer: Are you sure? What if you add a property?

Candidate: Let me think about that again.
const means the variable 'user' cannot be pointed at
a different value. But the object itself is a separate
thing in memory. Adding a property changes the object,
not the variable. So yes, I was wrong: you can change
it. If I wanted to prevent that, I would use
Object.freeze, though that only freezes the top level.

(Weak first answer. Strong second answer.
The second one is what gets written in the notes.)

// API data where some fields may be missing
const order = {
  id: 7,
  customer: { name: "Meena", address: null },
  items: []
};

// Weak: crashes when address is null
// const city = order.customer.address.city;  // TypeError

// Strong: optional chaining + nullish coalescing
const city = order.customer?.address?.city ?? "Not provided";
console.log(city); // "Not provided"

// ?? vs ||
const count = 0;
console.log(count || 10); // 10  - || treats 0 as missing
console.log(count ?? 10); // 0   - ?? only replaces null/undefined

A front-end developer reads API data all day.
If a candidate does not know how to read a nested
value that might be null, the gap is not about
trivia. It is about a crash they would ship.

Compare:
- Forgetting what Symbol.iterator does
  -> rarely needed day to day, small dent
- Not handling null in nested data
  -> daily task, real concern

Prepare everyday topics first, trivia last.

WHEN YOU REALISE AN ANSWER WAS WEAK

1. Pause. One breath.
2. "Let me reconsider that."
3. Reason aloud from a rule you are sure of.
4. Try a tiny example in your head or on paper.
5. State the corrected answer clearly.
6. Add one step further if you can.
7. Move on. Do not apologise repeatedly.

WHEN THE INTERVIEWER HINTS
"That's a good point. If X, then that means..."
Use the hint in your very next sentence.

THE NEXT QUESTION MATTERS MOST

After a weak answer, candidates often:
- rush the next answer
- answer too briefly to avoid more mistakes
- keep thinking about the previous question

Instead:
[ ] Restate the new question before answering
[ ] Answer at your normal pace and length
[ ] Think aloud as usual
[ ] Leave the previous question behind

One weak answer is a dent.
Three rushed answers after it is a pattern.

AFTER-ROUND REVIEW

Question I answered weakly: ______________
What I said: ______________________________
What the correct answer is: _______________
Was it a core skill for the role?     Y / N
Did I recover in the moment?          Y / N
How did I answer the NEXT question?   ______

One topic to revise this week:
__________________________________________

Do not decide you failed. Wait for the result.