This is also the interview where they refused to continue unless I told them how much money I made (which I don't do anymore). The justification they told me was that they weren't going to give me a 20K raise if I wasn't making that much right now. I didn't point out that they aren't giving me a raise, they are paying me market value based on what the position is worth (to oversimplify it).
I was offered the job but decided not to take it because that plus the technical interview made me wary.
Even after 20+ years in the labor force, I've never understood that justification. "I'm a nosy bastard" at least has a ring of truth to it.
"Proof of previous income" was required at one place I applied years back, and I've heard similar stories from colleagues. No, of course, I don't bother going forward in those situations.
"What are you making now?" is crass. The good recruiters I've worked with phrased it as "what are your salary expectations?" or "the range is $x-$y - are you OK with that?"
I've taken it literally in situations where they actually meant it literally. "We will not pay you $80k until you can prove you were making $80k at your previous job". Insane, but it does happen on occasion. How those companies ever manage to hire anyone... I'm not sure.
It's best to immediately walk away from a situation like this.
Dude, that right there is the problem. They make a commission off your starting salary, so OF COURSE their primary concern is your past and future financials.
This is why I hate recruiters.
For the recruiter, getting you in at 160k is twice as good as getting you in at 80k, and infinitely better than you walking away.
As a candidate that currently earns 100k, an 80k offer is worthless.
(Threatening to) walking away from a deal is one of the strongest strategies in negotiation. But that's the one thing a recruiter will never want you to do.
Candidate: High salary > no deal > low salary.
Recruiter: High salary > low salary > no deal.
You are right, that the recruiter has an even bigger conflict of interest with their employer. But that conflict does not mean the recruiter's interests are aligned with the candidate.
(One way to align any interests is generally to repeat games. That's why internal recruiters are usually less sleazy than the external kind: they are at least clearly on the site of the employer. And honourable employers have a reputation to defend---another repeated game.)
"Considering your obnoxious lack of professionalism and the fact that your approach is apparently acceptable to the company, I'm not sure there's any offer you could make that I'd be excited to accept. But everyone has his price, so write down $500,000 for now and I'll decide how much to increase it after I hear the rest of what you have to say."
Getting a salary ballpark out early can save both sides a lot of time.
As a potential employee it's important to phrase it right as "If you are not going to pay at least X we are wasting our time". Where X does not need to be your current salary - but really what would be least it would take for you to work there.
If they insist on current salary be firm on X. Point out that this is based on what it would take you to consider them, and you are already taking into account a lot of factors like company prestige, type of work, location, lost options etc.
It is important to realize that you are not giving away any negotiating power by putting out a lower bound. One easy trick is to mention that you are also talking to other companies that already agreed to the same lower bound.
Also do not ask for or let them tell you an upper bound from the hiring company. If they end up really wanting you it will be harder for them to change that.
Getting a lower bound will help both parties. An upper bound you do not walk away from will hurt your position a bit though.
Has nobody here played poker? You don't just say what your hand is when you start betting.
Correct. They're just trying to figure out how little you will accept.
they are asking you to start the salary negotiation
Never be the first to give a number.
Always be the first to give a number and conditions.
Setting the stage is too important to let the other party do it.
There ain't no such thing. Salary negotiations are pretty close to zero-sum.
If you do strike a deal, that's along a fixed sum border.
But do keep in mind, that either party can always blow up the whole process at almost any time. This is important.
HR people do actually see current income as 'social proof' of your actual worth. This is not necessarily out of a desire to take advantage of employees, but they find it hard to justify to their bosses why they did no negociate a better deal.
I learned it the hard way, by trying to work part time (like 10hrs per week) while studying and then having employers unable to grasp that I was demanding a much higher salary because I was offering my undivided attention in a full time position. This was explained to me by a simpathetic (though probably naive) recruiter, who literally coached me to lie on my application so she could process me as a viable candidate.
I did not get that job anyways, but at least I learned to avoid mentioning the fact that I had been "working for peanuts" in the recent past.
If we assume that your minimum bid is in fact below their maximum offer, then the market should clear: you should get hired. Under such circumstances, anything preventing a successful conclusion to the negotiations is harmful to both parties, since there exists a price at which both sides would be satisfied that they're getting more value than they're giving. Therefore, anything eliminating or preventing such an obstacle from arising is beneficial to both parties.
The corollary is that employers who insist on "social proof" place themselves at a disadvantage; they're less able to hire, and the people they do hire will likely be inferior. They are giving up value every time they enter negotiations, not by overpaying but by failing to engage in beneficial transactions. Those hidden costs can be, and often are, far greater than overpaying by some small percentage on the transactions in which they do engage.
I am afraid, reality is more complicated than that. There are opportunity costs, and there are threats. (Read up about the latter in "The Strategy of Conflict".)
Threatening to do both parties damage, can give you a better deal.
I don't really disagree, but we might as well be honest about it here.
Obviously in a better world it would be possible to glean this information from an interview alone, but the bottom line is that interviews generally suck at informing how useful a candidate is going to be. A candidate who claims they've done valuable work is potentially exaggerating, and it's difficult to tell by how much. That's (part of) why we have resumes, and (most of) why an employer wants to know your previous salary.
Note that I'm asking this unironically. I know that "never tell anyone your salary" is a popular point of discussion here, but I have trouble seeing why it's any different from, say, a grad school asking for your GPA.
If I'm interviewing for a potential employer in an area with a higher cost-of-living, I'd (in a certain sense) be cheating myself to state my current pay.
But the bigger issue is that they rarely ever give their hiring range, so why give them more info that can only hurt me?
If they end up calling my current employer and that this employer gives them the number (which is extremely unlikely), I just tell them "What I'm making right now is irrelevant, I gave you the salary I think I'm worth right now. If you don't agree, I'll just walk, no big deal".
count = 1
count = count + 1
P.S. I don't remember exactly what she put down as my "line-count" I was pretty annoyed at that point, it might have been a much more reasonable 5000. :-)
"If I had more time, I would have written a shorter letter."
Some interesting attributions of that and similar quotes:
Sounds like you made a great choice :)
I have absolutely no idea of what my average LOC / week looks like and could not care less.
This is a really dumb metric.
Between Annotation processors & code generation plugins, it already means nothing.
If you factor in DRY, it is just insane.
Am I supposed to willingly write horrible and unproductive code just to increase my LOC / time ?
Getting a project of a given size done on schedule means nothing? Your company sounds pretty laid back. That's nice.
"Am I supposed to willingly write horrible and unproductive code just to increase my LOC / time ?"
It's a nice strawman you built there. The metric in your case would be average, custom LOC brought into production. So, it would hopefully be productive, great code at a certain rate. The rate varies among people and programming approaches.
rofl, you are assimilating LOC and actually accomplishing a task on schedule and you talk about strawman ? give me a break.
It's fairly shady negotiating to anchor the process one sided. If they want your salary they should tell you what the highest paid developer makes as well.
So you base your salary offer on my current salary, instead of what I would be worth to you guys? Good luck. We're going to be here a while, since I'm not going to disclose my salary.
At a certain huge company that sells seeds, they decided to start having both a base test coverage target, and a specific plugin that demanded that the coverage never went back more than half a percent from the high water mark on any given project. The engineering managers thought it was a good idea: As time goes by, we'd have better code coverage!
I joined a team that had an application full of repetitive code, because nobody had spent much time thinking about reuse. I decided it was bad for maintainability, and the team let me rewrite a big chunk of repetitive, well tested code. I shrunk the codebase by a good 10K LOC, and it still did the same thing. Teammates liked what I had written, and everyone was happy. But when I pushed it, the build refused to deploy, because now the code didn't meet coverage standards.
The manager was mad at me: you wrote all that code, but I guess your unit tests were sloppy! he said. But when I went and looked at the code changes, I had a 100% code coverage. Since I am not a football player, I just couldn't give 110%. So then we look at the reports, slowly, and saw that while I had full code coverage, the code I was replacing also had full code coverage, but mine was so much smaller, our total coverage percentage went down! 1000 lines of uncovered code, in a codebase with 30K lines, gave us better numbers than the same lines in our shinier 20K LOC codebase. And building tests for some really old, badly factored code just wasn't in our top list of priorities.
The people in charge of this system refused to change it, even though it was really not helping things in our case. So what did we do? Fool the tool, of course. Added a bunch of well tested dead code that was never going to get called in production, and wouldn't even get built into the binary, thanks to some packaging magic. We put it in a separate module, clearly marked as 'dead code to make Sonar happier', and we went our merry way.
Really? I always thought that it's the old, ugly and brittle code that needs unit tests the most. Especially right before the moment you finally decide to rewrite it.
Since then, I've taken some pride in trying to be a "net negative" (by line count), contributor to any code base I work on. Not always possible, but it's a good mindset to strive for leaner designs/implementations.
Not sure if it will work but I keep wanting to see someone try it. :)
- Edsger Dijkstra
No, it had nothing to do with my prowess as a young coder, but solely due to the fact that my predecessor did not know what a function was nor how to use parameters.
He had written unrolled versions of the same piece of code, with embedded SQL with minor variations in WHERE CLAUSE values which could be easily parameterized.
All I had to do after analyzing the code was move the code into a function and loop through it with different parameters values.
Such is life.
— Ken Thompson
However, I didn't need anyone to sign off on commenting out code and replacing it with something else. :-)
We had a saying: "Comment in a fix....". This is our way of saying to each other that we needed to re-write code and to get around "red tape" we would comment out and replace the code.
So if comments confused things, we removed them, with a comment that previous comments "were confusing" or "no longer applied" :-)
> "Measuring software productivity by lines of code is like measuring progress on an airplane by how much it weighs." - Bill Gates
PS D:\project\> (dir -include *.cs,*.cpp,*.h,*.idl,*.asmx -recurse | select-string .).Count
Absolute genious. There are likely to be less problems on a smaller codebase and when there are its much easier to recommend a rewrite of 1k than 10k
I would love to know how he reacted and what happened next.
git -c color.diff.old=green -c color.diff.new=red
Or an electrical engineer: "How many resistors did you solder? I want them all gone."
Or an aeronautical engineer: "What does the plane weigh? I was expecting a few more tons."
Or a traffic engineer: "Why haven't you put more stop lights in?"
Or a mechanical engineer: "More gears!"
Always hard to get the bean counters to appreciate elegance.
But negative LOC alone is just as useless a metric as positive LOC. It's easy to come up with examples where deleting unused code is actually harmful:
- Just delete all comments
- Remove platform code you are not using now, but might in the future
- Remove reference code because you are only using platform code
- Remove test code that is just not called yet, but really should be
- Remove code from a copied library that is now harder to keep current
This is definitely harmful, agreed.
Definitely. It's in the repo if you want to get it back, so there's no reason why unused code should be in your source.
Yes. Remove everything you're not using. It's in the repo.
And again. Remove it if it's not used. Or start using it. Nothing else is acceptable.
You should probably be pinning versions of libraries otherwise you're going to see things break in the future. Upgrading them is a feature.
Deleting comments aside, using negative LOC as a metric does encourage people to write better code.
- every deleted line meant we could have more content
- the code ran faster
- there were, axiomatically, fewer bugs (and we fixed a lot of bugs on the way)
- the code was more understandable
I have absolutely no idea of what my average LOC / week is and I would argue that it is a silly metric.
Last week I deleted 30k LOC from the project (~10% of the code base) :
-we used to have both the old & new version of the UI in the codebase so we could switch between the twos in production. Now that the new version is complete, there is no need for that.
-There were many deprecated parts of the app and unused resources, I did a big cleanup of these and I have even more work in that area.
This has resulted in way cleaner code, easier to apprehend for newcomers. The app is also lighter by 2 mo. Probably a very productive week overall.
I'd say I'd enjoy deleting 200 lines to adding 200. It's like sitting down in a freshly cleaned room once you finally get your chores out of the way.
"If you've already started working on it, how long have you been working and how many lines of code (if applicable) have you written?"
My response ... "I personally believe that using "lines of code" is a crude metric as it favors the sloppy programmer who doesn't write compact code and discourages code reuse by utilizing libraries and frameworks."
1234 LOC, but I personally believe that....
IMO, the answer to a question like that begins with a number (if applicable) and contains commentary only after the number. (I agree with your commentary, just disagree with the value of not answering.)