Beyond the Code: Unconventional Lessons from Empathetic Interviewing

Recently, I’ve been interviewing Computer Science students applying for data science and engineering internships with a 4-day turnaround from CV vetting to final decisions. With a small local office of 10 and no in-house HR, hiring managers handle the entire process.

This article reflects on the lessons learned across CV reviews, technical interviews, and post-interview feedback. My goal is to help interviewers and interviewees make this process more meaningful, kind, and productive.

Principles That Guide the Process

Foster meaningful discussions rooted in real work to get maximum signal and provide transferrable knowledge
Ensure applicants solve all problems during the experience
– Judge excellence by how much inspiration arises unprompted
Make sure even unsuccessful applicants walk away having learned something
Set clear expectations and communicate transparently

The Process Overview

Interview Brief
CV Vetting
1-Hour Interview
Post-Interview Feedback

A single, well-designed hour can be enough to judge potential and create a positive experience, provided it’s structured around real-world scenarios and mutual respect.

The effectiveness of the tips would depend on company size, rigidity of existing processes, and interviewers’ personality and leadership skills

Let’s examine each component in more detail to understand how they contribute to a more empathetic and effective interview process.

Interview Brief: Set the Tone Early

Link to sanitized version.

The brief provides:

Agenda
Setup requirements (debugger, IDE, LLM access)
Task expectations

Brief Snippet: Technical Problem Solving

Exercise 1: Code Review (10-15 min)

Given sample code, comment on its performance characteristics using python/computer science concepts

What signals this exercise provides

Familiarity with IDE, filesystem and basic I/O

Sense of high performance, scalable code

Ability to read and understand code

Ability to communicate and explain code

No one likes turning up to a meeting without an agenda, so why offer candidates any less context than we expect from teammates?

Process Design

When evaluating which questions to ask, well-designed ones should leave plenty of room for expanding the depth of the discussion. Interviewers can show empathy by providing clear guidance on expectations. For instance, sharing exercise-specific evaluation criteria (which I refer to as “Signals” in the brief) allows candidates to explore beyond the basics.

Code or no code

Whether I include pre-written code or expect the candidate to write depends on the time available. I typically reveal it at the start of each task to save time , especially since LLMs can often generate the code, as long as the candidate demonstrates the right thinking.

CV Vetting: Signal vs Noise

You can’t verify every claim on a CV, but you can look for strong signals

Git Introspection

One trick is to run git log — oneline — graph — author=gitgithan — date=short — pretty=format:”%h %ad %s” to see all the commits authored by a particular contributor.

You can see what type of work it is (feature, refactoring, testing, documentation), and how clear the commit messages are.

Strong signals

Self-directed projects or open-source contributions
Evidence of cross-functional communication and impact

Weak or Misleading signals

Guided tutorial projects are less effective in showing vision or drive
Bombastic adjectives like passionate member, indispensable position.

Interview: Uncovering Mindsets

Reflecting on the Interview Brief

I begin by asking for thoughts on the Interview Brief.

This has a few benefits:

How conscientious are they in following the setup instructions?
– Are they prepared with the debugger and LLM ready to go?
What aspects confuse them?
– I realized I should have specified “Pandas DataFrame” instead of just “dataframe” in the brief. Some candidates without Pandas installed experienced unnecessary setup stress. However, observing how they handled this issue provided valuable insight into their problem-solving approach
– This also highlights their attention to detail and how they engage with documentation, often leading to suggestions for improvement.
What tools are they unfamiliar with?
– If there’s a lack of knowledge in concurrent Programming or AWS, it’s more efficient to spend less time on Exercise 3 and focus elsewhere.
– If they’ve tried to learn these tools in the short time between receiving the brief and the interview, it demonstrates strong initiative. The resources they consult also reveal their learning style and resourcefulness.

Favorite Behavioral Question

To uncover essential qualities beyond technical skills, I find the following behavioral question particularly revealing

Can you describe a time when you saw something that wasn’t working well and advocated for an improvement?

This question reveals a range of desirable traits:

Critical thinking to recognize when something is off
Situational awareness to assess the current state and vision to define a better future
Judgment to understand why the new approach is an improvement
Influence and persistence in advocating for change
Cultural sensitivity and change management awareness, understanding why advocacy may have failed, and showing the grit to try again with a new approach

