
Brief thoughts on getting hired as a senior coder - rspivak
https://medium.com/swlh/brief-thoughts-on-getting-hired-as-a-senior-coder-94f38998bb08
======
peteypao
> I sent over some horrible code in a language I can barely write that I was
> really proud of and explained why.

Why would you ever do that? The whole point of sending over code is so that
they assess whether you can write understandable code. I don't know what you
have to benefit from this.

> I sent over some different code, it was a 5 line code change that halved the
> average response time of an API. But I also said you know, I’m not
> interested in auditioning for you. Either we’re a good match or we’re not,
> but I’m not particularly interested in being “grateful for the opportunity
> to apply”, frankly I think you should be grateful that I took a few hours
> out of my day to explore whether we want to build something together…

Why would you even? Just why?

~~~
Cthulhu_
That second quote is basically saying "I don't actually want to work for you";
even if the code was good, that would've been a rejection from me. The OP
sounds like they're not looking for a job, but looking for people to kiss the
ground they walk on and give them money.

~~~
bdcravens
While I personally respect humility over arrogance, developers are often seen
as disposable resources; this seems to be a bit of response to that.

------
blueadept111
Anyone who seriously expects detailed feedback from a failed job interview
doesn't sound very "senior" to me. I'm pushing 50 after a lifetime in tech and
I stopped expecting feedback about 30 years ago. Also, as someone who's sat on
both sides of the interview table many times, I wouldn't hire this junior dev
who thinks he's a senior, if only because he goes out of his way to inject
snark into the interview process and seems to think that the world owes him
something at every step. Red flags left and right.

~~~
RangerScience
I "expect" it, but realize it won't generally happen. That this shitty
situation is the norm doesn't mean it isn't still shitty, and the lack of
feedback - or even the common straight up ghosting - is one of the reasons I
want to start charging for my time when interviewing. Basically - pay me with
money, or information, but respect me and my time enough that you won't waste
the investment with silence.

Note: I got feedback from everyone I did an in-person with (3, this time
around)

------
docker_up
Frankly, he doesn't sound like someone I would like to work with. The attitude
he exudes in his blog post reeks of entitlement and probably likes to argue a
lot instead of having discussions. As someone else put it, he sounds far too
emotional and definitely not level-headed, especially after his response to
the CTO, admittedly who was also a jerk. More level-headed people would just
ignore the email and not respond, but it sounds like he wanted to get his last
word in, which is an annoying trait in someone to work with.

------
hans1729
>#1) [...] it took /a lot/ of applications [...] I don’t have the actual
numbers

..ok?

>#2) Tech interviews are just stupid broken [...]

..ok?

>I was /never/ offered feedback. Not once! [...] This sucks.

You're talking senior positions. A senior, just going by semantics, should be
very aware of his standing, and what recruiters want to see for the specific
position he wants to be his job. If you have questions, ask the recruiter,
that's appreciated. Why should they spend money on the time it takes? For the
luls? When you don't even ask for it? You tried senior and you didn't make it.
Either you didn't know about important criteria, or you didn't meet them, in
both cases you're just not there yet.

>#4) Recruiters are absolutely useless, unless they are good, and then they
are gold. Not much to be said here, general recruiter model seems to be throw
all your jobs at every applicant, see if any bite. Throw all your applicants
at any job, see if it anyone gets hired. Keep commissions if it works.

the entire paragraph is hot air

>#5) Not publishing salary information sucks. Asking someone what they expect
to make without publishing salary information double sucks.

If you don't know your value, you're not worth the value they'd be willing to
pay if you did. It's not rocket science...

>#6) Weed out the jerks early [...] CTO wrote back and said verbatim, “I
honestly wouldn’t have written you back, because the code you sent over is
terrible. But my team liked some other things about your resume so I want to
give you a second chance to impress me. Can you send over some different
code?” [...] And he wrote back and said basically oh I’m sorry, I thought I
was clear, I have 50 resumes on my desk from the best CS schools in the
country, you went to a boot camp, you /are/ lucky if I decide to interview
you. And I was like, no thanks! Can you imagine for working for that guy if
that’s how he treats candidates?

