What 1000+ Reviews Taught Me About Reading Between Lines

Interview Insights · Resume & Portfolio Review

What 1000+ Reviews Taught Me About Reading Between Lines

SECTION 01The words: verbs and specifics that reveal ownership

The first layer is language. Certain verbs appear again and again on fresher resumes: 'worked on', 'involved in', 'exposure to', 'assisted with', 'responsible for'. They are not wrong, but they hide the one thing a reviewer most wants to know: what did you personally do? When I see them, I assume the role was small until the interview proves otherwise.

Specific lines read very differently. 'Removed duplicate orders caused by payment retries before building the revenue report' tells me there was real data, a real problem and a person who noticed it. Specificity is the strongest signal of genuine work, because it is hard to invent convincingly.

SEARCH YOUR RESUME FOR THESE AND REWRITE EACH:

  worked on        -> built / wrote / designed
  involved in      -> what exactly did you do?
  exposure to      -> used X to do Y
  assisted with    -> name your part
  responsible for  -> the action you took
  familiar with    -> fine only in a 'familiar' line
  handled          -> what problem did you solve?

Rewrite pattern:
[action verb] + [what] + [tool/feature] + [for what purpose]

BEFORE
- Worked on data analysis using Excel and SQL
- Involved in dashboard creation
- Exposure to Python

AFTER
- Wrote SQL joins across orders and returns tables to
  separate net sales from gross sales
- Built a Power BI dashboard with a category drill-down
  used in weekly sales reviews during the internship
- Cleaned inconsistent city names and dates in Pandas
  before analysis

The rewritten lines are not longer because they are padded. They are longer because each one contains a real action, a tool and a purpose. A reviewer can now ask a specific question, and you can answer it with confidence.

SECTION 02The projects: what your dataset choice says

The second layer is the project itself, and the first thing I notice is the dataset. Some datasets appear in a huge share of fresher portfolios: Titanic survival, Iris flowers, Netflix titles, a superstore sales file. Using them is not a mistake. But when I see them, I assume a tutorial was involved, and I listen carefully for what you added beyond it.

A less common dataset, or a common one used to answer an unusual question, reads very differently. It suggests you chose a problem rather than followed a path. Even a small dataset you collected yourself, such as prices from a few local shops, signals initiative more strongly than a polished copy of a popular notebook.

COMMON DATASET, ORIGINAL QUESTION

Dataset: a sample superstore sales file

Tutorial question: 'Which region has the most sales?'

Your question: 'Do heavy discounts actually bring
more profit, or just more sales?'

What you add:
 - bucket discount into bands with a CASE expression
 - compare profit per order across bands
 - recommend a discount ceiling for one category

Now the reviewer asks about your thinking, not the
tutorial's.

SELECT
  CASE
    WHEN discount = 0      THEN '0 none'
    WHEN discount <= 0.10  THEN '1 up to 10%'
    WHEN discount <= 0.30  THEN '2 up to 30%'
    ELSE                        '3 above 30%'
  END                         AS discount_band,
  COUNT(*)                    AS orders,
  ROUND(AVG(profit), 2)       AS avg_profit,
  ROUND(SUM(sales), 2)        AS total_sales
FROM superstore
GROUP BY 1
ORDER BY 1;

The band labels start with a digit so they sort in order. Small details like that are worth mentioning in an interview, because they show you looked at your own output and fixed what was confusing.

SECTION 03The history and the README: how the work happened

The third and fourth layers are the ones candidates think about least. If your portfolio links to GitHub, I look at the commit history. A project that appears in a single commit called 'initial upload' with every file complete suggests the work happened elsewhere, perhaps copied or downloaded. A history of small commits over days or weeks, with messages like 'fix date parsing for mixed formats', suggests real, iterative work.

The README is where I learn how you think. A good one explains the question, the data, the approach, the main finding and what you would do next. A missing or one-line README leaves the reviewer guessing, and guesses tend to be cautious.

# Commit in small, meaningful steps
git add clean_orders.py
git commit -m "Parse mixed date formats in order_date"

git add analysis.ipynb
git commit -m "Add discount band profit comparison"

git add README.md
git commit -m "Explain question, data source and findings"

git push origin main

# Before pushing a notebook:
# Kernel > Restart & Run All, then save

# Discounts vs Profit: Superstore Analysis

## Question
Do heavy discounts bring more profit, or only more sales?

## Data
Sample superstore sales file (public practice dataset).
One row per order line.

## Approach
1. Cleaned dates and removed duplicate order lines
2. Grouped discounts into bands with SQL CASE
3. Compared average profit per band and category

## Finding
The highest discount band had the weakest profit in
several categories.

## Limits and next steps
Practice dataset; no customer-level data.
Next: test whether the pattern holds by region.

A README like this takes under an hour to write and changes how every reviewer reads the repository. It answers the first three interview questions before they are asked, and it shows that you can communicate, which analysts do all day.

SECTION 04Self-review checklist before you apply

Read your own application the way a reviewer would. Go layer by layer, and fix the signals you did not mean to send. Uncodemy trainers use a similar layered review in resume sessions.

RESUME LAYER

[ ] No 'worked on', 'involved in', 'exposure to'
    outside a 'familiar with' line
[ ] Each bullet has action + what + tool + purpose
[ ] At least one bullet names a data problem I fixed
[ ] Skills are specific features, not levels
[ ] Every line could be demonstrated live
[ ] One page for fresher roles

PORTFOLIO LAYER

[ ] Each project starts with a business question
[ ] Common datasets have an original question added
[ ] Tutorial origins are acknowledged honestly
[ ] One finding per project is stated clearly
[ ] Charts have titles that state the insight
[ ] Limits are mentioned, not hidden

CODE AND README LAYER

[ ] Commit history shows steps, not one upload
[ ] Commit messages say what changed
[ ] Notebooks restarted and run top to bottom
[ ] No hard-coded personal file paths
[ ] README has question, data, approach, finding,
    limits and next steps
[ ] Repository name describes the project

SECTION 05Habits that make hidden signals work for you

Most hidden signals come from habits, not single decisions. These habits make your application read well at every layer.

• Write as you work — Keep short notes of problems you hit and fixes you made, so your resume bullets and README come from real memory.
• Commit little and often — Push small commits with clear messages while you work, so your history tells the true story of the project.
• Ask an original question — Even with a common dataset, choose a question the usual tutorials do not ask, and make that the centre of the project.
• Read your resume aloud — Lines that sound vague when spoken usually read vague too, so rewrite anything you would struggle to explain.
• Show limits openly — Mention data limits in your README and interviews, because honesty about limits is itself a strong signal.

SECTION 06Interview Q&A — Reading between lines

SECTION 07Test yourself — Reading between lines quiz

SECTION 08Frequently asked questions

SECTION 09Related reads