Effective Interviewee Behaviours (Behavioural Section)

Attuned to both personal behavior and both its effect on, and how it’s affected by others
Demonstrates the ability to overcome motivation challenges and inspire others
Provides concise, inverted pyramid answers that uniquely connect to personal values

Ineffective Interviewee Behaviours (Behavioural Section)

Offers lengthy preambles about general situations before sharing personal insights

Tips for Interviewers (Behavioural Section)
I’ve never been a fan of questions focused on interpersonal conflicts, as many people tend to avoid confrontation by becoming passive (e.g., not responding or mentally disengaging) rather than confronting the issue directly. These questions also often disadvantage candidates with less formal work experience.

A helpful approach is to jog their memory by referencing group experiences listed on their CV and suggesting potential scenarios that could be useful for discussion.

Providing instant feedback after their answers is also valuable, allowing candidates to note which stories are worth refining for future interviews.

Technical Problem Solving: Show Thinking, Not Just Results

Measure Potential, Not Just Preparedness

Has high agency, jumps into back-of-the-envelope calculations instead of making guesses
Re-examines assumptions
Low ego to reveal what they don’t know and make good guesses about why something is so based on limited information
Makes insightful analogies (eg. database cursor vs file pointer) that show deeper understanding and abstraction

Effective Interviewee Behaviours (Technical Section)

Exercise 1 on File reading with generators: admitting upfront their unfamiliarity with yield syntax invites the interviewer to hint that it’s not important
Exercise 2 on data cleaning after JOIN: caring about data lineage, constraints of the domain (units, collection instrument) shows systems thinking and a drive to fix the root cause

Ineffective Interviewee Behaviours (Technical Section)

Remains silent when facing challenges instead of seeking clarification
Fails to connect new concepts with prior knowledge
Calls in from noisy, visually distracting environments, thus creating friction on top of existing challenges like accents.

Tips for Interviewers (Technical Section)

Start with guiding questions that explore high-level considerations before narrowing down. This helps candidates anchor their reasoning in principles rather than trivia.
Avoid overvaluing your own prepared “correct answers.” The goal isn’t to test memory, but to observe reasoning.
Withhold judgment in the moment , especially when the candidate explores a tangential but thoughtful direction. Let them follow their thought process uninterrupted. This builds confidence and reveals how they navigate ambiguity.
Use curiosity as your primary lens. Ask yourself, “What is this candidate trying to show me?” rather than “Did they get it right?”

LLM: A Window into Learning Styles

Modern technical interviews should reflect the reality of tool-assisted development. I encouraged candidates to use LLMs — not as shortcuts, but as legitimate creation tools. Restricting them only creates an artificial environment, divorced from real-world workflows.

More importantly, how candidates used LLMs during coding exercises revealed their learning preferences (learning-optimized vs. task-optimized) and problem-solving styles (explore vs. exploit).

You can think of these 2 dichotomies as sides of the same coin:

Learning-Optimized vs. Task-Optimized (Goals and Principles)

Learning-Optimized: Focuses on understanding principles, expanding knowledge, and long-term learning.
Task-Optimized: Focuses on solving immediate tasks efficiently, often prioritizing quick completion over deep understanding.

Explore vs. Exploit (How it’s done)

Explore: Seeks new solutions, experiments with various approaches, and thrives in uncertain or innovative environments.
Exploit: Leverages known solutions, optimizes existing strategies, and focuses on efficiency and results.

4 styles of prompting

In Exercise 2, I deleted a file.seek(0) line, causing pandas.read_csv() to raise EmptyDataError: No columns to parse from file.

Candidates prompted LLMs in 4 styles:

Paste error message only
Paste error message and erroring line from source code
Paste error message and full source code
Paste full traceback and full source code

My interpretations

(1) is learning-optimized, taking more iterations
(4) is task-optimized, context-rich, and efficient

Those who choose (1) start looking at a problem from the highest level before deciding where to go. They consider that the error may not even be in the source code, but the environment or elsewhere (See Why Code Rusts in reference). They optimize for learning rather than fixing the error immediately.

Those with poor code reproduction discipline and do (4) may not learn as much as (1), because they can’t see the error again after fixing it.

My ideal is (4) for speedy fixes, but taking good notes along the way so the root cause is understood, and come away with sharper debugging instincts.

