Coding Signals

The point of interviews is for interviewers to extract signals from certain candidate behaviors. In coding interviews, the signals can be broadly classified into the following categories: Problem Solving, Technical Competency, Testing, and Communication.

When interviewers take down interview feedback, these are likely what is on their feedback sheet.

Problem solving

Understanding the problem

  • ๐Ÿ‘ Understood the key aspects of the problem quickly
  • ๐Ÿ‘Ž Had difficulty in understanding the key aspects of the problem


  • ๐Ÿ‘ Approached the problem in a systematic and logical manner
  • ๐Ÿ‘Ž Did not demonstrate a logical thought process for approaching the problem

Improving the solution

  • ๐Ÿ‘ Suggested a more efficient solution when prompted, or proactively coming up with a better solution
  • ๐Ÿ‘Ž Had difficulty in coming up with a more efficient solution even after being prompted

Trade-offs analysis

  • ๐Ÿ‘ Explained the trade-offs of different approaches clearly and correctly
  • ๐Ÿ‘Ž Failed to describe trade-offs of different approaches


  • ๐Ÿ‘ Did not require any major hints
  • ๐Ÿ‘Ž Needed plenty of hints

Technical competency


  • ๐Ÿ‘ Quickly implemented a working solution
  • ๐Ÿ‘Ž Was not able to complete the solution


  • ๐Ÿ‘ Implemented the solution correctly (e.g., working solution, minimal bugs)
  • ๐Ÿ‘Ž Unable to correctly implement a solution (e.g., non-working solution, incorrect logic, and/or serious bugs)

Complexity analysis

  • ๐Ÿ‘ Able to determine the algorithmic time and space complexity
  • ๐Ÿ‘Ž Was not able to determine the algorithmic time and space complexity (explain why TC came up with such an answer)

Mastery of chosen programming language

  • ๐Ÿ‘ Demonstrated mastery of the chosen programming language
  • ๐Ÿ‘Ž Does not seem to be familiar with the chosen programming language


  • ๐Ÿ‘ Implementation was clean and straightforward
  • ๐Ÿ‘Ž Implementation was unnecessarily complex and/or messy

Coding style

  • ๐Ÿ‘ Coding style was neat (proper indentation, spacing and no bad practices)
  • ๐Ÿ‘Ž Coding style was messy (inconsistent indentation, weird spacings, etc)


Common cases

  • ๐Ÿ‘ Tested their code against various typical cases
  • ๐Ÿ‘Ž Failed to test the code against typical cases

Corner cases

  • ๐Ÿ‘ Found and handled corner/edge cases
  • ๐Ÿ‘Ž Failed to consider corner/edge cases


  • ๐Ÿ‘ Identified and corrected bugs in the code (where applicable)
  • ๐Ÿ‘Ž Was not able to discover and fix bugs even after being prompted


Clarify problem

  • ๐Ÿ‘ Appropriately asked good, clarifying questions about the problem
  • ๐Ÿ‘Ž Failed to confirm understanding/ask appropriate questions

Communicating approach

  • ๐Ÿ‘ Able to explain overall approach, technical terms and acronyms (where applicable)
  • ๐Ÿ‘Ž Failed to effectively explain overall approach, technical terms and acronyms (where applicable)
Last updated on by Yangshun Tay