The truth is that there are lots of different ways to get a job, each with varying levels of effectiveness that depend A LOT on your situation. An effective job search is one where the techniques are tailored to the situation, and the amount spent on each reflects the expected effectiveness within that situation.

Example: A few years ago I got laid off. I had a few weeks of notice, some severance, and savings, so I decided I would be a job seeker full time until I got a job I really wanted. I followed the advice in this article almost to the letter and specifically avoided lots of the typical job hunting techniques (sending resumes, filling out job applications, talking with recruiters, etc...)

I did a lot of research on companies I wanted to work for, started meeting with people (I didn't know anyone who worked at those companies), sent a lot of unsolicited emails to get an 'in'. And after a few months of doing this I'd made a lot of new connections, but no legitimate opportunities. By this point I was starting to panic, so I broke down and started doing the 'traditional' job hunting stuff. Two weeks later I had an offer from an application I had submitted online.

Don't limit yourself to just one technique. Try a lot of different things to see what works for your situation.

- Dont care about getting the best-ever salary thats on offer. If the developer finds out that other companies are offering better salaries, they dont hesitate to re-negotiate or jump ship.

- Put more emphasis on the work-life balance rather than the work. This means one may not get excited enough about the work to seek out people and companies, but when they get emails from companies or recruiters, they dont mind starting a discussion if the work is decent and the people are good to work with.

This doesnt in anyway mean that the developer doesnt like coding. Just that they feel that its not worth the effort to fight for more money if they feel that what they are making is giving them a pretty good living.

"Rather than measuring proxies for talent, we just decided to try to measure talent directly."

The problem with this is that the technical side of things is much less important than how people work together. Google's Project Aristotle has shown that technical chops matter far less than people being empathetic, tolerant and good listeners.

I've worked for companies where the primary focus was put on "empathetic, tolerant, and good listeners" where everyone was afraid to rock the boat. These were the least favorite environments of my career as they attracted lets just say not A players - and the inability to get things done was astounding. Any talent that accidentally found it's way into the company never lasted beyond 6 months.

There is a balance. You need the raw tech talent to be there to get the project completed, but I agree you want those folks to play relatively nicely together.

The most functional teams I've been on have been relatively small, full of very opinionated but extremely talented people, and to an outsider it would have looked like organizational and social chaos. However we all loved that period of our lives, and speak about it fondly. When you're on a team that is rapidly getting things done, but is passionate enough about the work to scream and yell it's refreshing vs. the banality of the typical corporate dev/tech/IT job no one actually cares about.

So for me, I'd much rather work on a team of highly talented opinionated assholes than a team of untalented nice folks.

If they're afraid to rock the boat, then you don't have a team of "empathetic, tolerant, and good listeners"

http://www.nytimes.com/2016/02/28/magazine/what-google-learn...

"Imagine you have been invited to join one of two groups. Team A is composed of people who are all exceptionally smart and successful.... This team is efficient. There is no idle chitchat or long debates... Team B is different. It’s evenly divided between successful executives and middle managers with few professional accomplishments... At the end of the meeting, the meeting doesn’t actually end: Everyone sits around to gossip and talk about their lives. Which group would you rather join?"

I knew I'd want to join Team A: smart, efficient people who get stuff done without idle chit-chat.

If you believe the article, Team B will be less effective because they are too individualistic, and walk over other people. They didn't actually say "self-centered", but it was implied.

I don't see how you can't be both efficient, smart, and empathetic; I don't see why there has to a choice. I've worked with my fair share of a-holes, and it's no fun. But it's also not fun working with schmoes who spend more time gossiping over the watercooler than getting stuff done.

I think people hate to admit that things can just be "good enough", because the phrase "good enough" sounds like we settled without putting forth enough effort. It's a false dichotomy. Things can be good enough in one area yet outstanding in others.

There are other factors, such as the level of autonomy I have, that weigh into things too.

Keep your eyes open! I thought the same thing about six months ago, but it turns out my price tag just sat in the area between what I thought people were willing to pay me and what they actually were.

Being a shrewd negotiator is an absolutely critical skill in life, even if you don't want the best-ever-salary. If you know how to negotiate the best-ever-salary, you can trade it in for things that do matter to you.

Don't want tons of money but want great work-life balance? You can turn part of that salary into more vacation time, more flexible working conditions (remote?), one day off every single week, more benefits, and other things that matter to you.

Money can be used to purchase many things - the ability to negotiate for more and take less can also be used to purchase things - in fact they can purchase things not available in cash (see: extra vacation).

Personally, I'd rather not spend my life playing games with people who are constantly trying to capture the most value in a relationship at the expense of the other person.

Tell me what the job is, what it's worth to you, and let's mutually determine if this relationship is a fit.

That's basically the same as Patrick's advice. The difference is that you're expecting an employer to do that naturally, and he is encouraging people to ask employers to do that. It seems to work pretty well, anecdotally, and it's not all that scary.

Money and time are just poker chips - big, valuable ones, but 2 among many. Figure out what's important to you and what's important to the company, this sets the board. Then start trading chips.

The conversation isn't the hard part, intimidating as it might be. Determining what you value, and how much, so that you can begin the conversation is where it's tricky. It's easy and comfortable to skip this analysis, pretend that money and time are the only variables in the equation, and then leave something else you value undiscussed and unclaimed.

There's a great article (2012) I often refer junior developers to who are interested in approaching negotiation in a more productive way (with an emphasis on the most important chip to many of us, salary): http://www.kalzumeus.com/2012/01/23/salary-negotiation/

What if I am absolutely at peace with what I have? There are plenty other skills that I would put as more critical than negotiation. Its not an absolute.

"Don't want tons of money but want great work-life balance? You can turn part of that salary into more vacation time, more flexible working conditions (remote?), one day off every single week, more benefits, and other things that matter to you."

I want to make the same point as tetraodonpuffer. Its not easy to say I will work 50% less, give me 50% less salary.

Negotiating is something you do while you are in a job and while you are switching jobs. Even when switching jobs your negotiation ability can mean a dramatic difference in how much you are compensated.

> "but if you are looking for salary increases, negotiating is only one way to get it."

Well no, negotiating is the only way you can get it - you have to negotiate with the next company too. Switching jobs might get you a 15% raise by default, but a good negotiator can make that 50% instead (or 15% + a bunch of other perks).

According to other people on here (including patio11) its a more subtle, nuanced and longer drawn-out game.

Edit: Key point here is that I am not gauging how much I can get out of the company. I have a number in mind that I am comfortable with, and asking for that.

Edit - Response to the comment below from Consultant32452: That was never in question, I fully am aware of the lack of money obtained as a result of non-negotiation. It just doesn't matter to some people, as they are not optimizing for the highest amount they can get. Maybe they are already well off, or the salary they "non-negotiated" for already is a good-enough amount for them, or are optimizing for other things. Hence once cannot say that negotiation is "necessary".

there are not many companies hiring you for full time at $x that will allow you to work 3 days a week for 50% of $x, much more likely they will let you go and hire somebody else (unless you've been there forever and are the only person that can do something, in which case the company should worry about you getting hit by a bus)

money can be used to purchase many things, but in our field work/life balance is not one of them, unless of course you mean be lucky to have a good exit and then for the rest of your career you can work on what you like for part-time, but that is not realistic if you need a salary to put food on the table

Your calculus is a bit off. A company will not hire you part time because employees need time to learn the job. This includes the culture and political aspects.

Once you've been there for awhile, that all changes. Now you're a part of the company, so the company is going to be way more willing to jump through hoops to keep you around. The reason they wouldn't let you come in at 3 days a week, is the same reason they will start letting you (if you negotiate it right) after you've been there a year or so. It's tougher and more expensive to assimilate a new employee than it is to make a productive current employee happy.

If you can show to the company that the bottom line won't get impacted by a proposed change, make it clear that you'll leave unless you get your way, (hard to do convincingly) and offer an acceptable path to move from A to B, then you too can find work/life balance.

It's not impossible, but it's not easy either. I'd put it as being slightly harder than getting a 20% raise, which I've done. Now that I think about it, if you want a 20% raise, then one path to getting it might be to start the process of negotiating something like this, (to let them know you're serious about not being happy) and then come in one day and ask for more money. If you play your cards right, they'd be much happier to open up the checkbook than to deal with the prospect of having half their workforce ask for the same thing you just got. (that's the real reason they don't want part-timers. Even if they can trust you not to abuse it, what about the next three people that ask?)

We've been conditioned to believe that $$ (and in our field, equity) are the only knobs that can be adjusted during negotiation. In reality the actual field of negotiable variables is much, much wider.

YMMV of course, and negotiating for non-cash things can often be harder than negotiating for more cash, but it's eminently doable and is in fact done all the time - just poorly advertised.

Note: this is also why ability to negotiate for cash is and important skill. It's often easier to negotiate for cash and then trade that cash for non-cash benefits rather than negotiating directly for what you actually want.

I'm working in the same field as you, and I talked my employer into a remote position abroad in a region with more statutory leave than in the US, working four days a week. All this was done without a pay cut.

Knowing your own worth and having a clear idea of what you want from life allows you to buy work-life balance.

Exactly. But then most people will just bend over and wilt at having to deal with a car salesman, as if that's the gold standard of having to negotiate something (it isn't by any stretch). Or they will disparage and throw barbs at the same, as if a great price should just be handed to them on a silver platter.

Fyi, you are being idealistic here and not realistic.

Many, many companies will block you on taking unpaid time off and/or more flexibility. Too many for this to be a reliable option, particularly if you are an expensive employee and don't want to cut your salary massively.

I literally asked to work remotely [same hours, salary, etc] and their response was +1 week PTO, +$X/year instead. Basically, I can't cut my salary enough that they'd let me work remotely. I'd have to find another job.

Some things money just doesn't buy.

In one gig I got 6 weeks vacation, workweek not to exceed 45 hours and an Aeron chair. You still need to grok your value, but fringe benefits are usually more flexible because you can establish a value for them that is often more valuable than the value to the counter-party.

Next.

I'm working my existing software engineer job while I build up my customer base on my side businesses. Your interviews and shit riddles can fuck right off.

The best part is when the riddle (perhaps their explanation) doesn't make sense, or the coding test doesn't work because there is a firewall on the guest wifi that prevents it, etc.

I had a startup interview last year where they were a well-funded start up full of PhDs. Had a hiring screen (with non-trivial code), a full day of interviews over the phone/etherpad, a conversation + coding interview with the frickin CTO. This was to decide weather to fly me to the Bay are for the actual interview (was on the East coast). I had a full-time, high workload job at the time (constant crunchtime) ... so this was brutal on me. Never doing this again.

I am with you though in principle. Some fizzbuzz-like test is OK, I understand they want to know if you can code at all. Something like code review where you think aloud is fine too. But take home assignments, whiteboard coding, huh.. An acquaintance of mine had to conjure a working spreadsheet application in one and a Space Invaders clone in the other. Mind you, none of the jobs had anything to do with spreadsheets or gaming.

If my living would depend on it I'd do it, no question. But in a relatively liquid job market of today I'd ether pass or offer to do it at a competitive hourly rate.

First, negotiating live is often difficult and it seems somehow job seekers are somewhat surprised to find themselves negotiating (or talking money at all). You need to be prepared for the conversation, otherwise you will find yourself throwing out numbers that you will often regret. Expect that you'll be asked these questions at every point in the interview process and be prepared to answer - just like you may study technical topics.

Second, in negotiations job seekers tend to mistake silence for a 'no' answer. "I'm looking for 130K". Manager is silent for 10 seconds. "...but that number is negotiable". Don't do this. Once you state your number, don't speak until the other party has spoken - otherwise you are negotiating yourself down before getting an objection.

Lastly, it can be rather powerful for the company to envision you starting work (the end goal of negotiation) during the negotiation process. Instead of saying "Can you make it 130K?" as a counteroffer as Patrick suggests, it can be stronger to say "If you are able to offer 130K, I am willing to commit to a start date of MM/DD/YY." It's a subtle difference, but asking for a number without context can be mistaken for "negotiation simply for the sake of negotiation", whereas an offered start date lets them know you're serious and committed to the negotiation.

EDIT: And as much as agency recruiters are maligned, Patrick's mention of having an "internal champion" isn't much different than an agency recruiter's representation. Sending resumes to "jobs@company" is ineffective. As an agency recruiter, if I'm presenting your resume it is going direct to the decision makers, it's being presented by a trusted source with credibility (for some agency recruiters anyway), and it's not just a resume but rather a short letter outlining why this candidate is a fit for the role. Not to mention, when negotiation does come up, the agency recruiter will have experience and know both the salary ranges and negotiation tactics of the hiring company.

So if you look at the opportunity cost of effective negotiation, the value prospect doesn't look half as clear. If I want to buy a house, the actual negotiated price is probably somewhere down around #8 on my list of considerations. Time spent looking at comps, finding a good inspector, understanding the real estate biz, could be far better spent.

I agree that you are only influencing a relatively small percentage of the outcome in most cases (perhaps higher than 10% though), and at least part of that 90% you refer to consists of the image created when you were first introduced to the employer. Your resume, profile, even your previous employer's identity - that data gives an employer an initial impression of your price tag and influences where negotiations may go. This is even before the interview.

This is literally the biggest part of negotiation.

https://en.wikipedia.org/wiki/Best_alternative_to_a_negotiat...

Sure, if you have nothing better to do, go nuts.

It's very refreshing to hear this advice from an agency recruiter, because they are indeed maligned here and elsewhere. Part of the problem I think, is that the incentives of the recruiter are rarely aligned with the candidate.

If we are talking about an agency recruiter representing 15 different candidates for one position, clearly the alignment isn't there.

For smaller agencies like me (solo) doing lower volume work and working with startups, I find that my incentives are almost always aligned. If I only have one candidate submitted for a position at a given time, you can be sure that my incentive is for that candidate to get the job.

A system where candidates paid recruiters as a "job agent" would ensure aligned incentives, but candidates aren't likely to pay for a service they currently get for free (understanding of course that the hiring client is the primary recipient of the service as most view the relationship).

No need to dance around it so much. Don't worry about how to phrase it! Just tell the recruiter, "No I'm not going to discuss salary until we're actually negotiating." There's really ZERO need to dress it up. They know the game. Just stand your ground, and say "no", "no thanks", "really no", "not yet"... until they say the team wants to move forward with an offer. NOW we can discuss.

I'm saying this because engineers are already nervous about how to negotiate the process, and there's no need to make it even more stressful by worrying about how to delicately phrase things.

Small startups may be playing with their runway and so need to know where you stand in order to know whether your salary expectations will impact the runway too greatly.

You might be able to play this game if you are personally being recruited for something specific and/or working with the founder or a senior enough person in a large co who can break you out of the bands. But otherwise you risk the recruiter simply not qualifying you for consideration.

(I've hired many, many engineers in my career)

Company: "We can't possibly give you a raise! 'The book' says we can only pay you this much and no more."

Me: Uhh, ok...

[A few months later]

Me: Well, bye!

Company: OMFG WHAT COULD WE HAVE DONE TO RETAIN YOU???

Hah! I just had this happen to me last month. My wife accepted a position (at her dream company) on the other side of the state. That means we're no-questions-asked packing up, selling our home, and moving for this opportunity.

I told my manager the news and gave him the choice: The company can transition me to full-time remote or they can have my resignation (which I had typed, printed, signed, and brought with me).

So, that afternoon, I'm in the HR managers office. They (HR, not my manager -- he is an amazing, caring, understanding person who laughs at this story harder than I do) literally pulled "The Book" out and pointed to some section of text while stating, "ENGINEERS ARE NOT ALLOWED TO WORK REMOTELY!" at me.

I'm still there, we made it work, but it took almost more effort than it was worth.

Raises small after hiring

"Why is everyone in this industry such a job hopper?"

I was pretty happy :D

They know the game but it doesn't mean they'll play accordingly. I've had plenty of recruiters tell me they can't realistically move forward unless I give them a number and they get aggressive about it. I don't but I imagine most do. So in a way, I can see why he suggests dancing around the topic.

Unfortunately, I don't have enough hours in the day to interview good candidates who might or might not be willing to come down on my max comp.

By having your recruiter filter resumes by comp, it may be that they're accidentally throwing out just those few resumes that were actually the strongest! Maybe you could have negotiated to a good number for both of you.

I'm a strong believer in the philosophy that you need to walk in the door knowing you want to work somewhere. If you don't know already then you've done insufficient research or are insufficiently motivated and it will show.

Starting right out of college I picked where I wanted to work first and then started making the connections to make that happen. I always volunteer to work for free prior to getting hired. Why? because a work-to-hire internship, no matter your level of experience, is better for both you and the company. It's especially good if you don't fit the traditional resume of someone in the role for which you're applying. This works especially well with startups since their hiring practices are flexible and they are cash conscious. Four out of my last 5 jobs have been landed like this, the other I was recruited.

You should be excited about the specific company you're talking to. You should want them to succeed from day one. This will make you stand out from the crowd of "job seekers." You're not looking for a job, you want this job and you're ready to buy.

The main problem is that it is impossible to understand the company and how it operates from outside. And larger companies are divided into organizations and each organization is quite different. Of course, it is very important to investigate the company and learn as much as you want about it but be aware that information you gather might not be correct and up to date: there will always large number of unknown unknowns.

The other problem is that "always volunteer to work for free prior to getting hire" is that you are starting your negotiation from very very low anchor.

In short, do not think as buyer (I want to work here), you need to think as salesman (I want to sell myself).

What you're recommending (doing the background research on companies) is useful, but the worst jobs I've had have been the ones where I didn't do a good job interviewing my coworkers, and was just excited about the product, or the theoretical culture.

This sounds like a perfect way to devalue yourself to any potential employer.

Anything longer than 2 weeks, and I'd expect full benefits, possibly a signing bonus, and I would speak at length before hand to get specifics on exactly how I will be evaluated and which criteria will be used for determining if a permanent offer will be made.

This scares away most crappy companies and acts as a good filter to find good employers.

Part of "walking in the door knowing what you want... and owning it" includes understanding your worth to the company.

A company must also recognize your worth UP FRONT. Unpaid internships vary from corrupt to demoralizing. At best they set the wrong tone. Don't fall into that trap.

One the quirks of human nature that if you give the employer/customer/client a "deal" up front, when you switch to charging them market price, they feel ripped off.

I've seen a case where, to go up the ladder at a certain company, the best way was to quit, then work somewhere else for a time, then apply for the position you wanted to get initially... (no need for having improved any skills, external hires are just evaluated differently)

Many companies, however, hire paid interns on a "try before you buy" basis. Always go for at least one paid internship while in college. Not only do you get to show off your chops to potential employers, it also looks great on your resume for other potential employers down the road.

Still, lot of time went away for me, because I didn't want to go to other places. I believe this is good advice, but you still need multiple options, which means it's better to prepare but spare your own time: make sure the company invests in you as much as you do in the company at each step (even in the beginning...a cover letter is OK, but nothing more, like free work).

"The winner of any negotiation is the one who has least to lose"

Why shouldn't the company have to prove they are good enough for you to give them your life?

This isn't a romance novel, it's business.

It's like, yes, you've spent 20 years in progressively more architectural roles, however the decision to hire you or not is based on whiteboarding algorithms you last had to legitimately write out years ago in university and crammed on for a few weeks before this interview.

While I was in university 20 years ago for fun I wrote an iterative AVL tree library in C (everybody else seemed to do it recursive), it was difficult but rewarding, but not something I am very likely to do nowadays and if you ask me to whiteboard the rotation logic I am not very likely to do it correctly and would have no impact whatsoever on my ability to do the job at hand (because in a working environment if somebody asked me to write for production say a red black tree from scratch I would not trust my memory but take out my Cormen book and go from there, or look at AOCP)

When I have interviewed in the past, I've always tried to ask more about the candidate's past and whys of certain decisions, if somebody put on their resume that, say, they designed an API for something, I might ask them what they did for versioning, for schema, what about atomicity, do they expose txns or not, drawbacks for each, and then branch out towards general concurrency and so on and on, you can learn a lot more about how somebody thinks by drilling down from something they worked on than by hazing them on algorithms 101

If you find interviewing beneath you, what else about the job are you going to find beneath you?

Do you find it beneath you, or is that just some kind of excuse for a worry that you might not do well in an interview?

I've interviewed for various jobs tons of times over the course of my career and I've never minded a coding session (either on a whiteboard or an actual computer). They're never really all that hard. It's an easy way to show your stuff and give the company more confidence that you actually know what you're doing. It's not a big time commitment. What's the problem?

I don't consider interviewing "beneath me", but its a two-way street. I prepared for my job and this interview. If the prospective company shows a serious lack of skill/professionalism, its not only a red flag, its demoralizing, especially when they approached me. I've had this happen multiple times. I've also had great, well-considered experiences. Thank goodness.

Some people just seem to get UPSET about it though. I guess that's the real part I don't understand. Why the intensity? Not from you specifically, but from some folks.

Until you have had dozens of them and they become the rule rather than the exception.

> it's not like good engineers lack for opportunities these days

That is a very myopic view. Outside of a few hot areas and technologies getting a job is very much a meat grinder.

If you've interviewed tons it means that interviewing and whiteboard coding algorithms is a skill you have developed and are keeping current (because you interview tons, so you do it often) so you actually enjoy "showing it off" given that it is part of your core competencies

I would love to do an interview where there is a genuine technical discussion on actual hard problems one might find in a job (say, expanding on my scenario above, what are the pros/cons if you design an API to expose txns, why would/wouldn't you want to do it, and mitigations/tradeoffs you would have to deal with in each scenario) what I wouldn't love is going for an interview with 20 years experience and being asked to whiteboard random algorithms off the top of my head unless I am applying for a position where that is required (hint: I wouldn't)

All I, and others, want is for interviews to reflect reality, where you ask me what I am good at, I show it by examples and answers, and then I ask you if what I am good at is a good fit for the position, where you ask me what type of environment I work best in (collaborative, go and do your own thing, agile, waterfall, ...) and I ask you what type of environment your company provides and if it's a good fit, and then once we figure out that yes, I can work here and what I can do for you is what you need, we have a mature discussion on compensation and it's all done.

Assume you decide to have a custom house built and are interviewing architects for the job, are you going to ask them for their portfolio, for their ideas on flow, for what architects are their inspiration, for how they would be able to make your ideas on how a house should be real, or would you put them in front of a whiteboard and ask them to draw a bathroom cabinet from scratch and fail them if they forget to put the stop on the rails so the drawer does not come out when you pull it out?

Honestly if someone asked me to code a red/black tree, I'd probably say "I remember that term, but I don't for the life of me remember what it is exactly. If you want to give me part of the answer I can probably logic out the details on my own but I'm not going to do well on your memorization test."

Not always. Interviews can be a very stressful and uncomfortable experience for some people. Even good interviews that make sense when the candidate is a perfect fit. Especially when you aren't job hopping and interviewing every two years so you're out of practice.

Honestly I don't even care to interview people, I'd much rather not.

A) the benefits of finding the best possible job for you can be huge

B) the degree of annoyingness for this one is soooooo low

Hahaha, I feel like this was taken directly from one of my HN comments.

https://youtube.com/watch?v=l789l6np-qA

https://twitter.com/mxcl/status/608682016205344768

If you're stepping up from writing web apps, you should have done some homework first.

At this point it's only being used for its Computer Science signalling value. JavaScript doesn't even have true HashMaps, and it's unlikely you'll find yourself implementing them while building a web app.

It's just one example of poor interviewing practice but it's not the only problem.

We could write a thesis on this, right? and we would disagree wildly, but in the end go put up your amazing UX n youtube and show me how memorizing the Algorithm Design Manual helped you create that amazing UX. UI work is mostly art and craft, with math/cs still relevant but applied from an intuitive dynamic center of your brain, not stored and ready to put on a white board on demand.

IME there are platforms (Ruby, JS, others) that have such high method dispatch overhead that the fastest "algorithm" is generally the one with the smallest stack-trace for 99% of problems.

It can be a very very very difficult bar to overcome.

I've only ever seen algorithm choice play a meaningful role in traditionally fast/compiled languages. YMMV.

Anyways, that's my experience with Ruby. Since each allocation (at the time) took 23 bytes of memory, even object graphs c# or Java might consider fairly modest (say loading 10,000 rows with a dozen fields into an Array<User>) would burn through a silly amount of memory comparably and probably trigger a GC cycle.

We're talking nanoseconds on the compiled side vs hundreds of milliseconds.

It takes a very very high N to overcome that sort of issue. One you might run into in scientific computing a lot more frequently, but not the sort of issue you'd often (if ever really) run into writing a web-app.

But, I can see how if they job doesn't require data structures and algorithms (say, just a simple CRUD app), sure, this type of interviewing is not beneficial.

Were they expecting you to account for collisions?

If you ever have an array of a few thousand or hundred thousand items, knowing how to make a hashmap can be pretty useful for performance even in js

For example later on they were trying to test me on JavaScript type irregularities. I did not realise that `typeof null === 'object'` or think this was important in practice (although I expressed no surprise as when I'm trying to test any JavaScript type I generally use a high-level interface to avoid JavaScript 'wat' moments). They seemed to think I'd be doing if-elses at the top of each function in order to perform the type checks that Java would have given me for free. I mentioned that 'flow' would be a better idea if you weren't happy with duck typing, but this probably sounded like I was trying to dodge the question to a Java developer. In practice when you're writing JavaScript code, it's popular to be lax about this kind of thing and write code like `config || {}.property`.

In conclusion:

I think that Computer Science is useful but less useful here. I'm actually now mid-way into some Coursera algorithms courses for my own personal learning as I think they'll be very valuable in other tasks.

I think the problem was that you could tell that they were primarily Java programmers by the topics that they gave importance. I'd say there's a strong chance that they'll hire somebody with a similar skill set to themselves and will not end up writing natural, best practices JavaScript.

People hiring in languages and domains they do not know well can bias themselves with the wrong kinds of questions and opinions. This seems to be a common interview failure case.

The idea of "do your homework" for interviews trivializes professionals down to meaningless data points where real experience and past accomplishments are all rendered as null.

JustSomeNobody figured that if the interviewer is quizzing you on data structures and algorithms, surely the job you're applying for must rely on such knowledge. If only.

* Didn't study CS.

* Didn't go to "brand name" school.

* One of my job titles (which currently comprises half my software experience) doesn't say "software engineer" or similar on it.

* You know Python; we use Ruby (or similar)

It gets demoralizing after a while, That's the main reason Patrick is right about bypassing the resume black hole. It just doesn't work. I seriously wonder about the number of interviews I would have gotten had I crossed out the school I went to and written "Stanford" or "Berkeley EECS."

I've got 3 years writing Python software, so it should start getting a little easier (and it has -- very little).

PS I'm looking, and my email is in my profile if anyone wants to chat a bit. :)

* Needed 5 years experience of 4 year old framework, you only have 3.5

* Didn't mention vi. I was convinced this was excuse, phone call to recruiter seemed to indicate dense recruiter and he thought it as important as mentioning C++ or Java. Why it mattered was another thing.

* You don't mention specific flavour and minor release of OS.

* You don't mention degree. I'm past 40, why does this still matter? In fact you're the first to ask in 15 years...

Not to mention all the false positives from interfacing with some other language or app.

Memorable interview - Recruiter had completely falsified my CV and given me a ton of experience I simply didn't have along with taking away a good chunk I did have. 5 mins in and it was an obvious farce and I handed interviewer an accurate CV. We had a bit of a chat and agreed it wasn't something I'd want or they'd offer.

It's like being picked for a basketball team. You might be able to nail three-pointers all day long, but if you're only 5'8, be prepared to be picked last.

It's even worse with recruiters, because sending a bad candidate has the potential to lose them out on a lot of future business. So they have a huge incentive to play it safe.

They were not interested because I had a lot more experience with Java and Linux than with Windows and .NET.

Lesson learned, now I hide less relevant experience and highlight the more relevant experience. The "holes" is my resume can always be explained later.

Also, python didn't strike me as a hard-to-sell language.

Data science might change things, but it's still a very new field.

If you're looking for a dev job, you should learn Ruby unless you have an irrational disdain for it. It's close enough to Python to be a fairly easy switch, but it will raise your position considerably in the job market.

But really, you should take Patrick's advice and not present yourself as an X developer. I do because I want to work primarily with Ruby and Rails, but when I was starting out, I presented myself as a competent engineer that could get up to speed effectively with any framework. I got a .NET job that way, having no former experience in the stack. Got fired in three weeks, but I still got paid. Now I do Ruby exclusively, and have no trouble finding opps.

itjobswatch.co.uk: number of jobs in the past 3 months citing ruby: 2,766, python: 6,013. Rank table: http://www.itjobswatch.co.uk/IT-Job-Market/UK/Programming-La...

GB section on this page put Ruby mentions at 3% and Python 6% https://gooroo.io/GoorooTHINK/Article/16300/Programming-lang...

EDIT: indeed.com, ruby vs python: http://www.indeed.com/jobtrends/ruby%2C+python.html

Does anyone know where else to get data (not anecdotes)?

Languages don't just disappear. People still make fine livings programming Fortran. If I'm going to keep programming for 20+ years, I'd be happy to be one of those guys. I'd rather move into business, but if for some reason that never happens, being a specialist in a deep niche holds a deep appeal for me.

The tech industry is largely a group of companies competing to outbid each other to hire a small pool of "credentialed elite" developers for lots of money, and everyone else.

I've been reflecting on my experience with resumes and interviews for various positions, mostly technical, over the last 30 years. For me, getting jobs has almost always been about rapport with the person across the table or other end of the phone. Natural problem solving/engineering skills and abilities with a toolkit are important. Engagement with the interviewer via interesting, relevant stories feels like one of the keys.

A friend who used to hire engineers years ago at Sun told me he would hire based on two factors, assuming basic background/skills on the resume. One, light behind the eyes and two, could he enjoy drinking beer with the person after work? I have another friend who used to successfully hire engineers in a similar way. Not sure why we don't see more of this out there. Though the informal route probably embodies this approach by it's nature.

In my experience, about 80% of the candidates who send in their resume will not come close to working out. If you've never run a hiring process before, you'd be surprised how many people look decent on paper but somehow can't write a line of code without some serious hand-holding. The OP points out that sometimes the opposite is true (a candidate with a mediocre resume ends up being stellar), but this is an exception and you'll waste a lot of time trying to find these people.

I've honed my resume screening skills over time and I've gotten pretty good at filtering out most of that 80%, and I know I'm likely to screen out plenty of talented folks, but it's well worth being able to focus my time and my team's time interviewing more exceptional engineers than mediocre ones.

In other words, I think it's OK to throw out a lot of the baby with the bathwater as long as you're left with mostly baby.

Quite true, and basically what companies like Google do.

The issue comes in that we have been inundated for years with people bitching about "talent shortages"; i.e., there ain't enough baby left over.

I think a lot of this may have to do with nerves. Writing code on a whiteboard when given an arbitrary question is very different than writing code in a comfortable context and environment. I think it's safe to say that a decent percentage of people in our field let nerves affect their ability to write quality code at the same level they normally do.

> What that looks like in practice is you somehow find that an engineering company is hiring, which by the way, every company that has more than 10 engineers is going to hire engineers this quarter.

Not mine. We haven't hired an engineer, or anybody else, in over a year. We aren't struggling, either. We just don't have the work volume.

Maybe we are the exception, but anyone following this advice and trying to contact, say, me is just setting themselves up for disappointment.

Point being, as he mentions elsewhere, you should do it in parallel. For every company that isn't, there's probably another that is open to hiring.

I know a lot of good engineers that just become contractors because that's the only way to transcend the market salaries for programmer employees. There are a half dozen jobs I'd love to apply for but the salaries just don't match what I make as a contractor (even taking many benefits into account).

That relocation was the best decision of my life. And it started with contacting a company that originally indicated they were not hiring.

If you're interested, you make contact. Just don't expect that it has to lead somewhere. It never hurts to try.

I could actually go on about this at length. Over the past year, I've witnessed some close, personal friends going through it. From what we've observed from their experiences, as far as we can tell, it's legacy cruft, hazing rituals, and dysfunction combined.

The only time that's been true for any company I've worked for is in the few months immediately following massive layoffs...

Maybe for a few startups who are "growing" this is a good strategy (idk) but not the majority of businesses. It isn't good business to randomly hire engineers you don't have work for only to lay them off in a year because... you don't have work for them!!! Your rockstar engineer isn't going to have a good time twiddling their thumbs all day anyways.

My company has way more than 10 engineers but we rarely hire. Our work level has been very constant over the last decade and people rarely leave so they don't need replacing often. The majority of our engineers have been working at the company for over a decade.

That's not even how the majority of businesses work and many hiring managers aren't even allowed to hire without a specific job opening. My boss (also the hiring manager) at the company I interned for wanted to hire me full time instead of replacing me with a new intern after my internship ended (which was protocol for that project I was working on). He couldn't without the higher ups, who worked in another office, approving a new full time job opening which they didn't want to do at that moment. He was only allowed to replace me with another intern because that's what the higher ups called for, it was an intern position. There was no other full time positions open.

Yeah, it's true that you should try to network in case there is a job opening somewhere that hasn't been advertised yet. But it's not going to work to assume every company is hiring all the time. That's just setting yourself up for disappointment. Realistically most companies aren't just going to hire someone on a whim.

This whole article sounds like an unrealistic pipe dream. I guess this is how "startups" operate, I don't know, I don't live anywhere near California.

(Oh yeah, non-salary benefits like vacation or health insurance are just not negotiated, they are determined by an algorithm in the company handbook)

If a job with Z features is negotiated for $X you can't just throw in a couple more engineers, give them a couple features they didn't ask for, and charge $Y. You can only charge work on a project if that work is specified in the contract. Otherwise that's fraud.

And anyway, you're apparently going to hire all the engineers who ask you out to lunch (according to this article) so you're going to have a whole lot of engineers very soon if you are hiring this way.

This is a bit of a contradiction. If you aren't growing, you are dying.

At my previous large company, where I spent nearly ten years, I can count on one hand the number of engineers who left for reasons other than firing or retirement.

This "engineer churn" is very much a product of certain overheated markets. For most of the world it just is not the case. In fact, that is my main issue with articles like this. Not every market is overheated like the Valley, and you cannot cast what goes on there like it is the way the world works.

The question then becomes, what do you ask if someone's algorithmic knowledge is no longer in doubt?

That's one of the perennial problems with programming certifications -- they either certify technology that falls out of favor/use after a short time, or it certifies evergreen techniques that colleges/universities are supposed to cover. So you end up competing with MS/Cisco/Sun or Harvard/Berkley/etc.

Also, sites ranging from HackerRank to StackExchange offer a similar service. It's not a "certification" per se, but they certainly market their platform as a way to identify effective developers.

More interesting though is the vacuum it creates in the tech interview process.

Most people will not feel comfortable sharing their salaries or salary scale (company information) with someone they don't know or just met. Thankfully there are sites such as Payscale and Glassdoor where people share salaries anonymously so you can lookup the salary scale/ range for a company.

Even if you can't find it for company A that you are intending to work for you can always do a comparative market analysis; look up salary info for company B or C who are in Tech and in the same area/ domain and you can use this information to at least get a baseline or as leverage in the negotiation.

In fact this is something I blogged about a few days ago https://dreamjobexec.com/7-tools-help-get-tech-dream-job-hin...

It's asked early for a reason—to determine if you're compatible before proceeding with interviews. The majority of software developer jobs out there pay (substantially) less than I would accept and it's a waste of my time to spend time interviewing for them.

The ideal is that the company gives a compensation range, but many will refuse to. So I just tell them the top of my range. That ends the majority of conversations but it lets me narrow in on companies which properly value talent.

Having been on both sides of the market, I would add - try and imagine yourself in the company's shoes.. and DIVORCE your emotions from the process.

Understand the company's side of it:

They're buying your services, like they were picking out fruit at a market - a market where you haggle with the seller. Paid a dollar more? Didn't buy got no fruit? - not a big deal to the co.

The company really doesn’t care whether they pay you 100 or 130. This was a great point in the article.

This process is a lot bigger deal to you than to them. If they hire/don't hire you, is not going to affect the company that much. While, it affects your whole life.

And I think the most important thing, don't get upset if things don't work out. It's a cliche, but SO true - some things are meant to be for a reason. There are more opportunities out there.

That very much depends on one's perspective of it. What if I think its the same as many of the missed opportunities that I cannot put a price on? (i.e. they might also be totally insignificant)

Conversation usually goes like this.

E:"What's your salary expectation?" (or last job's salary)

Me:"We can talk about the salary later. We can first see if we're a right fit"

E:"Cool. But we want to know your expectation." (get's the same question) Me:"I don't want to disclose my number but can you give me your salary range and I can say whether it is within my range"

E:"Its between AA - CC" (what I'm expecting is BB)

Me:"Yup, its in my range"

There. I dodge the bullet, I get the offer, but the salary is AA+.

This happen to me a lot in my last search and I feel like I would have a better salary and save time if I just said BB up front.

AA+ offers will go away immediately. Your goal is to get several BB offers and with a little negotiation bring it to BB+ offer.

Also a lot of time employer loves to pull a card of "let's start from here". They will give you an example employee that got promoted twice in just a year.

The point is to save more time.

What I usually do, when I assess software engineers, is checking if they are using good variable names and short functions.

Btw.: I am a technical recruiter from Zürich with a software engineering background. If you look for a coding job in Zürich with net-salaries that are on par with the Bay area (in the range of 7-10k CHF / month after tax), you find my email address in my HN-handle.

a) I would really like to be able to do that instead of the awful application-oriented hiring process.

b) I will never be able to do that unless I'm able to relocate to a suitable location, probably after having completed an application-oriented hiring process.

How do the get-hired-with-connections gurus recommend resolving this chicken or egg situation? I get that Starfighters is aiming in part to solve similar problems, but surely there are existing solutions.

"Sending in resumes is not how people get hired for most jobs" - simply untrue. Where I work, most successful hires simply sent their resume via the form on the website. Or recruiters pinged them via linkedin or some such site. No behind-the-scenes hobnobbing was necessary. Boring, I know.

"every company that has more than 10 engineers is going to hire engineers this quarter" - simply untrue. Hiring freezes are a real thing. Of course if the candidate is really experienced or a perfect skills fit for that particular company then something usually can be done but if you are a junior or a merely "ok" developer then tough luck for you.

"you ask them are they team leader or higher in their company. If they say yes, they either are a hiring manager or they know who is the hiring manager." - team leaders trade in this funny currency called "vacancies". And if a team leader is short on those he or she has very little incentive to bring you into the company. Of course if you meet a team leader at the developer conference then they are usually hiring (and often explicitly say so during their talks!)

The one who first names the price forms the baseline of negotiation. Say their range is 100-140k. If you say, "tell me what you would pay" and they say 100K, you're screwed, no way you can say "150k" from there and still be taken seriously. If OTOH you say 150k at the start and are lucky enough to get the answer "no way we can give you more than 140k", from there it's a simple job of asking for an extra concession that you know they can make ("Hmm... ok, say I could accept 140k, but only if the company allows me to WFH when I need to")

( *) Of course, not from the start. He's right about that. They need to be invested in the hiring - if they already spent a lot of effort trying to assess your skill before making an offer, you're in a much better position to ask a lot. Presuming that they like you, of course.

An example: https://twitter.com/mxcl/status/608682016205344768

Coding interviews deserve their bad reputation, but dammit, there is no better way to learn whether or not a candidate for a programming job understands the really basic concepts than to have them write a little bit of code that can't be written if you lack the aptitude.

It's always been a personal connection.

At the risk of bragging, I'm very good at this stuff.

If you're filtering resumes and doing endless interviews, you're missing out. You won't get people like me.

It's always been a submit-a-resume-and-interview (via an agency).

At the risk of bragging, I'm very good at this stuff.

What's your point?

Edit: This is completely true.

That would be my point.

I would 100% agree that the professional connections have helped me get more jobs and more offers than a computerized/headhunter/recruiter service.

YMMV, but don't discount the importance of making good connections while working.

This is the sort of comment that might be more advantageous for you if you had contact information in your profile, just FYI.

Tho seriously, here's the question I'd ask of you...

Is that working out for you? It sounds like it's not, since you're still looking.

Maybe it's time to step back and reevaluate your process.

We have a high proportion of surprisingly high quality software engineers, from a number of European nations (a very international mix, now that I think about it). Good people move on, be it moving on within a company or without, and where I work the product is relatively narrow, so people tend to move on by leaving. I expect to be moving on myself within the next two years. When you have more than a dozen or so high quality software engineers, someone is always leaving. I advise the youngsters that if they ever find themselves in the same job and the same role for five years, they need to start thinking about their exit and get on with it.

In my opinion, our process is working well, thank you. There is no whiteboard involved.

I have also tried the "know somebody" tack. None of the people I have ever met has ever been able to even get me an actual interview anywhere, with the sole exceptions of my father, who has thrown roughly $1500 worth of business my way over my entire lifetime, and a former boss, who was laid off at the same time as everyone else, yet still managed to toss me $500 in contract work for his one-man startup as the emergency job search stretched out into the second week.

On a gross revenue basis, looking good enough on paper to start a conversation, and spamming out those resumes to anyone even considering hiring someone new has been roughly 400 times more valuable than knowing other people.

But my entire career has also unfolded far from the SF-Oakland-SJ metro area. We don't exactly get a lot of "meetups" around here. I'm not even exactly sure what a "meetup" is. Maybe like a geek night where everybody talks shop all night instead of having fun?

Also, not a single professional recruiter has ever successfully placed me in any job, nor have they even been very good at getting me interviews. They have been worse than useless, in that every second I wasted on them would have been better spent digging up my own leads and sending my resume myself.

All that said, I hate, I hate, I hate the current software professionals' hiring process and the trends in it that I have been able to observe from my end.

Then I just sit back, look over the job reqs that they send me and then I decide whether I want to be submitted.

Within two to three weeks, usually I have competing offers. I've never failed a phone screen with an employer and I've only twice haven't gotten an offer.

Luckily my first job I got was based on an internship. I graduated from a Podunk state college and I've been able to demand a competitive salary after my first three year job stint.

Recruitment for tech companies is near constant at a certain level of talent. While there are smaller or profitable but stable niche companies that aren't looking to add engineers, most companies would always hire an engineer with a skill level that exceeds a certain threshold. In other words, if you're really good at coding, have a really strong understanding of software design, and you aren't a hard person to get along with, they'll have something for you.

This leads to the technical "interview", which is really better described as a technical exam. The most infamous incarnation of it goes like this: you arrive in a room, a very strong software developer arrives you are asked a variant on a data structures/algorithms question that you must solve at the whiteboard. It will be difficult to get it exactly right in the time allotted, but you will now demonstrate that you are able to write tight, good, efficient code that largely solves the problem. You will also demonstrate that you can clearly explain difficult technical concepts in clear human language (usually English), without getting angry or excessively flustered. If you're really, really good at this, they have something for you. Exactly what that is we can all work out later.

This leads to a constant state of "filtering". These companies are continuously scooping up silt, sifting through, to see if there are any good bits of gold in there. If they accidentally throw out a bit of gold, that's fine, they just keep sifting and sifting.

The odd thing about this (having been on a few of these interviews myself) is that it turns the "interview" process into a technical exam. I've been shuttled from room to room for six hour of whiteboard exams, all about tree traversal, complex sql, some math, and at the end of the day, I honestly have no idea what this company does or what they'd want me for (aside from what I'd read about in preparation for the "interview", none of which was discussed at all). But I do get it from the point of view of the company - if I can do certain branches of math, write tight code, and do sql really really well, and I clearly have the verbal and presentation skills to explain it all, then yeah, they will be able to make good use of me at their company (for the record: no offer ;) )

The filtering is irritating for candidates, of course, since it means that in our field we sit for exams constantly. The saving grace is that these companies must devote the valuable time of their strong engineers to conduct the interviews, which means they don't do it unless there's a good chance you're a good candidate.

The more insidious side of this is the rise of automated testing and/or "projects". You spend 30 minutes talking with a recruiter, and then you get a link to an on-line exam or project that can take from 2-8 hours. This allows the company to cast a wide net without wasting time. Well, wasting their time. The process allows them to push the inefficiencies of the process out onto the candidates. The amount of time spent by developers on these exams, only to be dismissed in 5 minutes, is staggering. This is one reason I won't take these exams (if they occur very early in the process - if it happened much later, when it was clear both sides were serious, I would reconsider), even though I will spend an equivalent amount of time on in-person exam/interviews.

Let's get real here:

Yes, in the OP, the good news is likely:

> People who do consulting or freelancing for a living might realize this is isomorphic to getting consulting engagements. It really is. It’s fundamentally running a sales process for yourself, which is a really weird skill

On salary negotiation, I'd suggest bringing in some super important data:

Within easy commuting distance of the job, go house hunting. Want 3-4 bedroom, 2 1/2 bath, with family room and two car garage. Maybe also full, dry basement, nice yard, nice landscaping, pool, nice neighborhood, good schools.

So, get the figure per month for the house -- principle, interest, taxes, insurance, maintenance.

Add in your medical insurance, life insurance, IRA, and college fund for the kids.

Add in cost of cars for yourself and wife and, later, kids.

Add in usual costs of living -- food, clothing, education for the kids, home furnishings, smart phones, Internet access, desktop computers, professional memberships, professional publications, etc.

Add in some for recreation.

Add in some for contingencies, say, for the kids, private schools, tutoring, violin, swimming lessons, etc.

Then look at taxes -- city, state, and Federal.

Then add it all up.

Then add, say, 30%.

That's your figure. Justify it with

> I have a family, and I am the breadwinner. I have a wife and two kids, and we want two more kids. My wife is busy with the kids, and with the home, she is fully busy. We need the usual, food, clothing, shelter, transportation, medical care, recreation, education for the kids, retirement for my wife and I, insurance against risk, plus smaller items. In addition, my wife's mother needs to come stay with us. In this area, that's what it comes to. To have less than that would make us financially irresponsible.

Of course, if the employer wants to hire a single person who wants to live in an efficiency apartment and use busses and taxis for transportation, then, okay, but need to know that.

> It is well worth your time to take another developer out for a hamburger and say, “Hey, tell me a little bit about the company."

Maybe. But this other person might tend to see you as a competitor and want to hurt your career instead of a colleague who wants to help your career.

> The nature of careers for us is just working for 40 years for IBM and then receiving a gold watch is something that very few of us are going to be able to successfully do, and that frankly, I’m not even sure I want. Actually, I much more than not sure I want. I’m sure I do not want, do not want.

Right, don't want it. But, it's been a very long time since IBM offered such a career. The more common situation was, in an IBM area, a house cost 5+ times what the IBM annual salary was so that, really, the employee had to pay for their house out of other funds and was basically subsidizing IBM.

So, who was living in those houses? In some cases, IBM employees who joined when the house prices were much lower. But in most cases, people just not working at IBM or in any such job. Instead, likely they were doing well in small business, e.g., as owners.

More generally, there is a biggie fundamental problem with the whole career and salary negotiation process in the article: The company will just NOT for long be able to pay more than the work of the job is worth. So, really, the employee needs to know what the heck the work is worth and try to get as much of that as possible, and for that, and quite fundamentally, the employee needs in some significant sense, in one word, 'ownership' of the business. So, we've got to be talking stock or the person just owning their own business.

Biggie point: If own the business and run it, then are facing the 'market' for the product/service the business provides. If that market is poor, gotta pick another business. If that market is good, then the worker gets to keep what the work is really worth. That point is a huge biggie. As an employee, will have a tough time getting for very long even half what the work is really worth in the market. This is a crude analysis, but it can be the difference between (A) being single and (B) providing for a good family and a good life.

From the OP, here is another really fundamental point:

> “Look, I understand just if I start to read through the resume, it doesn’t look like the most promising candidate, but when given a very complicated engineering task, which involved both security research, and then a complicated open-ended data analysis task, they not only successfully solved the task, but produced a deliverable which could literally be published in a research journal,

Okay, if that is impressive, and it should be, then there's another approach: Look on the resume for candidates who actually have PUBLISHED such work in a peer-reviewed journal of original research. Or, at least they have a Ph.D. degree from a good research university where their dissertation was just such work and is likely publishable.

Let's have an example: Recently at the company, there have been some unexpected problems -- outages, performance degradations, security breaches, etc. -- in the network and some in the server farm.

So, the company wanted, in general terms, better near real-time monitoring for such unexpected problems. That is, the company wanted continual reports on health and wellness of their network and server farm.

They have been using various approaches, but especially thresholds, and in total the approaches have two biggie problems -- false alarm rate too high and detection rate too low.

Joe looked at that situation and saw that from Microsoft, Windows Server, SQL Server, IIS, Oracle, Cisco, HP, etc., there is a river of data available for monitoring. So, he could get data on any of some literally hundreds of relevant variables at data rates of a value each few seconds up to thousands of values a second.

So, Joe thought about how to use that data to get better monitoring. Well rested in a quiet room he put his feet up, popped open a cold can of diet soda, reviewed the problem and old approaches, reviewed some of this educational background, and had some ideas.

Eventually, he noticed: If look at, say, two variables jointly, should be able to do better on false alarm rate and detection rate than looking at the variables separately, unless the variables are independent, which in common cases the definitely are not. So, in some sense, want to exploit several variables not individually but jointly.

Next, Joe noticed that with false alarm rate and detection rate, he was reminded of his course in Statistics 101 and, there, hypothesis testing with Type I error, Type II error, and the 'power' of a test, that is, some tests are more 'powerful' than others. Also he checked in an intermediate text on statistics and noticed that the classic Neyman-Pearson result says how to get the most powerful test possible.

Then Joe had some ideas, got some real data, wrote some prototype code, and the results looked good. Joe was able to adjust false alarm rate, and know the rate in advance, for any detection say what was the lowest false alarm rate at which the data would still be a detection, and had really good reason to believe in an especially high detection rate.

He published his work in a high end peer-reviewed journal of original research and gave a seminar on that work at a world famous, high end server farm where reliability is taken very seriously.

He put this work on his resume, sent 1000 copies, and never heard back.

So, back to the last quote above from the OP, here comes the biggie surprise: Doing such work won't get you hired. Hardly a chance. Now, we should all be screaming, why, why, why, why, why?

Okay, maybe that monitoring work would not be very important.

But, maybe the company is facing some challenges in routing, scheduling, planning that, as is commonly the case, boils down to linear integer optimization, right, known to be in NP-complete. So, an impressive example might be a 0-1 integer linear program with, say, 40,000 constraints and 600,000 variables. Then, asking for a solution that is optimal, down to the last tiny fraction, might be a bit much, but coming within 1% of optimality might be nice. So, suppose Joe came withing 0.025% of optimality? Might want to chat with Joe about any problems in looking for good combinations.

So, Joe also put that work on the 1000 resume copies he sent.

Ah, usually the real data is arriving in ways that are not fully predictable. So, there is a stochastic process and want to know some of what the results will be. Once Joe was in touch with some people in touch with the US Navy, and they wanted an evaluation of how long the US fleet of SSBN missile firing submarines would be under as special scenario of global nuclear war but limited to sea. From an old B. Koopman report and some common sense assumptions, Joe saw a continuous time, discrete state space Markov process subordinated to a Poisson process, wrote and ran Monte Carlo software to do the evaluations, and had the work please the US Navy and be sold to a leading US intelligence agency (could say which one but then would have to ...).

Joe put that on his resume, too.

Then Joe got a call back, and they wanted to know what he knew about C, Python, and R.

Joe said that he'd one some C programming, but the language was so primitive that it was usually next to useless for his work in analysis. For R, that was just simple, standard statistics, and the work he'd done is statistics was beyond what R offered and he wrote his own code. For Python, that was similar -- instead he'd written his own code.

The interview died.

Okay, there's a fundamental lesson here:

Fundamentally, in US business, the attitude remains much as back in a Henry Ford plant 100 years ago: The company and the company managers know more than any candidate employee, about the work, how to do the analysis, how to write the software, and an employee is there just to add routine labor to what the company already knows. So, a resume that mentions work beyond what the company knows conflicts with this fundamental attitude and results in rejection.

In US mainline business (there are exceptions elsewhere), they are just very strongly against hiring as an employee someone able to do something the company can't already do.

So, dumb down the resume.

Then inside the company, fit in, don't expose real potential.

Then look for a good, new problem, say, needing analysis such as in the OP.

Then, largely independently, after hours, make some progress through prototype code and some impressive real output from real data.

Then develop some high level foils, go to the relevant manager, and give a short talk.

Then expect 'incoming' attacks, vicious, whisper campaigns, sabotage, etc., from jealous people. Then discover if the company really wants good analysis or not. If so, likely will have to transfer to a much better position, say, on staff of the CEO. Else, will likely soon get FIRED. No joke.

If say anything about such analysis before actually have the results, then people will either laugh or attack. The situation is quite general, say,

"First they ignore you, then they laugh at you, then they fight you, then you win."

Mahatma Gandhi

So, what the heck to do?

Sure, face the market directly. Do a startup. Pick your own problem, do you own analysis, write your own code.

Back to it. Work for today: Use a .NET collection class for a fast, easy to program way to find duplicates. So, a Web server, a Web session state store (wrote my own with just TCP/IP sockets, class instance de/serialization, and two instances of a collection class instead of using, say, SQL Server or Redis), SQL Server, and two specialized back-end servers, 18,000 programming language statements in Visual Basic .NET in 80,000 lines of typing.

Going live is getting to be very visible!

Let's see: The work is intended to provide the world's first good, a must have, solution for a problem pressing for nearly everyone connected to the Internet. To start, if I can get on average one user a second, 24 x 7, then, ballpark, I should get monthly revenue of

2 * 8 * 5 * 3600 * 24 * 30 / 1000 = 207,360

dollars. Now, in the OP, what annual salary ranges where they talking about?

The core analysis work? Silicon Valley has more hen's teeth than entrepreneurs who would understand that work even if I explained it to them, and many more such entrepreneurs than such VCs!

If you have something and explain it, then, if it is really bad, no one will like it. But, curiously, if it is really good, the same, no one will like it. Remember what Gandhi said. Or, easier and much the same lesson, just go back to kindergarten and to Mother Goose and "The Little Red Hen" -- same stuff. The hen wouldn't get hired, either.

Okay, maybe that monitoring work would not be very important.

But, maybe the company is facing some challenges in routing, scheduling, planning that, as is commonly the case, boils down to linear integer optimization, right, known to be in NP-complete. So, an impressive example might be a 0-1 integer linear program with, say, 40,000 constraints and 600,000 variables. Then, asking for a solution that is optimal, down to the last tiny fraction, might be a bit much, but coming within 1% of optimality might be nice. So, suppose Joe came withing 0.025% of optimality? Might want to chat with Joe about any problems in looking for good combinations.

So, Joe also put that work on the 1000 resume copies he sent.

Ah, usually the real data is arriving in ways that are not fully predictable. So, there is a stochastic process and want to know some of what the results will be. Once Joe was in touch with some people in touch with the US Navy, and they wanted an evaluation of how long the US fleet of SSBN missile firing submarines would be under as special scenario of global nuclear war but limited to sea. From an old B. Koopman report and some common sense assumptions, Joe saw a continuous time, discrete state space Markov process subordinated to a Poisson process, wrote and ran Monte Carlo software to do the evaluations, and had the work please the US Navy and be sold to a leading US intelligence agency (could say which one but then would have to ...).

Joe put that on his resume, too.

Then Joe got a call back, and they wanted to know what he knew about C, Python, and R.

Joe said that he'd one some C programming, but the language was so primitive that it was usually next to useless for his work in analysis. For R, that was just simple, standard statistics, and the work he'd done is statistics was beyond what R offered and he wrote his own code. For Python, that was similar -- instead he'd written his own code.

The interview died.

Okay, there's a fundamental lesson here:

Fundamentally, in US business, the attitude remains much as back in a Henry Ford plant 100 years ago: The company and the company managers know more than any candidate employee, about the work, how to do the analysis, how to write the software, and an employee is there just to add routine labor to what the company already knows. So, a resume that mentions work beyond what the company knows conflicts with this fundamental attitude and results in rejection.

In US mainline business (there are exceptions elsewhere), they are just very strongly against hiring as an employee someone able to do something the company can't already do.

So, dumb down the resume.

Then inside the company, fit in, don't expose real potential.

Then look for a good, new problem, say, needing analysis such as in the OP.

Then, largely independently, after hours, make some progress through prototype code and some impressive real output from real data.

Then develop some high level foils, go to the relevant manager, and give a short talk.

Then expect 'incoming' attacks, vicious, whisper campaigns, sabotage, etc., from jealous people. Then discover if the company really wants good analysis or not. If so, likely will have to transfer to a much better position, say, on staff of the CEO. Else, will likely soon get FIRED. No joke.

If say anything about such analysis before actually have the results, then people will either laugh or attack. The situation is quite general, say,

"First they ignore you, then they laugh at you, then they fight you, then you win."

Mahatma Gandhi

So, what the heck to do?

Sure, face the market directly. Do a startup. Pick your own problem, do you own analysis, write your own code.

Back to it. Work for today: Use a .NET collection class for a fast, easy to program way to find duplicates. So, a Web server, a Web session state store (wrote my own with just TCP/IP sockets, class instance de/serialization, and two instances of a collection class instead of using, say, SQL Server or Redis), SQL Server, and two specialized back-end servers, 18,000 programming language statements in Visual Basic .NET in 80,000 lines of typing.

Going live is getting to be very visible!

Let's see: The work is intended to provide the world's first good, a must have, solution for a problem pressing for nearly everyone connected to the Internet. To start, if I can get on average one user a second, 24 x 7, then, ballpark, I should get monthly revenue of

2 * 8 * 5 * 3600 * 24 * 30 / 1000 = 207,360

dollars. Now, in the OP, what annual salary ranges where they talking about?

The core analysis work? Silicon Valley has more hen's teeth than entrepreneurs who would understand that work even if I explained it to them, and many more such entrepreneurs than such VCs!

If you have something and explain it, then, if it is really bad, no one will like it. But, curiously, if it is really good, the same, no one will like it. Remember what Gandhi said. Or, easier and much the same lesson, just go back to kindergarten and to Mother Goose and "The Little Red Hen" -- same stuff. The hen wouldn't get hired, either.

In my experience, the only lesson I've learned is that you cannot know much at all about a candidate's eventual job performance or cultural fit from any hiring technique.

Giving them tests or quizzes doesn't work. Giving them take-home coding tests doesn't work. Asking them behavioral and technically probing questions about their background doesn't work. Having them come on-site and suffer through whiteboard hazing doesn't work. Making them sit in on a technical Skype call with three simultaneous interviewers doesn't work. Everybody's pet theory about how to vet them before their first day doesn't work. And most of those things also waste a lot of everyone's time and have the poor false-positive / false-negative rates that the OP describes.

The only thing that I think works is just hiring someone and then seeing if it works and not being afraid to fire them if it doesn't work. Everyone freaks out about this idea because there's so much taboo about the cost of hiring, setting up benefits, and so forth, and the morale drain from firing.

But it's a trade-off. Do you want to pay those costs while getting actual info about an employee? Or pay those costs in a status-showy way ("look how hard our hiring process is!") but not actually get any info for what you are paying?

To address the firing part of it, which of course is not at all fun, there is an easy solution: make generous severance packages a standard part of your job offers.

If you mistakenly hire someone who is not cut out for your team (for whatever reason, skill, attitude, work ethic, culture, etc.) that is on you no matter what your hiring process is. Don't make candidates bear the costs of your hiring mistakes. Treat them well and they will be more understanding if the hiring process involves a lot more firing than most are accustomed to. If you give them 6-8 months of salary as a severance benefit (and that's on the low end), then they will be secure about the risks of getting fired and it will buy them time to find a new job if you need to let them go. For a huge number of companies, this is easily affordable and building in a fixed cost of 1/2 year of their entry salary is borderline trivial (even if people want to make a big argument about it).

Everyone likes to whine that this is expensive, but hiring the right person is expensive -- it just depends on how you want to pay the cost. Like I said before, you can engage in a bunch of fake performative nonsense like tests and whiteboard hazing, in which case you are paying the price in terms of wasting your existing employees' time and in terms of false positives and false negatives and constantly leaving money-from-would-have-been-productivity on the table, or you can just own up to what it costs and be more willing to pay the dollar amounts necessary to trial people out. Then you can have much lower barriers to entry that mostly just involve basic conversations and extremely simple sanity checks about a person's background. If they pass those and the team more or less likes them, just pay the money to see if they work out and move on. Stop obsessing over it, especially by letting HR middlemen get in the way and obfuscate things.