Negotiating Internship Salary

Sources: The Charisma Myth and Never Split the Difference

Why to Negotiate

  • You will almost always get more.
  • If you do it nicely, they’ll still let you take the original offer.
  • Good practice for learning negotiation, a critical life skill.

How to Negotiate


Set a clear goal

  • Do your homework:
    • What are they paying other interns?
    • What are comparable companies paying their interns?
    • What are they paying their full times (total comp)?
  • What are the best case scenarios?
    • Not just about hourly salary, think about relocation/starting bonuses
  • What non-cash things can they offer me?
    • Paid vacation days
    • Pick the team you work on
    • Paid/subsidized housing
    • Flexible hours/working from home
    • Anything else you can think of!

Summarize the situation

  • Describe the situation so that they respond with “that’s right.”
  • If they gave you an offer, they already want you!
  • Seller’s market: good CS talent is hard to find
  • But: they want to get the best deal for their company, that’s their entire job.

Prepare labels and accusations

  • List any accusations that they might make in response to your asks
  • List labels with respond with:
    • “It seems like _ is valuable to you.”
    • “It seems like you don’t like _.”
    • “It seems like you value _.”
    • “It seems like _ makes it easier.”
    • “It seems like you’re reluctant to _.

Prepare calibrated questions

  • Want to figure out what is important to them
  •  Examples:
    • “What are we trying to accomplish?”
    • “How is that worthwhile?”
    • “What’s the core issue here?”
    • “How does that affect things?”
    • “What’s the biggest challenge you face?”
    • “How does that fit into what the objective is?”
  • Be ready to respond to these with labels as well


Talk on the phone, not on email

On talking: aim to speak like a late night fm dj

  • Speak slowly
  • Pause
  • Drop intonation at end of sentences
  • Breath from your belly
  • Smile

Show appreciation for what they’ve given you already

Actively listen:

  • Mirroring
  • Minimal encouragers
  • Paraphrasing
  • Emotional labeling

Phrases to use:

  • “I’m sorry…”
  • “This is going to sound harsh…”
  • “What would you like me to do?”
  • “How am I supposed to do that?”
  • “Where did that number come from?”


Always Follow Up!

Short post, but an important one:

During last year’s recruiting season, everyone told me the same thing:

If you don’t hear back, they are rejecting you.

Somehow, I never questioned that until now.

Yesterday I spent about an hour looking up every company I applied to this year and following up with them:

[Recruiter’s Name],

Just following up as I never heard back after I (applied/completed coding challenge/whatever)—am I still being considered for this position?

Thank you!


The result? Five replies, three confirmations of rejection, two interviews in the next week.

Not bad. The lesson: ALWAYS follow up!

How I Found a Bug in HackerRank

For those not in the tech space, or for those who are but haven’t had to interview recently, one of the most recent trends in recruiting is to send candidates a coding challenge. The idea is to screen out those who can’t actually write code (apparently surprisingly common, see so that you don’t have your engineers interviewing someone who is clearly not qualified.

There are a few companies that have developed platforms that make it easier for companies to do this and by far the most popular is HackerRank. They give you a problem description at the top, a text editor to write and run code in below that and then an input to test on as well as the expected output for it.

After you write code that is able to solve the known input, the server then runs the code on inputs that you are not supposed to be able to see. This is to give companies a gauge on how well you are able to write code that is able to deal with edge cases that are not given to you.

HackerRank lets you see how many hidden test cases there are as well as how many hidden test cases that you have passed. This leads to many frustrating moments when you have written code that gives the correct output on every test case except for one.

About a week ago, [company name omitted], one of the largest and most well known tech companies, sent me one of these and I faced this exact situation. After working on the last problem for a bit, I had a solution that worked for eight out of nine test cases. Sigh.

I read the problem description again and identified four areas in which there could possibly be an edge case with one of them requiring a rewrite of the main data structure that I had used.

Being lazy, I obviously did not want to do this. I really wanted to know what hidden input I was failing on so that I didn’t have to add code for all four of these edge cases when they were just testing for one.

I got up to get another cup of coffee and when I was walking back to my desk, I had a really stupid thought: “Since I know what the edge cases look like, can I just raise a runtime error if I see them?”

I really didn’t expect this to work, but added the two lines of code to test it: screenshot-from-2016-11-02-20-07-27

then I scrolled down and I pressed the submit button:


Bingo, I knew which edge case the problematic input was and could skip writing the solutions for the other three.

HackerRank does have functionality to mask the error message, so you aren’t able to write a custom exception to dump the exact input, but this is still a massive bug and something that should be addressed urgently. I’ll be sending this to HackerRank and to the company that gave me the challenge.

Thanks for reading!

 Update (2016-11-07)

HackerRank’s CTO, Hari Karunanidhi, reached out to me:

Harishankaran Karunanidhi (HackerRank)
Nov 7, 03:51 MST

Hi Charlie,

Thanks for sharing the feedback. We have a tough job of finding the right balance between having the test secure and also candidate friendly. For example, hiding the type of error would make it really frustrating for a developer to solve a challenge.

In this case, kudos on tracing out the corner case. For example, your idea of “Since I know what the edge cases look like, can I just raise a runtime error if I see them?” is not something all candidates might get during an online assessment.

Once again, thanks for reporting this. But we’ll display the “Runtime Error” to make sure the product is easy for test solvers to solve. We’ll also work towards making better testcases, so that you are forced to take care of all the corner cases.


His reasoning is understandable, but I still feel that they should just mark test cases with errors and incorrect. Still cool that the CTO himself responded.