guy was honest with you, gave you feedback you did't want to hear (heh, #4)
and made sure that you would't waste even more of his time (due to complete
lack of context-awareness with respect to the position and concurrence), while
still giving you a chance, because _some people in his team were interested_.
bruh. this is the best imaginable case. get a grip

~~~
human20190310
> If you don't know your value, you're not worth the value they'd be willing
> to pay if you did.

I disagree with this. Knowing your value requires access to information. For
many people, this information is obtained informally, through connections. But
this puts people without connections, who were at a disadvantage anyway, at a
further disadvantage.

~~~
hans1729
I can't really disagree with this, but am left in conflict:

Information should be free, but shouldn't companies be free to

a) negotiate in their own best interested

b) use NDAs?

~~~
eropple
Almost every company that hires software developers are corporations or
another limited-liability structure, such as an LLC. These entities exist at
the sufferance of the society that grants that charter. They have no natural
rights of any kind and they are granted the opportunity to exist _so long as
they provide benefits to the society granting that charter_.

So you're asking what is, to me, the wrong question. To me, a more valuable
question to community, society, and humanity is "why are we not putting them
in a hammerlock and demanding decency?". Like--is there economic benefit to
hiding this stuff from workers? Or is there _greater_ economic benefit to at
least some significant level of transparency with applicants and with workers
after they're hired?

My guess is that that transparency is of significant social, as well as
economic, value.

------
bitwize
Never expect feedback. Never expect to even _hear_ from the company once they
decide they're not interested. Any communication is a gift, because any
information they give about how they arrive at their decision could
potentially expose the company to liability.

This is the reality in $CURRENT_YEAR and it needs to be dealt with, not
bristled at.

