
What Developers Should Know About Job Searching and Negotiation - shakes
https://www.twilio.com/blog/2016/02/patrick-mckenzie-on-salary-negotiation-job-hunting.html
======
pumblechook
This is all good advice, but this article falls into the same trap that most
other career related advice does: it assumes only one type of job seeker (in
this case - ambitious, experienced, and passively job seeking).

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.

~~~
dreamjobexec
I agree with you. I think the best overall approach is to apply the scientific
method. Set hypotheses on what will work what will not, test, look for
evidence and adjust accordingly. or the startup metaphor of reaching product
market fit or pivot

------
cgopalan
Patio11 is very respected in the community, but I can't help but feel that
most points in here are not applicable to all software engineers. This seems
to be mostly for people starting off in their careers, or people that feel
that work is a major part of their life. I am sure there must be more people
out there like me who:

\- 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.

~~~
potatolicious
I disagree heavily - I think his advice is actually equally, if not more,
relevant for people like yourself.

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).

~~~
tetraodonpuffer
: you can turn part of that salary into more vacation time

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

~~~
vinceguidry
> 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)

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?)

~~~
Retric
Another approach is to suggest you split a job with another person. I have
seen several young mothers take this path as they don't need full time
daycare, and don't end up with a long employment gap.

------
robodale
I've completely turned away from getting another job. Recent scenario: After
giving in detail my 14 years development/engineering experience, they ask:
"Ok, here is a logic riddle: You have 3 circles A, B, and C. A depends on B,
C...." and by that time I've already lost interest. What the fuck does a
riddle have to do with anything.

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.

~~~
rpgmaker
Did companies do this before the media glamorized Google's job application
process? I had to do some of those stupid riddles when I was starting out but
hopefully I won't have to ever again (I'm working on a side business too).

~~~
varjag
The lore is it was a part of Microsoft hiring process in early 90s and then
spread out. Google "microsoft manholes".

~~~
turnip1979
MSFT did it .. sure .. but my first half-decade of software engineering jobs
seem like coffee chats compared to the crap we have today. I think I got my
first job after a 45 minute chat (was supposed to be 30 mins but we were
having a fun, geeky convo and lost track of time). What's crazy is I would
leave with offers in hand. This is until 2004. Google copied and one-uped
microsoft. The Googlers went out and replicated their process and suddenly,
most decent software engineering jobs require you to bend over.

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.

~~~
varjag
Well at the peak dotcom era you often could get away with spelling HTML
without stuttering and you were hired. Microsoft could afford to discern
however, being the top employer at the time.

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.

------
fecak
As a recruiter, even I often refer people to Patrick's article on salary
negotiation, and I agree with much of it. There are a couple points that
weren't covered that I think are valuable.

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.

~~~
vinceguidry
I can't help but to pile on about the difficulty of negotiation. The reality
is is that 90% of it is done before you've ever started talking. You can maybe
influence 10% of the outcome, and it might be worthwhile to do that, but it's
also worthwhile to work on that 90% beforehand, and studying negotiation
techniques doesn't really help with the 90%, only the 10%.

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.

~~~
billmalarky
"Time spent looking at comps, finding a good inspector, understanding the real
estate biz"

This is literally the biggest part of negotiation.

[https://en.wikipedia.org/wiki/Best_alternative_to_a_negotiat...](https://en.wikipedia.org/wiki/Best_alternative_to_a_negotiated_agreement)

~~~
vinceguidry
Yes, that's what I intended to say. My point was that of all the things you
have in your life right now to focus on, negotiating price for a real estate
transaction may not be the best use of it. It's likely to take more time than
it's worth when you take into account opportunity costs.

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

------
kzhahou
> Fake the confidence here. If they say, “What are your salary requirements?”
> You say, “Well, it’s really too early to talk about salary. I just really
> want to make sure that we’re a great fit for each other. If we’re a great
> fit for each other, we can work something out. If we’re not a great fit for
> each other, it doesn’t matter. We shouldn’t work together no matter what the
> numbers are.” Whatever you need to say, just do not answer the salary
> question until you’re actually negotiating.

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.

~~~
dotBen
It really depends on what kind of company you are negotiating with. Companies
of a certain size will have salary bands and they can't pay above a certain
amount otherwise they risk salary imbalances within teams.

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)_

~~~
ryandrake
I've run into this argument in the past. It also happens when you're already
on the job.

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???

~~~
scruple
> 'The book' says

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.

~~~
bigtex
The book is definitely not based on the local job market. I get emails from
recruiters and have a sense of what the proper salary range is for my
position. The book is usually on the bottom of that range.