Red Flag: Misplaced Focus on Traceback Line

Even though (2) included more detail in the prompt than (1), more isn’t always better.
In fact, (2) raised a concern: it suggested the candidate believed the line highlighted in the Traceback ( — -> 44 df_a_loaded = pd.read_csv) was the actual cause of the error.

In reality, the root cause could lie much earlier in the execution, potentially in a different file altogether.

Prompt Efficiency Matters

After Step (2), the LLM returned three suggested fixes — only the third one was correct. The candidate spent time exploring Fix #1, which wasn’t related to the bug at all. However, this exploration did uncover other quirks I had embedded in the code (NaNs sprinkled across the joined result from misaligned timestamps as the joining key)

Had the candidate instead used a prompt like in Step (3) or (4), the LLM would’ve provided a single, accurate fix, along with a deeper explanation directly tied to the file cursor issue.

Style vs Flow

Some candidates added pleasantries and extra instructions to their prompts, rather than just pasting the relevant code and error message. While this is partly a matter of style, it can disrupt the session’s flow , especially under time constraints or with slower typing , delaying the solution.

There’s also an environmental cost.

Feedback: The Real Cover Letter

After each interview, I asked candidates to write reflections on:

What they learned
What could be improved
What they thought of the process

This is far more useful than cover letters, which are built on asymmetric information, vague expectations, and GPT-generated fluff.

Here’s an example from the offered candidate.

Excelling in this area builds confidence that colleagues can provide candid, high-quality feedback to help each other address blind spots. It also signals the likelihood that someone will take initiative in tasks like documenting processes, writing thorough meeting minutes, and volunteering for brown bag presentations.

Effective Interviewee Behaviours (Feedback Section)

Communicates expected completion times and follows through with timely submissions.
Formats responses with clear structure — using paragraph spacing, headers, bold/italics, and nested lists — to enhance readability.
Reflects on specific interview moments by drawing lessons from good notes or memory.
Recognizes and adapts existing thinking patterns or habits through meta-cognition

Ineffective Interviewee Behaviours (Feedback Section)

Submits unstructured walls of text without a clear thesis or logical flow
Fixates solely on technical gaps while ignoring behavioural weaknesses.

Tips for Interviewers (Feedback Section)

Live feedback during the interview was time-constrained, so give written feedback after the interview about how they could have improved in each section, with learning resources
– If done independently from the interviewee’s feedback, and it turns out the observations match, that’s a strong signal of alignment
– It’s an act of goodwill towards unsuccessful candidates, a building of the company brand, and an opportunity for lifelong collaboration

Carrying It Forward: Actions That Matter

For Interviewers

Develop observation and facilitation skills
Provide actionable, empathetic feedback
Remember: your influence could shape someone’s career for decades

For Interviewees

Make the most of the limited information you have, but try to seek more
Be curious, prepared, and reflective to learn from each opportunity

People will forget what you said, people will forget what you did, but people will never forget how you made them feel – Maya Angelou

As interviewers, our job isn’t just to assess — it’s to reveal. Not just whether someone passes, but what they’re capable of becoming.

At its best, empathetic interviewing isn’t a gate — it’s a bridge. A bridge to mutual understanding, respect, and possibly, a long-term partnership grounded not just in technical skills, but in human potential beyond the code.

The interview isn’t just a filter — it’s a mirror. The interview reflects who we are. Our questions, our feedback, our presence — they signal the culture we’re building, and the kind of teammates we strive to be.

Let’s raise the bar on both sides of the table. Kindly, thoughtfully, and together.

If you’re also a hiring manager passionate about designing meaningful interviews, let’s connect on LinkedIn (https://www.linkedin.com/in/hanqi91/).

I’d be happy to share more about the exercises I prepared.

Resources

Writing useful commit messages: https://refactoringenglish.com/chapters/commit-messages/
Writing impactful proposals: https://www.amazon.sg/Pyramid-Principle-Logic-Writing-Thinking/dp/0273710516
http://highagency.com/
Glue work: https://www.noidea.dog/glue
The Missing Readme: https://www.amazon.sg/dp/1718501838
Why Code Rusts: https://www.tdda.info/why-code-rusts

The post Beyond the Code: Unconventional Lessons from Empathetic Interviewing appeared first on Towards Data Science.