
Hiring Is Broken: What Do Developers Say About Technical Interviews? - azhenley
https://www.researchgate.net/publication/334448588_Hiring_is_Broken_What_Do_Developers_Say_About_Technical_Interviews
======
palisade
I once interviewed at a company that had you write a traveling salesman
program where you were planning the shortest path of flights between cities.
It was a take home test where you were given at least a week to complete it. I
completed the test in record setting time (3 days earlier than most), mine was
the only one that was fully documented with comments (no one else bothered to
do this), they said I had the most visually stunning user interface (most were
ugly or unusable; I even animated the plane flying between cities), the
program came to the outcome in the shortest runnable time, out of all the
submitters they said my program was the most optimized solution (not the best
ever made, but the best submitted to this company so far), and mine was the
only one that actually worked correctly and ran without flaws. They then
proceeded to have me come in for the 6 hour interview in which they asked
questions like, "Write a working hash table from scratch on the whiteboard." I
got nervous and passed the question, they ended the interview early and
rejected my application.

~~~
WalterBright
The problem with take-home tests is you may have had help, or someone else did
the test for you. If you didn't do well in the in-person test, they may have
reasonably assumed that was the case. Especially if the home test was
unusually good.

I was aware candidates would do things like this when I applied for job long
ago. I also was aware that employers were suspicious of these sorts of things.
So I brought along listings of code I'd written, pulled them out, and walked
the interviewer through how they worked to show I knew my stuff. Note that
they didn't ask for this, I just did it proactively. I got an offer, too, and
was told some time later by the interviewer that that was why.

~~~
scardine
My companies do something a bit different: we ask people to pick any issue
from any opensource project in our tech stack and try to land a patch closing
it.

We think this is better then wasting the candidate's time on a toy project -
at least the can write off their time on the opensource-karma account.

Also, we can check not only their code but also their communication style and
other skills that matter in the real world (projects on our tech stack have a
high threshold for documentation, unit tests and other stuff that matters).

We call it "social code challenge" and it is working wonderfully for our
recruiting process.

~~~
jammygit
I basically like the approach, but I'm a bit wary after playing devils
advocate with it for a moment.