------
iandanforth
The advice on job hunting is the same kind of vague, shotgun style hunt with
the word "meetup" thrown in. This is a terrible way to find a job you love.
You might get lucky, but there is a better way. Pick where you want to work
and then be good enough to work there.

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.

~~~
st3v3r
"I always volunteer to work for free prior to getting hired."

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

~~~
p4wnc6
But offering to do a short working internship, which is paid at a competitive
rate that would translate to the salary you are seeking, is reasonable. That
way you are compensated for the effort you provide to assist the hiring
company in figuring out if they want to work with you, and if so, at what
price they are willing to agree to it.

~~~
st3v3r
It can be, but that gets pretty close to contract-to-hire, which is rife for
abuse from the company.

~~~
p4wnc6
When I say short, I mean 1 week, maybe 2 weeks tops. Few places that want the
scammy sort of contract-to-hire are going to bother with someone who expects
to be paid their regular wage for a one-to-two-week time period.

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.

------
tetraodonpuffer
it's also interesting that (anectodally, talking to people I know) the longer
one's career is the more unlikely they are to want to switch jobs just based
on having to deal with interviews, which of course makes it more likely they
don't go for that cool interesting job they might flourish even more in, and
makes it also harder for companies to hire as there are less available people
around than there would be otherwise.

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

~~~
harryh
I agree with your observation but I've always found that attitude a little
odd.

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?

~~~
tetraodonpuffer
you don't understand, I don't consider it beneath me at all, I mean, you have
to interview somebody to know if they are a good fit, but I don't see why
interviews have to be hazing rituals on things mostly unrelated with what they
are supposed to measure.

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?

~~~
harryh
I guess maybe I've just been lucky (or perhaps have chosen which companies to
talk to well) in that I've always had discussions closer to your "what are the
pros/cons if you design an API to expose txns" example than "implement a
red/black tree off the top of your head." Perhaps this is coloring my
judgement.

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."

------
Mc_Big_G
_" Oh yeah, you’ve been writing web applications everyday for the last five
years. Great. Can you please go up to a blackboard and using chalk write out
how to reverse a binary tree?"_

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

~~~
JustSomeNobody
I don't get it. If the job you're applying for relies heavily on data
structures and algorithms, why can't they ask this?

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

~~~
lhnz
Just the other day during a JavaScript/React interview I was asked how a
HashMap was implemented.

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.

~~~
pech0rin
While implementation details may be unnecessary, I feel like knowing how
something performs for lookups, insertions, deletions, etc. is important. It
definitely shouldn't be the end all be all of hiring, but it is definitely
helpful day-to-day to know how the code works performance wise with the data
structures you are using.

~~~
ilostmykeys
that CS stuff you can look up and understand when you need it, like when
you're looking for an efficient algorithm to do xyz, and so you should have
curiosity and a wise intuition but beyond that as a web developer that
knowledge should not sit in your brain because it will occupy precious
thinking resources that you should dedicate to building great UX and making
the code modular and maintainable which takes dedicating brain cells to
understanding the world around you, not just a commodity piece of textbook
knowledge that makes you feel smarter and covers up insecurities about having
produced dull or even terrible UX -- "hey I know how to balance a red/black
tree or build a hashmap implementation so I must be a under appreciated
genius" when in fact that is commodity knowledge anyone can pick up from
Google and a few hours of research and benchmarking (and having ability to
allocate regions of your brain to tasks of wildly different nature on the fly
which means you never keep crap in your head unless you're using it on daily
basis)

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.

~~~
ryandrake
Bingo. If you're looking for someone who's a walking Wikipedia, then those
"how does this algorithm work" or "what's the Big-O notation of that
algorithm" questions will find that person. If you want someone who gets stuff
done and is resourceful when they need to look something up, then that line of
questioning is going to filter those people out.

------
pmiller2
Here's a list of reasons I've heard for having my resume screened out:

* 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.
:)

~~~
jszymborski
It's too bad to hear that, and a surprise to me... always thinking that it was
an applicants market.

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

~~~
vinceguidry
Python's weird in the ecosystem of languages. It's way more of a hobbyist
language than it lets on. Since, as Patrick writes, most dev jobs are for
line-of-business apps, and Python occupies a very very small niche in that
world, very few devs can specialize in Python and hope to easily find a job if
they present themselves as a Python specialist.

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.

~~~
switch007
I'm not sure about the UK. Python, according to these job-regex-match
statistics, seems more in demand:

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...](http://www.itjobswatch.co.uk/IT-Job-
Market/UK/Programming-Languages)