~~~
llamataboot
This may be the current reality, but I still think it is a bad one. The
feedback could be generic and mostly offered as as a platitude. ("We just felt
a few other candidates were stronger in XYZ") If, as an industry, we are going
to drag people through 40-60 hour long processes for hiring (which I think is
largely unnecessary and a waste of money and energy), we can also learn how to
end those relationships (because at that point it is a relationship) with
human kindness.

~~~
alain94040
Have you ever been in the hiring manager position? Because what you propose is
intenable.

Too many things will go wrong when you provide precise feedback.

First, most people don't react well to negative feedback. The natural reaction
is to get defensive.

Tell one person you felt other candidates were stronger in XYZ: they get back
to you with arguments and examples that shows that no, actually they know a
lot about XYZ. Ok, you're nice, you take a look again. Then you decide their
XYZ level is still not up to par and you thank them for their time. Once in a
while, someone will not give up. They'll argue with you forever. Until you
stop all forms of communications. Only a minority of people do that, but out
of the one resume a day you receive, you can be sure to hit this problem
almost weekly. So you learn to stop giving feedback. And of course, once a
year, you have the candidate who threatens to sue because your answers show
that your hiring process is biased/unfair.

We'd love to give good feedback. Others ruined it a long time ago for
everyone.

~~~
llamataboot
I have been on the hiring side and always try to offer feedback, even through
back-channels.

If you tell me, "Hey, thanks for spending so much time with us, the team
really loved talking with you, and we were super impressed with your
experience in X and we were really impressed with your take-home and the way
you dealt with questions about why you decided to go with the architecture
that you did. It was a really hard decision, but ultimately we decided to go
with someone that we felt had a bit more familiarity with Scala and also had
more client-facing experience because it meets our current needs. We'll each
out in the future if we think there's a mutual fit, otherwise best of luck in
your search!"

That may be mostly bullshit, cause there are things you can't say, but at
least it helps me hone in on either areas where you were looking for something
I wasn't, or areas where I might be able to improve. Maybe I get feedback from
3 or 4 places that they want more experience with scaling issues so maybe I
spend the next 6 months trying to hone those skills.

I really don't think it's hard to offer actionable feedback, as I've done it
for every person I've ever interviewed. I'm not gonna tell someone I thought
they were annoying, or underprepared, or grossly over-represented their
abilities, it's not a perfectly honest feedback system, but i I liked someone
enough to spend multiple days with them, I'm certainly going to try to offer
them something honest that I feel would make them a stronger candidate, for
another company, or for future-us.

~~~
llamataboot
and as below comment says, if someone's response is "BUT I'M GREAT AT XYZ"
then fine, block their emails. In my experience 95% of the time it is someone
that says "Thanks! Sorry it didn't work out this time, but I agree that XYZ is
something I need to work on. I'm gonna dive into it thgis year and let's chat
in 12 months and see where we are both at"

Why are you burning candidate bridges to someone you clearly liked enough to
spend over $10k and lots of time interviewing by sending them a one line
canned response?

------
TrackerFF
I think the root of the technical interviewing issue is distrust. For some
reason, too many programmers seem to have a inherent distrust in other
programmers; a kind of "guilty until proven otherwise" mentality, where
everyone else is a hack / fraud in disguise.

Whenever I see people defend the current practice, they tend to back it up
with anecdotes like "I once had a technical manager who couldn't code his way
out of a wet paper bag","We once got this fresh CS grad that couldn't even
write basic control statements, ridiculous!", "I have a co-worker that can't
code".

I'm not sure why this field is more affected than any other I've been in.
Other than "tech", I've been in regular business, and in electrical
engineering (at big global corporations) - and the technical grilling is
absolutely nothing like what you see in coding-focused tech.

I think technical interviews have their place, and are legit, but not when
they're being used the wrong way.

Some guy breathing down your neck while expecting a 100% correct recital of
some esoteric data-structure or algorithm, for the sake of correctness, seems
like a terribly flawed way to go on about things - yet it's something you can
expect to experience in this industry. Reminds me more of quizzing than
interviewing.

So yeah, that's my observations on the current atmosphere. There are good
companies with good practices out there, but sadly a ton of low-effort stuff
that probably hurts both parties in the long run.

~~~
jpm_sd
I'm an EE who has worked with and interviewed a lot of SWEs. Software is a
uniquely "fake it till you make it"-compatible career path. There is an
oversupply of people who look pretty good on paper but execute poorly.

------
candybar
So I do agree with most here that you shouldn't care one way or another about
getting feedback and the author seems to be overreacting somewhat, I do want
to share that for each of my last 3 rejections from startups, I did receive
politely worded feedback as to why I was rejected. So again, while I do agree
that the author is overreacting in the sense that it's not helpful to
emotionally react this way, I don't think his expectations are necessarily out
of line - it's possible to treat candidates better and the more candidates
expect to be treated well, the better the industry will be.

On top of this, the criticism regarding how the author is self-unaware (I
don't entirely disagree) seems especially misguided because often how self-
unaware people become self-aware is through constructive feedback. With that
in mind, since the author seems to be here, the one piece of feedback I have
is that:

"I sent over some different code, it was a 5 line code change that halved the
average response time of an API."

I don't know if the author was at this point interested in the job or not (if
this was a joke, please disregard) but some clever 5-liner is extremely
unlikely to impress anyone looking for a senior engineer and is impossible to
evaluate in isolation. Also most of the work involved in "halving the response
time" \- again, assuming a reasonably complex system - is identifying where
the bottleneck is, not writing the simple fix to address the issue that was
discovered. You're expected to write substantially more code than that even in
a 30-minute technical screen. When people are looking for code samples (again
for a senior engineer), they are looking to see the ability to design and
organize larger chunks of a system, make trade-offs between different
architectures and ability maintain good code hygiene over a larger sample and
so on - providing a 5-liner raises more questions than it answers.

------
wolco
There is a randomness to it. Applying for remote positions I found I could get
rejected this month reapply and make it through the process next month with
same cover letter/resume.

There is an oversupply of developers generally and an under supply who know
your exact stack.

------
RangerScience
Where I'm at, the next time I do a job search, I want to charge for my time.
I've got enough public work on Github (or, expect to soon, as this art project
progresses!) that you can review _that_. If you want something just for you,
pay me. That way I know you value it, as well, because otherwise it's nearly
free for you.

