Know What the Job Needs So You Know What to Practice
A lot of students judge how hard a job is from hearsay. They hear “risk” and assume they’ll need very complex modeling, or see a big company and decide it’s out of reach.
As I said earlier, the same job title can mean different work. Read the job description (JD) first, then look at what people in similar roles have done, and finally verify your understanding by talking with people in the field. Don’t see that someone else knows a certain skill and conclude it’s required of every candidate.
Of course, you need the basic skills. SDE roles need the matching programming and problem-solving ability; investment banking requires understanding finance, valuation, and modeling; consulting requires being able to work through a case. But benchmarks like “LeetCode up to a certain level” or “can build a DCF” can’t replace a specific company’s requirements.
I keep reminding students about soft skills because so many are willing to spend dozens of hours on practice problems and so few spend the same time talking through their own experience. They’ve done plenty of technical prep, but when it’s time to explain “why I did it this way and how I handled problems,” all they have is a few vague sentences.
Many jobs out there need you to explain information and data to colleagues, and to keep thinking and communicating when you’re facing things you don’t fully know. Your technical skills, judgment, and communication all need to fit the role. The more a job involves clients, pushing work across teams, and explaining the business, the less you can afford to neglect judgment and communication.
A Resume That’s Too Advanced Can Also Hold You Back
One student I worked with had a lot of complicated technical language on her resume, some of which she wasn’t familiar with, and which her target roles might not even need. When we got to those parts, she had to stop and think for a long time. But when she switched to a piece of medical device research she actually understood, she could smoothly explain how the product, the funding, and market demand were connected, and why she’d reached a particular investment view.
In that situation, I suggested she bring the resume back down to what she could actually handle and what was relevant to the roles she wanted. The technical terms you put in can determine where the interviewer digs. Add a model you can’t explain just to look impressive, and the catch-up studying and interview pressure afterward can multiply.
I also went through the time cost with her. If chasing a higher-paying, harder role meant learning a lot of material she wouldn’t use for a while, whether that was worth it depended on her job search deadline and goals. The $100,000 and $130,000 we compared came from that one consultation; they’re not a fixed mapping between job difficulty and salary.
You might keep building depth, or focus first on roles where you already have an edge. What you want to avoid is wanting one kind of job while your resume steers the interviewer toward testing you for another.
Your Resume Should Show What You Specifically Did
Here are two real resume lines I quoted in an earlier piece:
Provide pro-bono consulting to clients by delivering impactful presentations and reports, demonstrating proficiency in navigating complex problem statements for tangible solutions, gaining hands-on experience in the non-profit sector
Led in-depth research for equity financing projects and instructed investment decisions by driving insights from due diligence, negotiation, valuation, and ROI analysis
These lines mention reports, due diligence, valuation, and investment recommendations. They seem to have everything. But after reading them, you still don’t know who this person researched, what she found, or which judgment was hers.
This is something I notice all the time after reading so many student resumes. Business resumes keep showing equity research, due diligence, audit, and case competitions; data resumes keep showing course projects, public datasets, and visualizations. The things people have done already overlap. If the wording is also reduced to generic actions, employers have a hard time telling you apart.
Not everyone needs a project no one else has ever done. What you need is to write down the specific things you did within familiar kinds of projects.
I usually have students start with four questions:
- What were you researching or working on? Which industry, what business, how many companies, or how large a dataset?
- What did you find, and how? Which metrics did you look at, what did you compare, and what problems did you identify?
- What did you recommend, or what judgment did you form, based on that? Even if you weren’t part of the final decision, you can still state your own conclusions.
- What result or impact did it have in the end? Was the recommendation adopted, did a process improve, and how many people, how much money, or how much time did it affect?
Depending on the role and your level, the emphasis will shift, but the second question is especially worth digging into. Many students feel that as interns without final results, they have nothing they dare to write. In fact, if you can explain what you saw, that’s often already much more specific than just listing “performed analysis.”
Don’t invent a final result that doesn’t exist. Write about the analysis, recommendation, or testing you completed, and be clear about how far it got. If it was only your own view and you never proposed it to the company, don’t write it up as something the company adopted.