GB section on this page put Ruby mentions at 3% and Python 6%
[https://gooroo.io/GoorooTHINK/Article/16300/Programming-
lang...](https://gooroo.io/GoorooTHINK/Article/16300/Programming-languages--
salaries-and-demand-May-2015/18672)

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

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

~~~
tetraodonpuffer
what does "citing" here mean? in my experience if a job has, say, ruby, odds
are it's a ruby job, if it has python often it's a job on something completely
different where at the bottom they put "familiarity with scripting (python,
perl) is an asset"

------
innertracks
Ramit Sethi has some great material. He has a download of a handful of resumes
his clients have used successfully in the past including an engineer. I used
those as models after seeing no results from my old resume. Then I submitted
the new resume to a company with great reviews on Glassdoor and open positions
I might be a fit for. I was curious to see what would happen. I was running a
test and willing to follow through if anything came of it. Results are I'm
flying out for final interviews next week. Time to study Ramit's interview
prep material.

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.

------
claudiusd
> What typically happens is that people are screened into a hiring process on
> the basis of what’s on their resume... That already throws a lot of the baby
> out with the bathwater.

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.

~~~
vonmoltke
> 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.

------
vonmoltke
Just a minor note:

> 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.

~~~
bryanlarsen
Are you saying if a superstar dream engineer came along and offered to work
for your company you wouldn't somehow find room for her?

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

~~~
vonmoltke
Basically what nommm-nommm said. We have craploads of work to do, but what
limits our bandwidth is what our customers will actually pay us to do. We do
bespoke work on contracts, so if we don't have the contracts we can't do the
work or hire the people, no matter how badly we might have to.

~~~
infinite8s
How do you have too much work that no one will pay for?

------
phamilton
I had a conversation with a friend about a hypothetical algorithms
certification program. Yearly, you sit the exam, do the whiteboarding,
regurgitate the big O stuff. You get a nice little certificate, and then a
tech company can skip that part of the interview if you show you've passed the
test in the last year.

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

~~~
mywittyname
Theoretically, the employer could just look at the grades a person received in
their algorithms class in college. So, how would your certification program
inspire more confidence than a university degree?

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.

~~~
phamilton
I didn't mean to say it would be an easy problem to solve.

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

------
dreamjobexec
I agree with almost everything in this post with the exception of taking
others for burgers and asking them about their salary (directly or
indirectly).

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...](https://dreamjobexec.com/7-tools-help-get-tech-dream-job-hint-
linkedin-job-boards-not-list/)

------
morgante
I really don't agree with the advice to kick the salary question down the
line.

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.

~~~
calcsam
The solution here is to turn the recruiter's around and say, "I'm not
comfortable sharing that information, but I'm sure you put together a salary
range when you put a rec out for the position. Could you share what that range
is, and I'll tell you whether it makes sense to proceed?"

~~~
morgante
Did you miss the part where I specifically mentioned that I do ask for a
salary range? That works some of the time, but sometimes companies flat out
refuse to give it.

------
jgroszko
Do people actually ask random people from other companies out for lunch? I've
never heard of someone actually doing this, and I feel like if I was
approached at a meetup this way I'd be very unlikely to accept, if not a
little uncomfortable at the prospect.

~~~
fecak
It's sometimes called an 'informational interview', happens quite a bit in the
market I work in (Philly).

------
dpweb
Great points that stood out-- Every company that has more than 10 engineers is
going to hire engineers this quarter. The company really doesn’t care whether
they pay you 100 or 130.

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.

~~~
cgopalan
"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."

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)

------
betadreamer
Is not saying your salary expectation a really a bad thing? In my last job
search I follow this advice and I actually regret it. A lot of times the
conversation goes no where and it can save a lot of time on both ends if you
get that part out of the way.

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.

~~~
solipsism
Do you not try to negotiate then? BB is within their range, and presumably you
can argue why you're more deserving than the lower end of their scale. Why
would they not go for BB?

~~~
betadreamer
Of course you will negotiate but a lot of companies have equations/guidelines.
"We've paid X salary to our employee that is similar to you" or "With N years
of experience at most we will pay X". Some companies have no negotiation
policy.

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.

------
s3nnyy
I also think that asking algorithmic coding challenges make no sense for most
companies. Facebook, Google and other tech giants are you using algorithmic
interviews because everything they do is at scale. However, this is not true
for most companies.

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.

------
dikaiosune
Every time I see advice that centers around "go to meetups, get coffee, make
personal connections," it makes me think that:

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.

~~~
83457
Conferences, conventions, vacations?

------
antonp
Pleasantly surprised to see Ramit Sethi's name pop up in the article. I've
watched some of his 'Find your dream job' videos on youtube and the advice
there was solid and yielded results first time I applied them in salary/job
negotiation situations.