A few interesting things happened this interview cycle: 1) I actually did get
feedback, at least from the companies I had an in-person with. I think I
managed that by enthusiasm and friendliness during the interviews. But, a
bunch more didn't give me any feedback and barely told me that they weren't
progressing, which sucks. AngelList itself was actually one of them.
Penultimate communication was "we really liked your takehome", next
communication was nothing, but when prompted they said "actually no" and
nothing more. :/

2) I was asked to write a lockable node tree as part of a remote screen-share
tech screen. I wasn't too excited about the job, so I felt like taking a risk
and pulled out a line I'd wanted to pull out for awhile: "If this is the kind
of work I'd be doing, I don't want this job. How about we switch to something
more like what I'd actually be doing?". Still wrote the code, and did get a
call-back, but by then I'd found something.

3) During an in-person tech screen, they asked me to implement something I'd
already done as part of a different tech-screen, so I just pulled that up and
we went from there. It was fantastic. That one ended interestingly; I get "we
really like you and would want to hire you for a position we don't currently
have but we don't have that position yet" rather more frequently than seems
reasonable.

------
AnimalMuppet
40-60 hours for an interview process? Do people really do that?

For my current position, I had a half-hour phone interview, then a 2 hour in-
person interview. My previous job was about the same.

For out of town interviews, I've had to fly out the evening before, then a
whole day process, so maybe 30 hours total even if you count the time I spent
asleep in a hotel. I have _never_ had a process take more of my time than
that.

~~~
yibg
40-60 seems excessive / exaggerated. Maybe it’s due to long take home
exercises? My experience has typically been 1-2 hours of phone, followed by
anywhere from 4 - 6 hours onsite potentially split across 2 sessions. If we
include travel and subsequent negotiations, and initial application and
research maybe 10 hours total?

------
yibg
He does have some correct observations. Information asymmetry, getting
ghosted, the ungodly time needed to go through interviews are all real
problems. Too bad the points are poorly formed and the whole article is just a
rant.

Also, funny what is considered (or at least how one considers themselves)
senior now. 15 years in and I think of myself as mid level.

------
larrik
I hire exclusively "Senior" devs, and our process is tough to get through. I
found the author's details online. Here's my thoughts:

> "Senior Coder" His education and experience puts him on _verge_ of Senior,
> but I'd go in expecting not a lot, and probably focus on throwing shit from
> right field at him and seeing how he react and learn on the fly. The blog
> post strongly implies he'd just angrily hang up (which is actually rare!)

Also, "Coder"? I can see he went from design to PHP to Ruby (via a bootcamp),
so I can see why he uses 'Coder' here. I don't want 'Coders', though. I want
people who can deliver well architected full stack solutions while being able
to mentor junior devs in the process. The article and experience leaves me
pretty low expectations of that.

The simple fact is that it's WAY WAY worse to hire a bad fit than it is to let
TEN great devs walk away.

~~~
ryandrake
> The simple fact is that it's WAY WAY worse to hire a bad fit than it is to
> let TEN great devs walk away.

This simple statement sums up so much of what is broken about tech hiring.
Everyone prides themselves on how they take smart risks and how
entrepreneurial they are, and how they “fail fast” and “explore.” Yet when it
comes to hiring, all of a sudden it’s “OMG we have to be super conservative!
We can’t fire people and one bad hire could ruin us! We must reject 99% of
candidates because Risk.” What happened to being bold and risk-taking?

~~~
larrik
In theory that sounds great.

