I had a job interview once where the HR rep asked me how many lines of code I wrote a week. I responded, "On a really good week -1000, I don't remember the exact figure." She was extremely confused by this answer and wanted me to give her a number. So she said, "I'll just put down 10,000."
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.
Don't be so literal about it. I used to get defensive about that question too, but the truth is they aren't asking you how much you are making, they are asking you to start the salary negotiation so they can get a feel for what it's going to take to hire you and describe you adequately to a hiring manager. It's just an opportunity for you both to ballpark the situation and eject early if there's going to be a wide disagreement about comp. It can be equally advantageous to both parties if you use it properly.
No... there are recruiters who are a lot more invasive and pushy (and a couple employers I've run across).
"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.
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.
I disagree. Recruiters have a conflict of interest that often goes to the candidate's advantage and against their employer's interest. The higher your salary, the higher their commission. And employers are fine with that because a good hire is better than no hire.
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.)
That is what you would expect, but they want to optimise both on commission and on throughput. If a slightly lower salary makes it easier to position you and get you hired fast, the cost of the lower commission is less than the cost of working on your case for a long time. It is the same with real estate agents. From that perspective, their knowledge of the market should theoretically set the price at the optimal short-term, hiring decision point. Nevertheless, for the employee and employer this is a long term relationship and it works out bad on both sides (lower salary than could be achieved for the employee, greater employee turnover for the employer.)
While a fair salary is ideal for all parties, optimizing for job satisfaction would be a wiser decision than optimizing for salary amount. Scoring a high salary may merely mean the new hire will be one of the first to be cut from the crew should the firm hit choppy waters... an outcome that recruiters do not need to care about.
I guess you're right, that does happen sometimes. In those cases you also shouldn't be mad, though, because they just gave you a crystal clear sign they aren't worth working for.
Just say "my salary expectations for this position is $XY0,000". I use it as an opportunity to set the ballpark for the negotiation. Sometimes bosses don't know what people are worth so they ask these kind of questions. Once we opened an office in a new country, and when we hired people, we asked them what they expected and gave them that + 20% because we really had no idea how much we should be paying.
> I've gotten "I need a number for us to continue" multiple times.
"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."
What's really fun about that is that most people I interview, when asked "what are your salary expectations?" answer with "I'm currently at XYZ a year"
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.
None of what you say has anything to do with someone's current salary. If I'm in a job paying $50,000 in a market where the typical salary is $80,000 and I want $100,000 then asking for the $50,000 number doesn't help anyone. It's just meaningless data that clouds the issue of what you are willing to pay to hire me. I can understand asking a candidate what salary they're looking for. That's useful. It's got nothing to do with their current situation.
Yeah I mean it really depends on where you are applying to work. If you are trying to join as a senior member of an organization negotiations have way fewer rules, but if you are applying to Google etc. below a level 4 position it seems pretty reasonable to not need to assert your individuality as an engineer by disrupting the system since you'll be ending up with a standard package anyway. Sometimes you just need to learn how that game is played and play it instead of changing it.
The actual dollar value is usually literally zero sum, but if you have a family and need a $200k salary with specific benefits as a hard requirement it's going to be helpful to get that out of the way up front. On the same note, if you want a $200k salary and only make $180k it can be useful to say you are currently making $200k. So again, this moment can be advantageous to both parties.
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.
It is, in fact, possible that some aspect of a negotiation can be beneficial to both parties, but not for the reasons the parent suggested.
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.
> 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.
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.
Depends on the BATNA; failed negotiations can quite easily be negative-sum if it results in not hiring someone and both parties having to spend effort continuing the search.
Actually the truth is more like "I want to pay you as little as possible for you to work here and be productive." People who're worried about money are really bad at their job. They spend all their time thinking about something else. If someone is willing to accept a job on a salary that isn't really enough to live on (say, because they don't know how expensive the area is) then you should pay them more than what they believe their minimum is. Unfortunately hiring managers quite often fail to understand this.
Serious question: Why is asking your salary any less relevant then asking for your previous place of employment? If I say I did X on project Y at Google, that's a pretty incomplete picture of how valuable my coworkers and bosses found my work on project Y. Thus, it seems like a salary is another potentially helpful data point indicating how valuable I've been to previous companies.
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.
I live in an area of the US where the cost of living is low (think $1.60/gallon and $725/month to rent a 2-bedroom apartment).
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.
It's a well-known tactics to lowball you. The standard answer is "I'm not allowed to disclose it" and if they push, I just give them what I want them to give me minus 5% regardless of what the actual number is.
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".
Ha, I guess the developers they are hiring used to be sci-fi writers! But don't most writers say the hardest part is cutting words out of their book and cleaning up language?
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. :-)
Are we counting the code my macros produce? As far as git is concerned I might be down a couple hundred to a couple thousand in a good week, but if we count macroexpansion, I'm rolling in the LoC.
What is the current average in a language like C# or Java for a skilled developer? Average that goes into production rather than what's likely thrown away.
In a week long project (some supporting tool, or something similar) it's easy to write 10k lines a week. In a 6 months project, 10-100 lines are more likely, and in an "eternal" software that is already mostly written, 0 is a perfectly fine number.
I dread the day someone starts tracking LOC vs productivity in TFS. I might be switching between C#, SQL, CSS, HTML and Javascript on a busy day. A context switch == a productivity hit.
That was actually one of my favorite moments! Someone pulled up the TFS chart of lines of code added/removed per developer. First, I removed way more lines then I added. But second, the number of lines I removed was (completely accidentally) the same as the number of lines my team lead added. When he saw that, he just kind of looked over at me to make sure I wasn't following him commit by commit to rewrite his code!
"Between Annotation processors & code generation plugins, it already means nothing."
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.
I'd be very tempted to ask the HR person for their salary and/or ask for the CTO/CEO's salary and/or some confidential revenue number or something like that before ending the interview.
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.
> 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
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.
It's not just old managers that dislike negative lines of code: Static analysis tools dislike them too, under the right bureaucracy.
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.
> And building tests for some really old, badly factored code just wasn't in our top list of priorities.
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.
4 months into a new job, and I realized I had contributed about -4000 lines of code. I thought, how weird it would be to explain (especially to someone less technical), that I'd pretty much just been deleting code since I started. I'd also added a number of important features along the way.
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.
There was someone at Google whose total code delta over his tenure was something like -2M. Yep, two million lines of code deleted. May we all be that productive.
Show management a picture of the code. Show them a visualization of all of it with its myriad connections. Tell them you just got rid of 4,000 lines of that crap. Show a visualization that's smaller and connected neatly. Promise to continue attempting this incrementally and safely in between new features. New features that are coded similarly neat.
Not sure if it will work but I keep wanting to see someone try it. :)
I've pretty much exactly that, and it did work. Though it was at a company that had a headcount of 15, so in a larger org it might not go down so well.
We've done this as a recap of successes with a few clients, now. It helps that the old stuff was stupid slow and ours has been both understandable and faster.
One of the most interesting experiences I had very early on in my career was reducing a 12,000 line C program to a roughly 1,000 line version (in C itself) without losing any functionality.
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.
I've had that exact same scenario about 4 years ago with a very large website (you've probably used them) which was put together in a hurry. The site was written in Java and each and every access to the database contained the exact same pre-amble, a bunch of database interaction with the aforementioned change to the where clause and then a cleanup section. Typically 50 to 100 lines. There must have been 100's of these copies in the code. In the end I moved the db open and close stuff to program startup and shutdown and replaced all the rest of it with a single function with a couple of parameters. The code suddenly became maintainable again.
... I remember deleting ~500 C++ files .. they were all classes that differed by a constant, so I just passed in a parameter. Was not popular at all, they liked lots of files.
I worked at a furniture company where in order to delete code you had to have the head IT guy, the IT Director and an outside consultant sign off on it. Yes, that is right! 2 people that didn't know how to code and an outside consultant that we paid to look over "IT" moves before we made them.
However, I didn't need anyone to sign off on commenting out code and replacing it with something else. :-)
I was one of 2 coders that worked there, but we did different things. We were supposed to do "code reviews", monthly with each other. We did, but we usually went to a Denny's (open 24 hours) and literally hung out there for 15 hours, ate 3 times, etc and reviewed things. We cared about code quality and not having to band-aid.
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" :-)
I finished up a 24-month project earlier this year on a codebase of ~1M lines in which I dropped a net of almost 100k lines of code and reduced the main Visual Studio solution from 325 projects down to 105 projects. Compile times dropped from ~40 minutes to 6 minutes. If only all my projects could be that fun.
Once had a compiler QA gig. Was kinda lazy. So, I wrote a nonsense code synthesizer. Just take the BNF and belch out code. Millions and millions of lines of code. A fun variant was to create a class hierarchy that would run 100's of levels deep. I showed it to marketing. They asked: "Can you do that for <competitors> compiler?" "Sure thang!". Soon, there was an ad showing how our compiler could handle a lot more bloat than their compiler. Not my proudest achievement.
I worked somewhere where the support manager somehow managed to get approval to bill his costs against each product group based on the lines of code in their product. We spent part of a week refactoring and reformatting to cut it by 70% before we gave him our numbers.
Stock market indicators in China are reversed in colour from the western world (up=red, down=green). Sometimes I wonder if Github really should be flipping the colours on diffs for Chinese language users for the sake of consistency.
Negative LOC while retaining those things would be optimal, if you can manage to reduce the size of the overall codebase while fixing issues and/or adding features it's the best possible outcome.
I deleted a couple thousand lines this week. It felt awesome. But you'd have to admit that rewarding based upon deleted lines of code could be even more dangerous than rewarding added lines of code.
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.
It's funny that other programmers feel the same way. I've never discussed it with other developers much, but I also derive a degree of satisfaction when refactoring if I leave the code with fewer lines than it had originally.
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.
I was surprised when YC asked something similar in their application:
"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."
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.)
Similarly, the number of git-commits is also a poor judge of how much work was done. When CI builds automatically build release notes based off of the git-log since the last successful build, this can be deceiving.
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.