------
dunkelheit
Maybe my part of the world is somehow different from Patrick's but I find some
of the points in his talk simply untrue, and others true only with some fairly
big caveats. Like:

"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!)

------
rubidium
In case people aren't aware, Patio11's comments are pretty much exactly what
is stated (with many more examples and strategies) in "Guerilla Marketing for
Job hunters", a book I recommend whenever posts about job searching come up.

~~~
minionslave
This is helpul or was it guerilla marketing for the book? The world will never
know.

------
pmiller2
It's always good to read about when someone recognizes the process for hiring
devs is so broken. Does anyone know of any companies that are both attempting
to do something about it, and hiring devs?

~~~
bovermyer
My current employer doesn't do technical interviews at all. We might ask about
favorite languages, blogs, or open source projects, but generally we're more
interested in whether the candidate "feels" like someone who is comfortable
coding at the job's level. This has never gone badly for us, and we have never
had to fire someone for not being able to do the job.

------
vpalanc1
His advice flies in the face of every negotiation course/book. Yes, you must
know the range they are willing to pay; but once you know... you don't wait
for them to make an offer, you ask something at the high end of what they're
willing to offer, possibly above (but close enough to) the higher margin(* ).

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.

------
marcell
Tech interviews have become a favorite punching bag of various bloggers, and
partly for good reason. But even still, who can argue with the results? Some
of the tech industries most successful companies (Google, FB, etc.) and many
successful startups use whiteboard coding interviews as their bread and
butter, and it seems to work. Maybe it's not as bad as conventional wisdom
says it is.

~~~
pyb
Some unsuccessful companies also use the same format. It makes a lot of sense
for Google to place maximum emphasis on whiteboard interviewing, not so much
for its lesser competitors. If Google is a more desirable company and they run
the same interview process, won't they be hiring mostly people who failed the
same interview at Google?

~~~
pklausler
The programming world has lots of smart, talented, capable people whose
resumes won't get them even a phone interview from Google.

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.

------
bluedino
These articles are targeted at developers - someone needs to inform the HR
department, that's where the problem lies

~~~
dreamjobexec
HR departments are responsible for HR / behavioural interviews ... dumb riddle
interviews and reverse a tree using a one line function is made for developers
... by developers...

------
waterlesscloud
I've been a professional developer for 20+ years. Not once have I gotten a job
from the submit-a-resume-and-interview path. Not once.

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.

~~~
EliRivers
Well, I'm looking for good software engineers. Getting someone who is a good
software engineer but isn't great at personal connections for getting a new
job doesn't sound like a huge loss.

~~~
waterlesscloud
Whiteboard away then!

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.

~~~
EliRivers
We're _always_ looking, and when I see a sizeable company that isn't, I
consider it a warning note.

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.

------
scarface74
I have never done this song and dance. I've been working professionally as a
software developer for 20 years and my M.O. Is to talk to reputable
recruiters, get an idea what the salary ranges are for my skill set, send my
resume to the recruiter and tell them to send me prospects that meet my
qualifications and that can meet my salary demands.

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.

------
pjdemers
one thing I've learned about negotiating a job is to discuss responsibility,
roles, reporting structure, projects, etc first. Because, in my experience, if
a year later I go to the VP of engineering and say "give me more money or I'll
quit", I get the money. If I say "give me more responsibility and better
projects or I'll quit", I get a going away lunch....

------
despinozist
My code exams are almost always can you do some form validation plz thx bye
becuz I'm dumb.

------
aquateen
In all the interviews I've been a part of (1.5 years, maybe ~50 candidates),
I've never seen a candidate decline because of salary requirements. We would
decide if they were a good hire, and HR would make it happen.

~~~
ovi256
So that's another datapoint confirming empirically patio11's idea that
candidates are underasking. If they would ask for their fair value, 50% of
companies would decline their candidature because of the price.

------
geebee
What I'm writing is tangential, but related to the topic. When we discuss tech
interviewing, I think it helps to start with the basics of the process and the
motivations behind technical interviews that are essentially exams.

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.

------
graycat
Part I:

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?

~~~
graycat
Part II:

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.

------
p4wnc6
I have experience as part of a hiring team that spent over a year searching
for a single candidate, and I also have experience as a job seeker who has
spent over a year searching for a minimally acceptable job.

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.

------
pitt1980
bookmarked

------
golemotron
So job hunting in tech now is "unsafe." Really? Try applying for a law
position, a hospital position, or a standard minimum wage job. Among the many
needs to check one's privilege in this world the thought that the process of
getting a tech job is "unsafe" is one of them.