A candidate might reasonably assume that they can look better than the other
candidates by spending more time on the problem and tackling a larger or more
impressive ticket. If you imagine a world where all interviews were like this,
candidates could end up working 60 hours a week on these projects in the
normal course of job hunting (easier to imagine if you assume that the talent
shortage isn't permanent). Probably, since they can see the size of the
contributions made by previous candidates, the pressure increases over time as
well.

edit: it would be amazing for FOSS in general though. Imagine how much faster
GNOME would be if hiring committees required you to write bug fixes for
popular projects.

~~~
scardine
> A candidate might reasonably assume that they can look better than the other
> candidates by spending more time on the problem

The same is true with a take-home, candidates see the (often underestimated)
statement "this should not take more than X hours" and assume they will have a
better shot if the invest more than the X hours.

I forgot to mention that we also accept past contributions - in the end the
hypothetical candidate can spread this 60 hours investment over any other
hiring processes using the same method.

I'm thinking about writing a "social code challenge manifesto".

------
noego
I've read a million "hiring is broken" articles about software companies, so I
asked my sister (lawyer) yesterday how the legal industry does hiring. She
told me that even at the most prestigious and exclusive legal firms in the
nation, the interview success rate is ~50%.

That seemed staggeringly high, considering that Google's is less than 10%. So
I asked her how these legal firms managed to pull off such a high interview
success rate. Apparently, they only ever invite someone to interview, if they
are already pretty sure they want to hire that person. And how does that work?
They make no attempt whatsoever to judge your competency on the basis of
interview performance. Rather, you are judged almost entirely by your resume -
the "brand name" of the law school you attended, your GPA, and the "brand
name" of the law firms you've previously worked at. If your school or previous
law firms aren't prestigious enough, you won't even be invited to an
interview.

In fact, not only is the above a convention, it's often a firm policy. My
sister once got a job offer, through very fortunate circumstances, at an elite
law firm. But their HR department blocked her hire, literally because she did
not attend a top-15 law school.

Ironically enough, I've never heard anyone complain about legal hiring being
broken. Perhaps that's precisely because legal firms don't even give most
people a shot - they are filtered out entirely at the resume stage. I imagine
people get far more agitated when they are rejected after an interview, as
opposed to being ignored entirely from the outset.

I'm personally glad to work in an industry where even the most exclusive
companies are willing to give everyone a shot at the interview, regardless of
which school they went to. Is hiring broken in tech? Sure. But it's completely
dysfunctional elsewhere.

~~~
DavidAdams
Malcom Gladwell addresses this strange credentialism in the legal industry in
a recent podcast. In his reckoning, entry into top law schools is determined
almost entirely on LSAT scores, and the LSAT favors people who can process
questions extremely quickly. But good lawyering is done by deliberative people
who often don't perform well on standardized tests. In the podcast, a guest
who took a look a legal hiring determined that LSAT or resume from top firms
were not good markers of a good lawyer, so yes, legal hiring seems to be very
broken. [http://revisionisthistory.com/episodes/31-puzzle-
rush](http://revisionisthistory.com/episodes/31-puzzle-rush)

~~~
dogma1138
For every court room charmer or a loophole engineer a large firm will 100’s of
associates digging through documents and filing motions in the background.

In fact if a top tier law firm does their job well they would likely never get
to a court room.

The main “need” of large law firms is an army of motion bees and discovery
drones.

If anything it shows that large firms have too much of an influence over
school admissions rather than that legal hiring is broken.

------
tropicalia
_Let’s begin with a technical interview problem. Consider the following coding
question from LeetCode, an online platform for preparing software development
candidates for interviews:_

 _[statement of the Maximum Subarray Problem]_

 _Before going further—and regardless of your coding proﬁciency—we’d like you
to spend a few minutes and take a stab at this question._

From Wikipedia:

 _The maximum subarray problem was proposed by Ulf Grenander in 1977 as a
simplified model for maximum likelihood estimation of patterns in digitized
images. ... Grenander derived an algorithm that solves the one-dimensional
problem in O(n2) time, improving the brute force running time of O(n3)._

 _Jay Kadane of Carnegie Mellon University soon after designed an O(n)-time
algorithm for the one-dimensional problem,[1] which is clearly as fast as
possible. The same O(n)-time algorithm was later automatically derived by
algebraic manipulation of the brute-force algorithm using the Bird–Meertens
formalism.[2]_

If you really think anyone -- short of a faculty-level algorithm specialist at
places like CMU -- can be reasonably expected to derive an optimal solution to
problems like these _on the spot_ (as opposed to the way candidates are
actually forced to prove their ability to "solve" them: by binge-cramming on
dozens and dozens of problems like these for weeks on end, so that they have
at least a 50 percent change of passing your "filter") --

the you're either very naive, or deliberately kidding yourself.

~~~
zinclozenge
Presumably asking questions like these would be fine if the expectation to
solve wasn't there, and instead their performance was evaluated based on how
their reasoning/approach changes with hints and discussion with the
interviewer. But instead gotta be able to solve at least 1 question and make
good progress on a follow up to be considered for an offer from a FAANG
company.

Now if you'll excuse me I need to grind out some dynamic programming problems.

~~~
shados
> to be considered for an offer from a FAANG company.

I don't disagree with the main point, but FAANG companies' interview questions
are available all over the net. In many cases (most?) they'll literally tell
you what they are ahead of time, so it's a lot more of a filter for grit than
a filter for computer science aptitude.

Eg: I know for a while Google was pretty keen on asking about A* algorithms. A
friend who worked there mentioned that to me. Not having a CS degree myself,
my first reaction was that was a very "either you know it or you don't...maybe
you can figure it out, but that's not gonna be fun" kind of situation.

At some point i saw the material Google gives out. A* was literally listed
there as something that they were likely to ask.

Now, it does mean preparing for a very specific interview, which not everyone
(or even most people) would be willing to do. And today I don't think Google
has the reputation to pull that stunt off for much longer. But a couple of
years ago, if you really wanted that free cafeteria? Its a small price to pay.

~~~
notatgoogle2
When I last interviewed with Google (which was about 8 years ago, I think),
they explicitly told me not to post my questions to the internet, and if I
recall correctly, had me sign an NDA about the questions because they want to
reuse them. I don't know if that has changed in the intervening years.

~~~
shados
My info is also pretty out of date, but for a long time at least they would
give a PDF/flier thingy with a "how to prepare for your interview" that had
all that stuff listed, and it went in a lot of details.

------
twblalock
Every time this comes up on HN we see why the problem is so hard to solve:

\- Nobody likes whiteboarding

\- Take-home assignments are unpaid work, and candidates who are raising
children don't have time to do homework after they get home from work

\- Pair programming during interviews makes people uncomfortable because of
the pace or because it's not how they are used to working

\- People who currently have good jobs are unwilling to consider contract-to-
hire or "tryout" periods

\- Credentials, including graduate degrees, are no guarantee that someone is a
good engineer

The current interviewing situation in the industry sucks but all of the
alternatives are worse in important ways.

~~~
tempsolution
> Nobody likes whiteboarding

That's why companies should allow laptops.

> Take-home assignments are unpaid work

True, they could be optional. You may not get the job if you don't do it.
Honestly, if you can't spend one or two hours on a take home assignment during
a 7 day period, you certainly have different problems than applying at this
company.

> Pair programming during interviews makes people uncomfortable

I agree, pair programming during an interview is mostly a no go. Not because
of the issues you mentioned but because most interviewers are totally
unqualified to do this properly (unfortunately, most interviewers are also
unqualified in general to conduct interviews). It takes a lot of skill to
conduct pair programming interviews and draw the correct conclusions.

> People who currently have good jobs are unwilling to consider contract-to-
> hire

In US, there is practically no difference between those three. You can be
fired any day anyway. But yes, if you have a secure job that is good, the bar
for switching is high, but so what? Why even switch? It's your choice then...
Luxury problem!

> Credentials, including graduate degrees, are no guarantee that someone is a
> good engineer

I would go as far as saying your credentials and degrees are horrendously
irrelevant in predicting your skills as an engineer. The only thing you might
be able to conclude is that a GPA 4 M.I.T. graduate probably can pick up
missing knowledge quickly, as opposed to a no degree dish washer who learned
"how to code" in a 6 week bootcamp.

On that note I have experienced first hand, Berkeley and Georgia Tech CS
majors, who were absolutely incompetent on the job and just had no idea what
the hell they were doing, with little improvement in sight...

~~~
jedberg
> Honestly, if you can't spend one or two hours on a take home assignment
> during a 7 day period, you certainly have different problems than applying
> at this company.

That's an extremely privileged thing to say. And what a terrible way to start
out your working relationship. The very first thing you ask of me is to do
unpaid work in my free time? IF you're willing to do that, how else will abuse
me in the future?

Also, why should they spend time on your homework before they know if you're a
company they would even want to work for?

~~~
gjm11
I mostly agree, but attending any interview is _also_ doing unpaid work in
your free time, and often takes a comparable amount of time to the sort of
take-home assignments used for recruiting.

I think the reason why take-home assignments tend to feel more unreasonable is
the asymmetry. If I attend an interview, it's costing a pile of my time, but
it's also costing a similar pile of time for multiple people at the company
where I'm interviewing, which gives me some reason to think that my
application's going to be considered seriously and therefore that the effort
I'm putting in isn't going to be totally wasted.

Whereas a company can hand out a take-home assignment with no effort at all,
so the fact that I've been given one doesn't indicate that the prospective
employer sees me as a serious prospect or that there aren't hundreds of other
candidates in the same position as me, so it's no guarantee that my chances of
getting hired aren't miserably low, so there's more risk that I'm wasting my
time.

~~~
jedberg
I think you've hit the nail on the head here. A homework assignment does not
indicate seriousness on the part of the company. Great insight!

------
gopalv
> He has Aspergers and locks up and fails miserably in the interviewing
> process, but the honest, reality is, he is10 times the developer I am, the
> guy sees patterns instantly and has a knack for code organization.

I don't think I can get hired without a referral - haven't managed to land a
cold interview once so far. So at least, there's no evidence of it.

Interviews are a performance act, they are the packaging that you throw away
after buying a product for the cover.

The interview "suit" I wear is actually one of someone who's calm and smiling
- instead of stimming with my hair and dead-pan with a smirk (if I was a
woman, I'd have resting b-tch face).

I feel for this guy, because I figure out how to wear that suit, but I still
need to thumb the scales to get hired, because the mask I'm wearing is effort
& it does show to the perceptive HR person (& it doesn't matter what you are
faking - if you're faking it, it counts against you).

However, here's where everything is unfair in this world.

I have a pretty decent job because I ran into the right people at the right
conference back in 2004, where someone noticed that I might be able to do hard
things with minimal effort (and fail at easy things, simultaneously).

There must be thousands of people in my state who never got that "come to
Yahoo, have a coffee" invitation & get plugged into a network of people who
have kept me gainfully employed for more than a decade.

I definitely had fewer challenges there because I wasn't an outright minority
in the industry - I didn't have anything to prove beyond the performance.

~~~
itronitron
All things being equal, I'd rather hire someone that seemed nervous in an
interview than someone that seemed relaxed, as the former is a good indicator
that at least they are excited about the position.

~~~
rtkwe
That's gotta be a very noisy signal though. I'm nervous in any interview or
public speaking thing whether I care much about the thing or not.

------
ThrottleHead
No one wants to address the elephant in the room, and that's that "leetcode"
or "codefight" tests have nothing to do with your ability to design and build
complex systems of interacting parts.

Why anyone puts a high degree of credence into these tests and whether someone
can solve one in a high-pressure interview is beyond me.

Give them a take-home assignment where they can develop something similar to
what they would be at the company, and decide if they wrote efficient, elegant
code that's easy to follow.

Also, if you're self-taught and applying to a team of CS majors, may the force
be with you. No one's more insecure than a CS major interviewing a guy who
might have more development experience than he does.

------
jedberg
The problem with hiring in our industry is the lack of licensing/certification
that everyone trusts. When a doctor interviews for a job, they don't ask the
doctor to perform six surgeries in a day for free and then say, "we'll get
back to you". That's because they know that if the doctor holds a license and
a degree, they have the necessary skills.

We don't have that in our industry. I interviewed countless "senior engineers"
with degrees from well regarded universities who couldn't write a simple loop.
Therefore I must now conclude that a degree from that university means
nothing.

There are some folks like Tripplebyte who are trying to solve this by pre-
qualifying candidates, but I don't think the problem will really be solved
until we form a software engineering licensing board. Take a test once, and
then take a refresher course every couple of years to maintain your license.

~~~
commandlinefan
I’m shocked at how important software development is to the 21st century
economy while we still don’t have anything even remotely resembling a
licensing exam. I’d honestly welcome one, if for no other reason than to be
able to make some assumptions about what my co-workers already know vs. what
I’m going to have to explain: do they know what a socket is? Do they know how
public key cryptography works? Do they know the difference between a unit test
and an integration test? It might not be perfect, but it would be a heck of a
lot better than what we have now.

~~~
dudul
> Do they know the difference between a unit test and an integration test?

Funny when you think of how many blog posts, flame wars, SO questions exist on
the internet just to debate what is indeed a unit test, and what is an
integration test :)

Who would have the legitimacy to design such an exam?

~~~
analog31
>>> Who would have the legitimacy to design such an exam?

If it's like civil engineering, it would be the regulatory body that
determines the approved technologies and design formulas for your field. The
exam would be based on those standards. I'm not sure most governments would
even approve public key cryptography.

Better watch what you ask for. ;-)

------
tombert
I've put a line in the sand that I won't do take-home projects anymore for
anything short of a "dream job". They can be extremely time-consuming, and
it's entirely possible that they'll decide that they don't like you anyway. If
the project doesn't result in an offer, and if I don't really have a need for
another "Roman Numeral to Arabic Number" converter, then the time is
completely wasted.

~~~
HiJon89
Engineers: coding exotic data structures on a whiteboard in a time-crunched
interview is high-pressure and unrealistic!

...how about we give you a project that more closely reflects problems we
solve here day-to-day that you can solve in the comfort of your home on your
own hardware in whatever IDE makes you comfortable?

Engineers: That's absurd! I've drawn a line in the sand!

~~~
palisade
Ah well the hash table wasn't exotic.

But, software engineering interviews are pretty rough. It is a uniquely
miserable experience. Since I'm a temp worker I have a lot of them. They don't
get easier.

I don't know of anyone who likes high pressure time crunch interrogations
except maybe the ones getting to do the interrogating part.

A take home test isn't so bad. But, ya if you asked me today if I'd be willing
to do one like that again I'd say probably not unless I was desperate. The
reality is, it is a lot of effort to put in for it to all come crashing down
with a rejection anyway. When you're applying at dozens of companies if
they're all requiring that level of time and mental commitment from you, you
can't swing it really and it's stressful. Interviewing and being under
financial pressure at the same time is already a stressful position to be in,
let alone being mentally and emotionally flogged for it.

All the jobs I was ever hired onto the hiring manager just had a good gut
feeling about me and the tests never mattered. And, they were happy with my
work.

The ones that never hire me usually rely on all the employees to vote on you,
if even one says no you're out. Or, the ones that are very fixated on your GPA
or whether you can invert a binary tree on the whiteboard while they yell at
you "Wrong!" along the way.

~~~
kazinator
> _All the jobs I was ever hired onto the hiring manager just had a good gut
> feeling about me and the tests never mattered._

At one, the _resume_ didn't matter! When through the interviews, got the
offer, and then "oh, can you send me your resume, so we have it on file?"

~~~
heelix
Early in my career, I went to an open house sort of thing. Hit it off chatting
with one of the chief architects who basically cut through all the red tape
and got me a position. A couple weeks after starting work, I get a rejection
letter from HR. Was a bit awkward conversation when I went up to their office
with the letter to check if I still had a job. (I did, but boy was I sweating
at the time)

------
justinmk
> “I think it’s offensive and I don’t like how the industry has standardized
> on basically assuming everyone’s a bullshitter,”

I think it's weird for people to complain about whiteboards and technical
questions, given the implied alternative. There are many other industries if
you prefer the traditional hiring model.

That is, if you can get an interview. While you complain about the awkwardness
of a whiteboard, people in other industries are quite happy to get a call. And
in the interview, they compete in terms of poise, diction, rapport, and other
intangibles, without the chance to repair any lack thereof by demonstrating
technical competence. And they get 1 hour to make their case, not 3-6 hours.

~~~
xamuel
If you give someone gold long enough, eventually they'll complain how heavy
and ugly gold is.

Whiteboards are an unbelievable utopia compared to so many other disciplines.
It's an amazing stroke of luck that software developers don't have to do
medical-style "residencies". We don't have to rely on letters of
recommendation from our professors (hope that professor you slaved away for
for six years doesn't have a bad day when he writes your letter!) We don't
have to pay thousands of dollars to take excruciating standardized tests to
obtain certifications that expire in a decade. We don't have to do unpaid
internships, we don't even have to wear business suits to the interview.

Software devs don't realize how many people in the world would kill to have
things as good as we have them.

~~~
gjm11
There's a lot of truth in that.

But I'm not sure it's that developers are being given gold and don't recognize
it. It's that developers are being given mud and recognize it, while most
other people are being given shit instead.

I'd rather be handed a pile of mud than a pile of shit, but it's not hard to
feel that there must be some alternative that's better than either.

(Maybe there isn't, though. Matching candidates to jobs is just _hard_ , I
think; everyone's incentives are misaligned, performance is difficult to
predict, it's amazingly difficult to get past your initial snap judgements or
even to realise that you're failing to do so, etc.)

~~~
lacker
Well, _some_ developers feel like they are being given mud. But developers who
are really good at whiteboard interviews feel like they are being given gold.

------
Nelkins
Honest question, which I can't really answer myself: Do people think the
hiring process for developers is more broken as compared to other industries?
My personal experience says that interviewing as a developer is often more
straightforward and less arbitrary than what my non-tech friends have
experienced.

Can anyone who has made career changes to or from tech give their experience?

~~~
SQueeeeeL
All hiring is extremely arbitrary. The reason coding is so bad is because
there's this huge myth of lower class workers becoming coders overnight, just
by studying for a few months of leet code.

There is an essay about the feminist movement in the 70s
([https://www.jofreeman.com/joreen/tyranny.htm](https://www.jofreeman.com/joreen/tyranny.htm)).
It makes the reasonable point that people are likely to hire/recruit people
similar to themselves. The code interviews are expected to remove this, if you
stick a bunch of CS people in a room and tell them to make an unbiased
interview process; you'll get the hell world we live in today. To get a job on
a sales floor, most of it is just impressing the existing gate-keepers.

Coders live in a fantasy world where gate keeping isn't real. Except it isn't
possible to remove that from hiring, no one wants to hire someone who doesn't
integrate well in their team. So we have this hellworld where people can study
for 3 months on leet code and nail the tech interview, they still won't get
the job. Even though the "unbias" process says they should.

------
throwaway_a0f1
I genuinely don't understand what this industry is looking for in an interview
process.

Some background, about 2 years ago I started teaching myself to program full
time. About a year ago, I felt confident that I knew enough to get a job,
taught myself all of this leetcode stuff, and started applying.

People told me that if I could crush leetcode, I'd have no problem getting a
job. What they didn't say was how impossible it was to get an interview when
transitioning fields.

I was also told that people would look at my GitHub code, but considering
recruiters spend about 15 seconds on a resume screen, this is more of a meme
than reality.

In the last year in Bay Area, I've managed a total of 2 on-sites with well
over a hundred applications, all of them quite targeted. Maybe 8 companies
total have engaged with me, and I have not missed a single one of these types
of questions at any point in the process, yet it hasn't been enough.

It seems that there are so few entry level jobs that that market is extremely
saturated. I'm not sure how this industry expects to address it's serious man
power shortage if no one wants to hire juniors.

~~~
lacker
_I have not missed a single one of these types of questions at any point in
the process_

The most likely problem is simply that you are getting questions wrong, but
you don't realize it. Companies don't often give candidates whiteboard
questions, have the candidates nail those whiteboard questions, and then drop
the applicants.

~~~
throwaway_a0f1
I mean that's a fair take, and one I've tried really hard to examine, but I
feel as though the questions have a very obvious answer and you either get it
or don't. And to reply to that, no one actually gives feedback so you'll never
actually know.

Looking at your profile, you seem well suited to be able to evaluate this, so
let me give an example from an interview I just had.

Here's a problem and solution from the last interview I had:
[https://pastebin.com/LyVYqLv4](https://pastebin.com/LyVYqLv4)

~~~
ben509
Python: uses underscores. Java, Javascript: camelcase. .NET: Capitalize. And
so forth, those are the conventions that professionals use, so stick to them
for an interview.

`biggestSize = 99999999 #MaxInt` This is returned if the caller passes you 0
for slicesToFind, so you're returning a nonsense value in that case. Either
raise an exception (preferred as it catches errors fast) or return None.

`def area(size)` You're using pi r^2, so size is a radius, but it seems you
call it with a diameter. This is why choosing distinct names is very
important.

`newSize = (originalSize / newSlicesInCake)` Again, using "size" all over the
place is confusing. I'd write something like `new_slice_area =
(original_cake_area / new_slice_count)`.

~~~
throwaway_a0f1
Thanks for feedback about convention and variable naming- you're totally
correct I should work on both.

As far as 0 input, they actually told me it would always be valid so edge
cases were not accounted for.

~~~
ShamelessC
I personally think you had a strong answer despite the criticisms mentioned.

But, yeah. Casing convention was surprisingly important in one of my
interviews. They wanted to know that I was able to adapt to a new language as
the job was for a language I didn't have on my resume. It's weird, but I
understand where they're coming from. Seeing improper styling in a code review
is an immediate red flag and an interview problem is ultimately a code review.

------
leet_thow
I just went through the interview process with multiple Bay Area startups.
Competency and experience don't really account for much and it is much more
about the companies internal politics. People are thrown in a room without any
evidence based HR training to wing it. The processes are ridiculously
bureaucratic, in most scenarios you need approval from 5 different people who
at any time can decide they don't like you for their own personal reasons.
Given a 50/50 chance with each person, that is a 3% chance of getting an
offer. People have no idea what they are doing.

~~~
dahart
> People have no idea what they are doing

Just for some friendly and non-judgemental feedback from a different point of
view, to me that sounds like more of your own fear coming out than reality.

Everyone who interviewed you also said the same things out of fear before they
were hired, and then they got in and didn't manage to change it. That could
mean it's not viewed as a problem from the inside...

Companies are hiring people onto _teams_ , not to hero-solve pure code
problems in a vacuum, but to work together with other people. Communication
and personality and attitude are all super important, usually more important
than technical skill. (That doesn't mean technical skill is unimportant, it
means precisely that people skills are more important, for the average
programmer candidate.) It's a feature, not a bug, that team consensus is
needed. And there's rarely 50/50 chances, using that to speculate wildly on
your chances will prove incredibly inaccurate... the most common case behind
the scenes is that more or less everyone agrees that either the candidate is
right, or that they're not right, or that everyone is meh on the candidate so
nobody is pulling for them.

Chances are determined by how many people are applying for the job versus how
many jobs are available, with a side of how long the company wants to take to
fill those positions. The company has the upper-hand knowledge of what the
candidate pool looks like, and they can hire the top 10% of those candidates
who apply. As an applicant, you have no idea and no control over that. All you
can do is improve yourself, research as much as you can, try many options, and
try again when it doesn't work out.

~~~
bradlys
I'm working at a unicorn. It's a relatively unknown one. They have no idea
what they're doing. I've talked to peers across the bay and with my various
companies I've worked at - they almost universally don't know what they're
doing.

I've interviewed at over 100 places in the bay area. I'd say that from
internally and externally, most of the companies here have no idea what
they're doing. Most don't use rubrics, most don't have a standardized set of
questions that have been heavily reviewed and tested, there is either no
training or inadequate training, and most are winging it completely. Many ask
whiteboard questions to interview candidates and they never had to do them for
the job they got (got in through referral or at a different stage when they
weren't doing such questions). Resume, referrals, and charisma will get you
into positions very easily in many of these companies even if you're very
technically challenged compared to others with less resume+referral+charisma.

Being liked is one of the best ways to get into positions you are terrible at
but compensated so well for.

~~~
dahart
I hear you and I can very much agree ... especially for startups. And the
majority of companies are startups. But! I don’t know exactly what “they don’t
know what they’re” doing even means, it’s not well defined. That sentence
implies you have some specific unstated expectations. What are you expecting,
and why? What I’ve seen a lot of in interview and hiring threads is a lot of
expectations that aren’t fully realistic.

Does it matter if someone who didn’t get asked whiteboard questions is asking
you whiteboard questions? That question is implying some vague concern about
fairness, and isn’t focused on whether whiteboard questions are a good idea.
On the positive side, at least they’re asking coding questions and not hiring
100% based on resume and charisma, which definitely happens in other
industries.

Younger programmers especially seem to think more often that highly reliable
technical evaluation in interviews is both achievable and desirable above soft
skills. In my experience that view may be too narrow.

I’ve interviewed and hired many people over the years for several companies,
large and small, and no matter how much advice I offer about what is actually
important when interviewing, it seems like candidates rarely listen, and
instead complain that “they don’t know what they’re doing”, as if they know
better.

I honestly think interviews are legitimately scary, and that fear comes out in
various ways with programmers suggesting their ideas for “improvements”, but
by and large the system is working, good companies are finding good people. I
know there are a lot of interviews that are stupid, and I know there are bad
companies out there. The suggestions in the article won’t fix that.

Being liked is a good way to get hired period. Being liked and being good
technically is better. Being technical and not likeable is a good way to not
get the job. It has very little to do with the occasional cases of incompetent
people being hired and paid a lot.

------
shultays
I am surprised how many people here considers take home tasks as an "unpaid
work". You are already doing other interviews with them which costs you time
as much as an assignment does. Why it becomes a problem when it is a home
assignment.

Honestly I would take home assignment over any technical interview. Even if it
will cost me 3x time. At least then I will be working in a relaxed state and
will do my best, compared to an interview where anything can go wrong.

~~~
rightbyte
Interviewing is somewhat symmetrical in that the employer also wastes
resources if they don't hire you. It's no cost to ask 1000 candidates to
submit homework.

Homework feels really unnecessary too. If the interviewer would like to see
code I have written I have a USB stick full of old university assignments and
some public projects on Github.

------
ionwake
I will never forget my interview at the 2 best fashion houses in London. Both
failed for what I still consider was a massive loss to them as I had all the
skills they needed and more, but either management or the devs had no idea. Im
not bitter for I earn much more now than I would have, it was just crazy to
see the disconnect between management and programmers, in opposing ways.

Fashion house 1: 2 guys sat me down and ask me to answer a question about some
node.js code, which took around 25 minutes to get running on my laptop. Once
it was they were hoping for progress, when it took me a few minutes to read
through several config files ( over a hundred lines each).

After 30 minutes they gave up and asked me what library I should use for a
certain task. I said I had built alot of code in that domain didn't recall
which library I used for that specific task.

Suddenly I was walked out, but not before one of them took pity and tried to
explain to me how, when you make a request you can write code which waits for
a response from a server (async programming).

I ofcourse thanked him and left.

This was after I spent 3 years developing a successful networked engine in my
spare time ( with a custom 3d engine bolted on it ) which enabled 20
asynchronous connections for a war simulation I built. They both had 30
minutes and hadnt thought of reading my CV or asking me about any of code /
experience. Just drank their coffees looked at their mobiles and waited for me
to somehow decipher their 10k line codebase. (Management had already OK'ed me
but were not around for this part of the interview and blind to what was
happening ( or the lack of it.)

To this day I dont think the engineers even looked at my CV. Just thought I
was some confused kid who didn't understand how basic network code worked.

Fashion house 2 I also interviewed at their competitor, who _had_ looked at my
CV, lead engineer was about to extend an offer, CEO walked in, not knowing who
I was, asked a casual question ( culture fit ) type, but I was unable to
answer, I had trouble understanding what he was saying. Failed interview, but
that is ok atleast I was not as offended this time as there were no quips.

The icing on the cake, was that both companies had a 20+ engineering team,
that relied on an app, which just framed a webpage.

And I cant help feeling I know the reason why.

~~~
commandlinefan
A few years back I interviewed for a software architect position at a major US
airline. I actually had experience with every one of the 20+ things they
listed on their availability description, including the “nice to haves”, some
of which was sort of obscure but I had actually done quite a bit of work with
anyway. So they phone screened me, I got feedback from the recruiter that the
phone screen went well and they wanted to bring me in for a face-to-face. I
took a day off of my then-current job to drive out there and spend nearly a
whole day (four hours) talking to them. I got word back from the recruiter
that things went great, but a week later they asked me to come out for ANOTHER
face-to-face, so I took ANOTHER day off to spend the whole day talking to
them. I got feedback from the recruiter that things went great, and I should
hear back from them any time. A week passed, nothing. I called the recruiter.
He said he hadn’t heard back from them. Another week passed, nothing. I never
heard back from them.

------
llamataboot
I got roasted for this article last week, but I'll post it here because its
completely relevant.

I think the entire dev hiring process is broken. Not because I had a hard
time, I think I had a totally normal (and slightly easy, because was okay
where I was while looking) time and ended up getting a large raise and ending
up somewhere I love...but I've been on the hiring side as well and I think
hiring signals are weak and cargo culting is rampant.

It's telling that I can't think of many other fields outside of academia that
require so much time interviewing to hire.

[https://medium.com/swlh/brief-thoughts-on-getting-hired-
as-a...](https://medium.com/swlh/brief-thoughts-on-getting-hired-as-a-senior-
coder-94f38998bb08)

------
curtis
Last time I was looking for a job (about 3 years ago in Seattle) I had a lot
of trouble getting through the initial screening to even get to a technical
interview. I didn't have a lot of luck until I started applying through
AngelList. One notable thing about AngelList applications is that there was no
HR/recruiter screening step you had to get through first.

~~~
lordnacho
Don't the firms on AL tend to be smaller firms? That would explain it.

------
andrewstuart
Coding tests are completely useless unless the company doing the assessment
can clearly explain up front their method for assessing the code.

I did a coding test once that was organised, met the requirements of the test
spec, was documented, included tests and in identified and solved an
inconsistency in the test spec.

The feedback from the employer "they didn't like your code" \- right there is
the point at which I realised that coding tests are, without a quantifiable,
systematic assessment method, complete garbage.

------
bazooka_penguin
Imo the industry should consider a more cooperative process that involves
larger real world problems with the interviewer working with the interviewee
to work through the problem, teaching them even, if need be, to get to an
acceptable solution. Big tech interviews can already run almost a day long and
the phone test is just a whiteboard lite. I feel like the face to face time is
kind of wasted on an open ended examination format rather than trying to find
out a developer's temperament, behavior, and openness in a real work
environment where they will be expected to work constructively with peers.
Given a lot of companies have separate design and behavioral interviews, with
the former probably being close to my idea already.

I just hate the technical beat stick that is the whiteboard test, feels like
going up in front of the class in data structures and algorithms classes

------
avip
Good interview method is characterized by:

1\. It hires me

2\. It can be used to unhire others thereafter

------
jackcosgrove
I have never been asked an interview question where I am expected to sanitize
noisy real world input, report meaningful errors to the user, or create a few
classes that interact in a SOLID way. (I have been asked what SOLID stands
for.) Maybe these questions are asked but unfortunately I haven't come across
them.

I have been asked many times how to solve crazy, weird problems in what is the
equivalent of a couple of functions.

The first kind of test, which I have not been given, is highly relevant to my
daily job.

The second kind of test, which is administered in every single interview, is
relevant maybe 1% of the time in my job.

I try to keep this in mind when I am on the hiring side of the table.

------
Renal
I refuse to do coding assignments for free and I think everybody should too as
well.

The problem I have with them is:

1) Malign intentions: You never know whether they are trying to:

\- Purposely waste your time.

\- Free consulting. How would this guy do this ?.

\- Data compilation. Let's see how a bunch of unemployed developers solve a
particular problem.

2) Is too easy to reject a coding assignment based on subjective things since
there are so many different ways of doing the same thing.

3) It is easy to cheat. You can easily ask/pay someone to do it for you.

And the core problem is that is too easy to ask for coding assignments.
Companies don't loose anything by asking you to spent a week doing the
assignment.

------
lowdest
Current recommendations on discussion boards for job seeking are to complete
300 medium-to-hard Leetcodes in the 60 days before your interview. This is up
from 200 1-2 years ago.

If you won't do it there are many others who will.

~~~
AnimalMuppet
_FORGET. THAT. NOISE._

If I'm not going to do a 6 hour take-home assignment for you, I'm _definitely_
not going to do 300 Leetcodes to "prepare". I've been doing this for 34 years.
That's my preparation. Either you want what I've got, or you don't.

------
pascalxus
I think most people misunderstand why they were rejected. Most people
interviewed are more than qualified for the job. I've interviewed countless
people on phone and in person, and I rarely come across a candidate that's not
able to do the job.

The real reason candidates get rejected is simply this: 5 candidates get
interviewed and ONLY 1 can get the job. This is simple math. No amount of
studying on the part of the candidates, and no amount of interview hiring
competence can avoid this outcome: there is only 1 Job. The reason for all
this is simple: a vast oversupply of qualified candidates. As more and more
engineers get pumped into the market, this problem will only get worse. You
can see from the 2019 developer survey, the ratio of 1-5 year devs vs 5-10
years, indicating the number of senior devs is increasing very rapidly.

------
shivawu
I'm surprised how much people hate take-home projects. Companies must've done
this very wrong to piss so many of us :)

My take on the comments: \- We know whiteboarding and algorithms are bad. \-
Take home assignment is better, but very few companies do this right. \- If
doing wrong, the experience will be far worse, make you never want to do it
again. \- The reason is, A. lack of transparency; B. unbalanced time
commitment, candidate vs company

On the other hand, I think we should give more mercy/time to take home
assignment. We know it's better, we know it's in the process of improving. If
we don't say no to algorithm, it'll just be there forever.

------
adamredwoods
After taking take-home or timed coding exercises from these major companies,
I'm becoming more and more depressed, compounded by the lack of any
constructive feedback.

I'm not sure all these code tests are EMOTIONALLY sustainable for a developer.

------
jdlyga
I've had some good technical interviews and some bad technical interviews. The
worst I dealt with recently was the technical phone interview process for a
FAANG company (not Amazon) that only provided a basic text editor (requiring
me to tab over after every newline) for writing full working solutions to
problems, and unhelpful and disinterested interviewers. This was a couple
years ago, so hopefully it's improved since then. But it left a sour taste in
my mouth.

------
gregrata
I wrote a book on this:

[https://www.amazon.com/dp/B07FJ6N8P1](https://www.amazon.com/dp/B07FJ6N8P1)
(the book will be free tomorrow - would love for you to give me some
feedback...)

Lighter-weight then this paper - just my experience in using different kinds
of tech interviews, and what I found that worked the best for my team and
company.

Some key points:

\- Interviews should be as close to what the candidate will do in the job - if
they'll be writing a lot of code, that's just basic algorithms - on a
whiteboard - then whiteboard interviews are perfect. If they will be doing a
full project and interact with others as part of that project, then do
something more like that (For me, that's a take-home - with an emphasis on the
interaction part, and how they go about creating software... not coding).
Treat it like a project, not an interview quiz question.

\- If doing the takehome, respect peoples time - it needs to enough be close
to something they'd do in the job, but something that can be done in a handful
of hours (and NEVER treat it like getting free work. I personally would love
to be able to do a paid take-home, but haven't had the budget for it) The
total expected time of the take-home + onsite should be able what they do for
just a full on-site

\- Understand that not everyone will have time to do this. Have a backup (my
backup is "Project Day", which is on-site, but still about creating software)

\- Try to do the same one for all candidates. At my last company, 80+ people
ran though the same take-home. The team really started to get a sense of a
good result and bad result.. and not JUST on code. What questions did they
ask? How did they go about driving the project? What tools did they use?

\- I did catch a few people cheating (after 80+, the code was out there, so
not hard to cheat). LOOKING at someone else's project for this was ok (if you
read the book, you'll see why). Outright copying was not. Part of the process
is a friendly code review after the project is done - if the candidate wrote
the code, they'll be able to talk to it, and have ideas of how to improve it.
If they can't do that and don't see to know the code, they probably didn't
write it... which was painfully obvious for those that tried to cheat.

Do what works best for your team and company. This worked best for me; I have
yet to see whiteboard interviews be a strong indicator of someone being a
great fit for a team, but I was able to build a great, happy, very productive
team using this method.

------
iMage
I have yet to enter the workforce, but as someone who has done a bit of
programming for fun and really liked programming-interview type websites I
think I'd be decently prepared for a whiteboard interview.

The thing is, I have barely any (read as: no) software engineering knowledge
and don't know how to build any sort of programming _product_.

------
dep_b
I had quite a nice interview for a contractor position building a larger
fairly well-known mobile application and they surprised me by giving me one of
their stories and asking me to ask questions about it (like: "where are the
comps?", "is this also supposed to work offline?" and so on). That was so
refreshing.

------
jmharvey
I'm sure I'm not the only one here in a position where I can re-shape my
company's interview process. And it's loud and clear in the comments here that
people are unhappy with the status quo. So, if you were making a hiring
process, what would you ask candidates to do?

~~~
carapace
> if you were making a hiring process, what would you ask candidates to do?

Review code.

It would be at least a few pages, in the language they would be working in,
with a few bugs that you know of in advance. Depending on what the code does
and the particular bugs you introduce you can get a pretty good idea of the
candidates' comprehension of the things you need. (Bonus points if they find
bugs you _didn 't_ introduce.)

One problem with this is that both the code itself and the evaluation of the
candidates review have to be done by sharp folk who know what they are about.
Otherwise GIGO.

~~~
cableshaft
I'll second this. This is mostly a copy paste of my comment on another one of
these interview topics:

"One of my best interview experiences was exactly that. The interviewer handed
me a printed out class and said "tell me what this does, any mistakes you see,
and any little improvements that you think could be made."

I got the job and later confirmed it was a class that was actually in the
software I would be working on, not some toy class he came up with.

He also asked me a handful of technical questions and had me go over some
source code I brought in, but that was about it. At one point he even said, "I
know enough to know you can do the job, but now I'm curious what you really
know." And asked me some no pressure really low level questions. When I said I
didn't know the answer to something he'd spend a couple of minutes explaining
the concept to me.

I walked out of that interview having learned a few new things about my field.
A couple of them have stuck with me over a decade later.

And the guy was a grizzled veteran who was the lead on some massive mainstream
video games I pretty much guarantee you've heard of. He used to code them in
Assembly, even. He's probably the most knowledgeable programmer I've ever met.

I've never had anyone try going over actual code with me since, in probably a
couple dozen interviews, and I don't understand why. It seemed very
effective."

------
chovy
[https://thedailyshitter.com/heres-a-rediculous-interview-
que...](https://thedailyshitter.com/heres-a-rediculous-interview-question-i-
got-today-they-gave-me-48-hours-to-complete-how-nice-of-them-s/)

------
11235813213455
As a fan of algorithmic problems and websites like leetcode, I'm totally fine
with this kind of interview challenges, it's a good way to select candidates,
and anyone can prepare for it

~~~
TrackerFF
But is it any good indicator on future work performance?

~~~
username90
Yes, not sure why so many believe otherwise.

------
icedchai
Up until the 2009 or so, tech interviews weren't like this. You'd show up, get
asked a few easy questions, get a feel for culture, BS a little, and that was
it.

------
vrt77
Curious to know if anyone has had any remarkably good interviews? So good that
you'd actually use the approach with candidates you're interviewing?

------
vrt77
Curious to know if anyone has had a "good" interview? So good that you'd
actually apply that approach to candidates you're interviewing?

~~~
lacker
In my experience, most people who are hired by Google or Facebook consider the
interview process to be good, and generally approve of applying that same
interview process to find new candidates.

However, that set of people is outnumbered by the set of people who applied to
Google or Facebook and got rejected.

~~~
shivawu
I was hired by these big company before. I don't consider them good. I just
know how it works.

Probably don't want to go through this process again, unless there's some
amazingly good opportunities there.

------
tictoc
Am I still hirable as a developer past age 35?

~~~
cr0sh
I'm 46 and still employed as an SWE - got my current position 3 years ago. The
key is to not let your skills stagnate, and to always be playing with
something new - even stuff that you may not think you'll use in your career.
For instance, for the past several years I've been playing with machine
learning with a focus on self-driving vehicles. Do I think I'll ever get a job
working in that field? Not likely, but the skills I have learned may be useful
down the line (and personally, I've been pursuing such an education for my
hobbyist aspirations).

------
aussieguy1234
Given the choice between a technical or culture interview, I'll take the
technical one any day.

For those that complain about them, are you really as good as you say you are?

I support coding challenges, as long as they're reasonable and won't take too
long to complete. If you'd spend an hour doing an interview, wouldn't it be
reasonable to spend the same amount of time on a coding challenge? The best
ones are done during the interview. No more time wasted.

------
est
Hiring is no longer about qualification, but a bar for revenue distribution

------
rs23296008n1
There is no talent shortage except for corporations favoring low effort hiring
using low effort puzzles. They see people as cheap so why bother investing in
hiring. One person is as good as another, right?

That first question in the paper is an indicator that I literally don't want
to work there. Their culture is probably toxic, full of bro coders and likely
infested with poor time management and politics. That's my rule of thumb and
I'm sharp and harsh since I've seen enough to make this assertion and won't
even negotiate on it.

The reason they showed me a puzzle is they want interviewing cheap. But I'm
not cheap. And I'll see right through it and just see a messy company. No
thanks. I have too much experience with messy companies and can spot them from
a single question. I'd rather work with professionals with real problems and
no time for nonsense.

Google etc can't hire someone like me because I interpret stupid puzzles as an
indicator of poor work environment. I don't write this out of some sense of
superiority: I'm just tired of the correlation between puzzles and
environments that are just plain bad. The mentality of people who like
pointless puzzles is not one I'd like to work with. The irony of my job being
based around production issues that involve uncertainty and require novel
solutions is not lost. I work with smart people. Do people on the outside
really think we would play with wooden or toy puzzles because we"re
"technical?" None of us do.

I get my contracts through referrals so interviews are mostly now just "hey
are you available in a months time and can you also do X" followed by "do you
have a github for this kind of work?" Then a quick 15-30 minute interview with
no idiot puzzles. Mostly to expand on experience to explore some portfolio
piece. Big corporations can't do this kind of interview. Their hiring is
broken. That is why they have thousands of candidates and still shout about
talent shortages. I've been interviewed a few times and I usually get to a
point where I say "sorry but I'm not happy with the environment you are
presenting" then I politely cancel. I can't be alone in this experience. I'm a
blip in their radar that rapidly fades away. They probably see me as poor fit.
Good.

Lower your tolerance. Raise your expectations and actually judge them back.
They are presenting their corporation in the best light possible. So using
puzzles is their best light. Ouch.

Any code or project example that an interviewer presents to you are
demonstrations of how their best practice development process works. Best or
worse or an examination or discussion of why not either way. Evaluate them. If
its "from scratch" then they simply do not use libraries and suffer from "not
invented here". If its not commented, they hate maintaining code and they want
you to fix their mess. Is the time limit too short by your experience? Then
they expect miracles and likely won't pay for it either. What about a 8 hour
home project as part of the pre-interview that you could probably sell? They
expect free labor and no compensation for it.

These are assumptions but when firmly applied your opinion will be suitably
sharp enough that puzzles no longer seem so reasonable. Judge the interviewer
on what they present. That code will be production ready or they will ask why
it isn't. Each question is an example of how they specify real problems. Judge
them on their method. Is there enough information? Why not? How is that
acceptable?

The interview process is two way. Anyone who says otherwise is someone you
want to avoid. They are likely toxic. Don't work with or for anyone who thinks
interviews are one way. If the process is not win-win then avoid because other
nasty surprises are hiding in your near future. My personal experience shows
genuine horrors await if you stay.

Why is that particular technical question so bad? Because it shows the answer
will not be production ready and the culture around it accepts that. The
design specification is indicative of bad design. They even showed the shape
of their preferred answer.

Consider the implications: what was missing from the question? Why would I
care about what was missing? What is the maximum run of numbers it can search?
A million numbers? How often does this code run? Is it part of an interactive
flow? I hope the user has coffee and a lot of patience. When does it time out?
No answer in the design. It never does because it is not specified. The
interviewer likely won't even answer that question. No context and you now
seen as incompetent for asking. Instead you can ramp up the assumptions: So
the entire system hangs as it searches. You could also say that the company is
likely bad at operations and they don't specify their problems clearly or
thoroughly enough. They have multiple mysteries in their systems they just
can't solve. Systems fail for no reason and asking why is "being difficult".
What a painful place to work. No thanks.

I can make these assumptions because the question they showed me is seen by me
through the lens of a production example. An example of a problem I'd likely
see if I accept their contract. This is an inter-view. Two views. I expect
them to show me a serious example of how they would frame a problem and how
they would specify the preferred shape of a solution. They didn't show me a
toy problem because they wouldn't want a toy solution. That would be
disrespectful: so what was presented is a serious question to be solved. It is
to act as a demonstration of what I would be presented with and then they want
to see how I'd meet and solve it. Now look at the question again. Its so
simple. Just answer it. Ignore everything. It will be fine. Now clean up our
codebase. Have fun with all those puzzles. We need it fixed in 30 minutes, all
200000 lines.

Oh well. Back to work. I've got money to make and this system is 1.5ms too
slow, and that is costing the business 100k per month in lost opportunity. How
would I solve this? Perhaps a bubblesort algorithm I saw in an interview
question awhile ago might help? Thats fast and best practice isnt it? Perhaps
I could write it from scratch... on a whiteboard. With only 5 minutes. Sounds
great doesn't it? Should a company bet their livelihood on that kind of
decision making?

Interview carefully. You could end up working with these people.

------
unnouinceput
Before going freelancer route I was like everybody else. Send resumes, go to
interviews when invited, get whiteboard crap. Usually it resulted in 50% times
invited to interviews and getting offer 75% off those interviews. Then a hard
time came (2000's EU crisis) and the market was drying, with hundreds of
applicants even at small firms that were hiring. So I changed the way I was
going about. Whenever a hiring was happening instead of sending a resume to
the office@whatever.com and hoping for the best I went proactive and digged
further for a phone number, called about their address and went in person
there pushing until I was in front of a technical leader that was in position
of power to hire. I avoided HR entirely and when in front with that tech guy I
asked for real problems that they either have or had and to show him my way of
thinking hunting for bugs in front of a PC. This resulted in 100% hire and I
kept doing this for the next several firms I worked for. I got to work for
Alcatel and Siemens this way. No HR drones, no whiteboard, just good old
coding in front of a competent future co-worker/team leader.

Alcatel tried to kick me out with security. I went out on one door, entered
another in next 2 minutes. I argued with them, I voiced that I will keep doing
this until I get a tech guy to interview me. When head of HR came eventually
and told me police is on the way I said "so until they arrive can I get that
tech guy to do the interview? Because I will pass it in 15 minutes, that's how
awesome I am". That line made him reconsider me and guess what, I was hired.
My point is if you know you can do the job just push it, regardless of
obstacles.

Siemens punished me for this type of behavior by interviewing me for 8
straight hours. No bathroom breaks, no eating or drinking this time, just
interview with one manager after another, all with hiring power. First of them
was actually the head of the entire HW department and he made sure I
understood what is going to happen. Later on I found out who he was, and on
hierarchical ladder hes was the boss of the boss of the boss of my boss (team
leader -> immobilizer division -> BCM group -> HW department). After 6 hours
came a group leader (BCM -
[https://en.wikipedia.org/wiki/Body_control_module](https://en.wikipedia.org/wiki/Body_control_module))
that was actually in need for guys in one of his teams and I finally got to
coding part and at the end of those 8 hours I got a contract to sign and to
start next Monday (this was happening on Friday). Their punish made sure that
I was actually that good as I was bragging at beginning and that I was willing
to do the grinding required for the job. This way I got to work on immobilizer
division (this was an embedded SW position). My point is that if you brag,
make sure you also can do it, as harsh as it can be.

------
tbyehl
2-Column PDFs: Writing is broken.