But, good/great devs only want to work with good/great devs. You get a bad fit
in there that manages to stick around, and your good/great devs start to
leave. Then you end up with either only lesser devs or a bunch of devs that
hate each other.

------
msluyter
Regarding the issue of feedback, IANAL, but I would have to guess that this
would open the company to liability/lawsuits. Incredibly vague feedback might
not be (directly) actionable, but regularly offering feedback raises the
possibility that the person offering it says something -- inadvertently, or
perhaps because they are in fact biased/jerks -- that implicates a company in
discriminatory hiring practices.

Even if feedback in a single case isn't actionable, one can imagine that in
aggregate it could be. If during discovery lawyers can find certain
themes/patterns in the feedback offered to rejected interviewees, they might
be able to use that as evidence. Perhaps I'm paranoid, but my wife's a
lawyer....

Aside from that, in simple economic terms, offering feedback makes no sense.
After all, if it helps rejected candidate, you're basically helping to improve
someone who may end up working for your competition. And if it doesn't, you're
wasting time. I'm not saying "in economic terms" is the right/only way to
guide behavior, but if you want to understand the behavior of most companies,
it's something to keep in mind.

------
jpm_sd
I think one of the reasons technical interviewing has become so cumbersome is
because companies are very reluctant to fire employees who are not working
out. Thus, they have to make sure it's an absolutely perfect match up front.

Wouldn't it save time and cost overall to hire fast and fire fast? Make it
very clear that your first two weeks are a vetting period and your first 6
months are still probation?

~~~
AnimalMuppet
Legally, you'd probably have to structure that as "contract to hire".
Otherwise, "fire fast" is probably going to open you up to lawsuits. (You may
win those lawsuits. They're still expensive.)

~~~
jpm_sd
What is required beyond "your at-will employment has been terminated"? What
are the grounds for your hypothetical lawsuit?

~~~
AnimalMuppet
It's easy to file a lawsuit. You have to claim something mildly plausible that
the court recognizes as possibly legally valid. At that point, the company has
to burn lawyer time in order to fight the case. Even if they win, it cost
them. (It cost the ex-employee, too, but the company doesn't care about that.
They only care that it cost the company.)

Maybe I'm cynical from watching SCO v IBM ( _still_ not over, after 16 years,
even though SCO never really had a case), but my perception is that you can
file a lawsuit without a case. You just have to, in your initial filing, give
the appearance that there might be a case.

------
meesles
The point about feedback is spot-on. It's chronic across hiring because hiring
teams are trying to find their candidates and save time/money.

What people forget about is the social capital you gain/lose. If 50 people
come through your process and you give no feedback, they'll tell their friends
about your weak hiring practices and that alone will cost you candidates.

If you've already put in many hours to interview someone, taking 30 minutes to
explain some areas of improvement or why it wasn't a good fit is a very
valuable thing to do for your business in the long-run.

~~~
reikonomusha
Is it demonstrated that the company actually gets a return, or is it the case
that 5–10% of candidates will feel happy to receive feedback, and 90–95% will
feel like it’s a chance to rebut and defend themselves, leading to a situation
to deal with?

~~~
llamataboot
I think that if a candidate has made it through your entire process, that you
already should have a good read on them and trust them essentially. If you
decide not to hire them and they write you a note thanking you for the
process, offering you some feedback on your interview process (positive and
improvements) and ask if there's anything they could focus on over the next
year or two that would make them a stronger candidate, that it's pretty clear
they aren't going to fight with you.

And yes, I do think you lose the opportunity for someone to reapply to another
open position (or refer their friends) which is a shame, because presumably
you thought this person was a /strong candidate/, they just didn't quite work
out at the end for some reason.

------
mcv
> _#3) I was /never/ offered feedback. Not once!_

> _CTO wrote back and said verbatim, “I honestly wouldn’t have written you
> back, because the code you sent over is terrible. But my team liked some
> other things about your resume so I want to give you a second chance to
> impress me. Can you send over some different code?”_

So you did get feedback, but only from the company you decided to be a jerk
to.

