30.10 Your First Week in a Power BI Job and a Mini Portfolio Checklist

Suppose we are starting on Monday as a junior Power BI developer in an Infosys client team for a retail brand. This is what most teams expect in week 1. It is not about knowing every DAX function. It is about being careful, asking the right questions and shipping one small, correct change.

What the company expects in week 1

1. Day 1 — Access. Laptop, Power BI Desktop, workspace access, data source access, VPN. Make a list of what is missing and send it to your lead the same day.
2. Day 2 — Read before you write. Open the existing report. Write down every page, every measure on the cards, and every data source. Ask: "Which number does the business trust most?"
3. Day 3 — KPI definitions. Ask how each KPI is defined. Example: "Is AOV sales ÷ delivered orders or ÷ all orders?" Write the answer in the measure description.
4. Day 4 — One small change in DEV. Fix a title, add one measure, or clean one column. Work in a copy or the DEV workspace. Never edit the production report directly.
5. Day 5 — Show and check. Show the change to your lead. Compare one number with the source (Excel or SQL) by hand. Publish only after review.

Habits they notice in week 1:

1. You never e-mail a .pbix file. You share through the workspace or app.
2. You do not give yourself or others Member access "to make it easy". You respect RLS and data privacy.
3. You name measures clearly (Total Sales, not Measure 3) and keep them in one measure table.
4. You say "I don't know yet, I will check" instead of guessing.

Mini portfolio checklist (three proofs)

1. One PBIX. The Blinkit Maharashtra project (Chapter 28): star schema, a marked Date table, 8–10 explicit measures (Total Sales, Orders, AOV, % under 10 min, Cancel Rate, FYTD, YoY %), and two clean pages.
2. RLS demo. Dynamic RLS with a User Security table. Two screenshots of View as: one city manager and one multi-city user. A 60-second screen recording is even better.
3. Published report. Published to a workspace with a scheduled refresh at 7:00 IST and a screenshot of Refresh history. Use Publish to web only if every number is fictional, because it makes the report public on the internet.
4. One-page README. Business question, data source, model diagram, list of measures with one-line meaning, and one decision the report supports.

Say it in 60 seconds (practise aloud):

"I built a Blinkit-style operations report for six Maharashtra cities with fictional data. I cleaned the exports in Power Query, built a star schema with a Date table for the April–March year, and wrote measures like AOV and % delivered under 10 minutes. I added dynamic RLS so each city manager sees only their city, tested it with View as, and published it with a daily 7 am refresh. The main page tells the manager which store is late, by how much."

Samajla ka? One honest project, shown well, beats ten copied dashboards.