
How I Learned to Stop Worrying and Love the Job Hunt - rbanffy
https://blog.stephanbehnke.com/how-i-learned-to-stop-worrying-and-love-the-job-hunt-in-toronto/
======
jorblumesea
> While they said I shouldn't spend more than a "couple of hours" on it, it
> took me pretty much one and a half days to finish.

Basically every take home assignment. Half the time someone doesn't look at it
anyways. In theory everyone should love this as it's supposed to be practical
real world work vs the mostly academic hackerrank problems. In reality it's
usually a waste of time. Sadly if someone has a take home like this I usually
skip them unless it's very basic.

~~~
paul7986
Yeah I recently was asked to redesign and develop the following site for a job
prospect.

[http://www.publicsafety800mhzinterference.com/CTIAWeb/](http://www.publicsafety800mhzinterference.com/CTIAWeb/)

My redesign... [https://goo.gl/5LGvCQ](https://goo.gl/5LGvCQ)

I never heard back from the company! It was 3 days of work and that was only
my 1st attempt. I guess it sucked horribly....

~~~
murukesh_s
Oh may be they are not the hacker news reading type :). Some large enterprises
still wants slideshows and case studies with a link to white paper downloads
filling the home page with less reference to what exactly you are doing!

~~~
paul7986
who knows yet the site has one purposes only to report interference and they
do have a button on their homepage to do that. Thus, I empathized the main
purpose with as little text as possible and a bright purple button.

It would have been nice of the company to get back to me, but yeah Im unlikely
going to ever do post interview homework again.

~~~
murukesh_s
hmm, it sucks when there is no proper follow up. I guess it's the competition
nowadays.. companies get flooded with resumes.

------
twic
_When the inevitable question "What are you most proud of?" comes up, it's
your turn to impress._

This is my biggest weakness. I haven't worked on anything where I made a
substantial contribution that I'm proud of. I've been working as a programmer
for nine years.

Three years in a consultancy implementing solutions based on a third-party
framework. The framework was terrible, so the best we could do was to paper
over its cracks. We made things much better, but it was still very poor
compared to normal software.

Two and a half years at a small company, working on their legacy codebase. We
did innumerable small cleanups, bodged in new features, and did one bigger
architectural change. Even the big change was the sort of thing that would
only take a week in a sane codebase.

Two and a half years in an agile consultancy. Many short projects, mostly
building technically rather simple things, but focusing on teaching the
clients how to be better at software development. The one technically complex
thing we built was mostly only complex because some plonker settled on a
microservice architecture using a new messaging framework before I took over.
I think we did a good job, but I can't justify the central design decision of
the project!

Those companies were all agile, with pairing, collective code ownership, and
self-organising teams. Even where we did something good, it wasn't my work
alone.

One year so far in a hedge fund. I've built several small tools and features,
most of which haven't ended up being very useful. The two bigger things I've
done have mostly been about wrapping sophisticated third-party libraries in an
application which integrates them into our environment - I'm a plumber.

Everything I've done has been what seemed like the most useful and sensible
thing to do for the client or company at the time. None of it helps in
interviews.

~~~
l_t
Whether or not you feel proud about them, I would suggest trying to look at
some of your accomplishments from a different perspective to see how they can
actually be impressive. Things like cleaning up terrible legacy codebases are
valuable and reflect two positive traits, to me: Willingness to get your hands
dirty, and the sense to distinguish between "good" and "bad" code.

On the other hand, if you really just want to build more "pride-worthy"
things, I think you really just need to prioritize that desire more. Making
something you're proud of often means going beyond what's mandated by "useful
and sensible". This might sound a bit inane, but I would seriously consider
asking yourself, before you start your next project(s), "How can I make this
project something I'm proud of?"

~~~
sngz
I'm in a similar boat as OP, every thing you say is true and I've tried
selling myself that way, but in the end when you're trying to break out of
that industry and work for a startup or different kind of company not all of
them can appreciate that type of work. I've gotten rejected many times with
the feedback that I was great but other people interviewing for the same
position has more relevant experience.

~~~
l_t
Good point. I imagine most smaller companies are specifically looking for
people who can build things in a self-directed environment using the latest
tech. Maybe it's only the larger, older orgs that care about legacy code
wrangling.

In my limited (n=1) experience with startups, I'd say they take a _very_
different approach to recruiting and should be "courted" by the applicant in a
slightly different way. Relevant experience becomes more important. IMO,
startups particularly care about:

1\. Can the applicant hit the ground running? Startups don't want to hire
people that need training, because they want them to be productive ASAP.
Startup teams have very little slack, so individual productivity is more
important. For example, I started working at a large company and had 3 months
training before I touched any code. Then I went to a startup and pushed a
bugfix to production my first day. The expectation is quite different. My
recommendation would be to work on some side projects that use common startup
tech stacks (Ruby, Node, Python, etc.) so they know you're familiar with more
than just Java or whatever, and emphasize how you're a quick learner that
adapts easily to different situations.

2\. Does the applicant offer a specialization we need? Startups are always
looking to increase the quality and range of their technical skillset. If you
have a relevant specialization that their engineering team is lacking, like DB
admin, security, hiring, management, distributed systems, AWS, etc., the
startup will be much more inclined to hire you. Recommendation here would be
to try to dig into some topics and gain expertise in your current company that
can carry over. Alternatively, something like getting an AWS certification,
publishing blog posts about relevant topics, etc.

3\. Is the applicant a culture fit? For example, usually startup employees
should be internally motivated, autonomous, good communicators that enjoy
programming and think of development as a vocation instead of a chore. You
shouldn't have to be exactly the same as everyone else, just show that you're
likeable, flexible, and can do good work without a manager.

(edited: Added some additional clarifying points).

~~~
sngz
#1 and #2 is basically why me and many others have been stuck in the same
industry working on big enterprise apps and legacy technology/code.

------
KKKKkkkk1
I interviewed with Google. All the interviews went well, and in one session,
one of the hiring managers was so surprised by my solution he had to look it
up on Wikipedia. Next week the recruiter calls me--"We're not forwarding you
to the hiring committee. I can't tell you why. Contact me ≥ 1 year from now if
you want to try again." WTF Google?

~~~
dota_fanatic
Quoting from a recent post,
[https://news.ycombinator.com/item?id=16023589](https://news.ycombinator.com/item?id=16023589):

> _" Project Oxygen shocked everyone by concluding that, among the eight most
> important qualities of Google’s top employees, STEM expertise comes in dead
> last. The seven top characteristics of success at Google are all soft
> skills: being a good coach; communicating and listening well; possessing
> insights into others (including others different values and points of view);
> having empathy toward and being supportive of one’s colleagues; being a good
> critical thinker and problem solver; and being able to make connections
> across complex ideas."_

Who knows why you weren't chosen, but the above quote probably has a clue as
to a potential why. Coming away from a failure and concluding "WTF
$OTHER_PEOPLE" might have something to do with it. Sorry for the disappointing
outcome; your technical skills can take you far, so don't lose hope.

~~~
KKKKkkkk1
I don't see what this has to do with Project Oxygen. They gave me only one
soft-skills question in a five-hour session. It was straightforward and I had
no indication they were unhappy with my answer. My WTF is referring to the
fact that the outcome is at 180 degrees from the feedback I received at the
time.

~~~
FLUX-YOU
They're trying to say Google's more likely to reject you for a soft-skills
deficit, but they're incorrectly drawing any conclusions from "I can't tell
you why". It could have been anything from discrimination to a simple mishap
of hiring for a position already filled and the recruiter/interviewer saving
face.

~~~
twblalock
Most companies won't tell you why. There is no upside for them, and
significant downside if they reveal something that could open them up to a
lawsuit.

It's easier for companies to have a blanket policy of never telling than to
educate everyone involved in the hiring process about the complex and ever-
changing realities of employment law, discrimination law, protected classes,
etc.

~~~
gozur88
Yep. I've never worked for a company where we told people why they didn't make
the cut. Heck, the person who delivered the bad news didn't even know - we
selected the candidate we wanted (or none) and told HR to make the rest
happen.

In most cases there's no answer beyond someone else seemed like a better fit
for the position. How would it help to know you would have got the job if only
this other person didn't apply?

~~~
l_t
Well, it depends. At my job, we do give feedback to all our candidates.
Basically, we condense our notes about the candidate down to the most
important points and send it to them. We've found that candidates appreciate
getting this kind of feedback because:

1\. It gives them a kind of closure and treats them with respect.

2\. It can help them improve for future applications.

Usually, the reason is not "Someone else is a better fit". We're not just
trying to fill one position -- if we find good engineers, we'll hire them.
Usually feedback is related to stuff that came up in either the coding project
or the interview. It helps people in the same way that code review helps them:
by giving them an opportunity to learn and improve.

~~~
gozur88
>Basically, we condense our notes about the candidate down to the most
important points and send it to them.

This is an _excellent_ basis for a lawsuit.

~~~
l_t
How so?

(edit: I wonder if we're talking about slightly different things here. The
"notes" I'm referring to are primarily code commentary -- the same kind of
material we cover in pair programming. As far as I know, we don't share notes
about our internal decision-making process, which perhaps is what you're
talking about.)

~~~
gozur88
Ah... I misunderstood. I thought you were sending them notes on your
impressions of the candidates themselves.

------
auggierose
> I got a challenge from a company and due to my prioritization and
> commitments, I wasn't able to work on it before the deadline. I wrote them
> and explained the situation, telling them that I cannot interview with them
> any longer since I'm too busy with other companies. > To my surprise, they
> offered to fly me in to their New York headquarters straight away to meet
> the team. I was baffled.

People just want what they cannot have. Applies in all sorts of situations.

~~~
TipVFL
Yeah, the less you want it the more they want you. During my last job hunt I
got an offer, and while I was considering it another company contacted me. I
told them I was deciding on another offer, and I wasn't interested unless they
could beat that job offer in 48 hours. That same day I had a phone interview,
came into the office, met the team, and negotiated the offer.

I wish it was always that easy.

~~~
fencepost
Company A had already interviewed you and liked you enough to offer. If
Company B can hire you instead they've possibly gotten a free ride on the
"technical qualifications" part of the interview process. The fact that you
have an offer means you've already passed a lot of qualification checking from
someone.

~~~
gaius
_The fact that you have an offer means you 've already passed a lot of
qualification checking from someone_

But if you already have a job, that’s the same evidence isn’t it? So why does
anyone need to do a technical qualification interview after their first job?

~~~
expertentipp
If one already has a job means one perhaps passed the technical interview but
long time ago and meanwhile could become lazy incompetent bum;) Getting a
fresh offer means one is back in shape, a competence somehow transferable it
seems. Just my divagation.

------
expertentipp
> I applied to 14 companies, talked to 8, interviewed at 5 and got an offer
> from 3.

That's very good success rate, can anyone confirm similar results? Over here
(central EU states) it's more like:

>50 --> ~30 (good match they want to talk and ask for salary requirements at
this point) --> ~10 (they could pay if you are "REALLY good" i.e. child of
Knuth with Torvalds) --> 0-1.

The market is flooded with dirt cheap Russians and Ukrainians, even
Americans/Canadians for some reason desperate to put their foot in the doors.
Asking for anything above 60k EUR gross annually pretty much guarantees 0 at
the end of the pipeline. Big 4 are so capricious, demanding, and time
consuming (while still paying local salaries + 20-30% max) that it's better to
not bother with them over here.

~~~
vladd
I'd recommend to be careful when mentioning nationalities together with
diminishing words ("dirt cheap") - even if it's not discrimination, it can
impact your judgement and its validity.

For example, if you would have said "the market is flooded with dirt cheap
programmers", the next question would have been: are the competent, therefore
really valuable from a value per dollar perspective, or not? Once you mention
their nationality, the reasoning goes elsewhere and you don't make your point
(you do not follow-up on why they're dirt cheap, how this connects to their
quality of work and why it causes the 60k cap).

~~~
expertentipp
Whether you like it or not this is the migration dynamics in this part of EU.
For Russians/Ukrainians it's geographic proximity plus salaries higher than in
home countries. Many Americans/Canadians idealize this part of EU (Germany in
particular) as some kind of promise land, eventually have romantic partner
over here. All of them are in volatile and vulnerable legal situation (e.g.
visa depending on employment contract). Either way most of the times I end up
visiting the company I talk with an American, Ukrainian, Russian, and a local
national. There are quite some Romanians as well, but they emancipate quickly
(Romania has been EU member since recently).

~~~
purity_resigns
As an American that took a substantial pay cut (taxes add to the pain) to get
into Germany, this sounds about right for my experience. I came over mostly as
a cultural thing, and salary was less of a concern.

I work with a few Canadians as well, and they didn't have access to the same
salary levels back in North America that Americans do, so salary is less of an
issue for them coming to Germany.

------
dvt
> Know complexity and scalability: Every time I had to code something, I was
> asked about the time and space complexity as well as whether I can simply
> make it more efficient. Now and then, I was also asked what would happen if
> the input became gigantic so it wouldn't work on a single machine anymore.
> It's crucial to have answers here.

I was interviewed by a startup a few years ago (not naming names as they might
be lurking HN) and they asked me exactly this kind of question: can you build
scalable systems, what's your experience with tons of people hitting your API,
and so on and so forth. I was thinking to myself "holy shit they must really
be blowing up" only to find out 15 minutes later in the conversation that
their API was being hit like 200 times a month.

~~~
yeukhon
This is “grill you on everything” kind of interview. Open discussion on system
design is IMO a really cruical round. I am not saying the candidates have to
have years of experience in scaling - I doubt most applicants have. FWIW, the
application I built for my CS department when I was an undergraduate was
getting at least 10-20 times of that amount at peak every week (probably
hundreds per night) as assignments were due. We were fine on a single server
running three vagrants - one for main backend, two for grading assignments in
a sandbox.

Shipping MVP is really crucial for a startup. Don’t build a mega-internet
scale setup. Yes you can start using AWS and takes advantage of the basics
scaling features, but there you go - talk about how to leverage those services
to make scaling less a hurtle in the long round. That’s what I want to hear as
an interviewer.

I want to hear about trade-offs and ramp-up. Picking the grading application I
worked on, as the candidate I would want to know a high-level view of the
stack, and try to identify and address shortcomings with the interviewers
together. System design round should feel like a collaboration, whiteboard
“pair-sketching” (analogus to pair-programming”. If that was not your
experience, sorry.

Anyway, point being when there is a take-off, I want to be sure my coworkers
and I have good intuitions and ready-to-use knowledge to keep our product
afloat. More importantly, we want to start thinking about scaling,
availability, fault tolerance and all the big words now. We don’t need a
manager walk by and ask “so what should we do today team?”

Everyone should be proactive. That should be the point of a system design
round. Much of that round shoukd be spent on questioning and then answering
back and forth. The interviewer SHOULD be talking too as much as the
candidate; it should not feel like giving a talk or giving an oral read of
your PhD thesis. If most of your interviewers onsite behave like an exam
proctor rather than a peer, consider the culture a bit unfit for yourself
(take offer now and do another hunt is up to you). This is IMO the best
“culture fit” test both sides can use. Don’t judge on the elegancy of the
solution (big plus for clever soltion), but reward points for how pleasant it
is to be in a room working together.

~~~
lovich
That would be wonderful is interviews were actually done with the idea of
finding out if a prospective employee was proactive or not, but most
interviews are just the interviewers going off a checklist of questions they
think they need to ask because they are effectively in a cargo cult.

Take the questions on scalability for instance. I personally don't have any
experience with scaling on requests, my highest demand was an application with
<5000 users for the entire client base. I want the experience so in my last
job hunt I apply to a number of jobs that I know get a lot of traffic. I tell
the recruiter the chance to get experience in that skill set is why I am
applying. The recruiter tells me the desire to learn is all they want. I get
to the interviews and have the same talk with the engineers and the same
response. They then ask me system design questions and I answer as best as I
can along with bringing up approaches I've heard of but don't have experience
with. Interview ends and the recruiter tells me they are passing because I
don't have the experience in scaling they want. I had this happen with
multiple companies.

Not wanting an employee without that experience is perfectly fine, but why
waste everyone's time when an interviewee tells you from the get go that they
don't have one of your must haves? When resumes are passed over for implicit
signals like which school you're from, unusual names, spelling errors, etc,
why go through all of it? It's because most companies and most people
interviewing have no idea what they want or what they are doing and are just
copying approaches they've seen before.

It's the same problem that gets you interviews where they want you to reverse
red black trees on a whiteboard but the actual job is just implementing CRUD
api's, or building jobs that run an algorithm that is basic algebra once a
day.

At this point a "grill you on everything" interview for any position that's
not director level or someone getting paid double the market, because they
actually need you to know everything, is just a red flag that the company has
no idea what's going on and you'll have better luck making the interviewers
like you as a person than actually learning all those skills

~~~
ryguytilidie
"most interviews are just the interviewers going off a checklist of questions
they think they need to ask because they are effectively in a cargo cult."

Recruiter here. I interviewed with a company ~9 months ago and they asked me
"how do you choose whether to hire for experience or pedigree". I gave a bunch
of reasons why you might trade off one for the other and the interviewer made
a bit of a sour face. He then asked me "is there another way to phrase what
you're saying?" I said "Well, the way you make those tradeoffs depends on..."
and he cut me off and said "thats what i was looking for". When I asked what
he meant, he said that the answer on the sheet was "It depends" and he wanted
me to literally say those words.

I didn't continue the process as I can't imagine the type of culture that gets
people to that point of disengagement.

~~~
lovich
Unfortunately its the kind of culture most companies seem to get. The few that
don't have that culture, like early Facebook or google, can skyrocket from
getting actual talent, but even those companies start to devolve into the
scripts once they get large enough unless there is a concerted effort to avoid
it.

People are animals and animals are lazy so the path of least effort gets
chosen the majority of the time, and that means going off of predetermined
scripts.

------
reificator
> _Explain what [ "123", "456", "789a", ...].map(parseInt) returns_

I understand the frustrations with questions unrelated to the job you'll be
performing, such as asking about balancing b-trees when you're applying to
make frontend CRUD apps.

But trick questions bother me so much more. This one in particular is
something you'll probably encounter if you do frontend development in a
functional style for long enough, but it's still a trick question at heart.

~~~
reificator
I forgot to mention, the worst part about trick questions is that you never
quite know what's meant to be a trick question and what's not, and handling
that gap can be extremely tricky.

For example:

>> _Which C++ data structure would you use to store a sorted list of 5,000
integers, a linked list or a vector? The values will be randomly generated one
at a time, and after inserting an integer the list must be in a sorted state._

> I would use a vector because of its compact and linear nature. It would-

>> _Sorry, the correct answer is a linked list. With an array if you want to
insert something in the middle it 's going to require you to move all elements
that come afterward. Linked lists on the other hand have a constant time cost
for insertion and removal._

> But the cost of constant cache misses while traversing the linked list are
> going to significantly outweigh the cost of shifting the array by one space.
> And on top of that the 3-4x overhead is going to push nearby nodes out of
> the cacheline.

>> _I 'm not convinced._

> We could benchmark it together, or find an existing benchmark online.

>> _We 're on a strict schedule here, so let's just move on to the next
question._

> No thanks, I've realized I wouldn't be a good fit for this position. Thank
> you for your time and best of luck.

How do you handle a situation like that, where you're asked a trick question
but the interviewer doesn't know the trick? It's difficult to find a balance
between assertiveness and argumentation.

Do you insist on giving the correct answer and backing it up with facts? Or do
you tend toward conflict avoidance, taking the loss on one question and hoping
to make it up on the rest?

When you're on a team, you can plan your approach based on the personalities
and culture around you. But in an interview you usually have minutes of
experience talking to your interviewer. Would they be impressed at your
knowledge, confidence, and assertiveness? Or will they perceive your
confidence as egotism, your assertiveness as an issue with authority, and your
knowledge as incompetence?

The correct answer varies based on the interviewer's personality and your
tactfulness, but realistically you need to either stand your ground or walk
away. If you acquiesce, you're setting yourself up for a miserable work
environment.

~~~
blowski
“It depends on how often the data will change. A linked list will be good for
[situation x], but a vector might give better performance in [situation y].”

I’d give more points for that answer because it shows a deep understanding.

~~~
reificator
I'd agree with that in the general case, but in the situation as given I think
there's not much benefit to using a linked list.

Perhaps ergonomics, but that's subjective and relative to the codebase in
question, and I tend to prefer the ergonomics of a vector personally.

If you have an example of why a linked list would be a better choice in a
given situation, I'd love to learn more.

Here's an example performance graph, but I encourage you to try it yourself if
you're curious:
[https://www.codeproject.com/KB/cpp/340797/linux_insert1.png](https://www.codeproject.com/KB/cpp/340797/linux_insert1.png)

~~~
blowski
I’ll assume you’re right as I have no knowledge in this area. My suggestion
was just how I would handle the question in an interview.

~~~
reificator
I'm in a much more dangerous position: I have a little knowledge in that area.

------
skrebbel
> _Nothing. Happened._

> _Even one company where I seemed to be an almost 100% fit didn 't get back
> to me._

What's wrong with these hiring managers? I mean, I thought software engineers
were super-much in demand. Every founder interview I read includes a complaint
about how hard it is to find good coders. These companies publish vacancies,
and then don't even respond to well-fitting applicants (I'm just going to
assume that the author is compentent). Is this typical? Among "startups
between 20 and 100 employees"?

~~~
ikeyany
American citizens are expensive, comparatively.

~~~
skrebbel
??

This article is about a German citizen looking for a job in Canada.

------
minimaxir
I'm currently working on a postmortem on my recent data scientist job hunt.

As I found out during my job search, the new 2017 trend for tech hiring is
companies giving _both_ a take-home assignment _and_ an algorithm test before
the on-site. And it's _never_ a weighted average where doing well on the take-
home can account for a weaker algorithm performance; it's always pass/fail.

This gets very annoying very quickly when you keep passing take-home
assignments (that has questions actually related to data science) easily but
fail the subsequent Leetcode-esque algorithm questions that aren't related to
data science at all.

~~~
WWLink
Well yeah dude, our corporate social media mobile app requires the best of the
best! We have a $4M Stage 3A valuation from our VC and were in YC round 6 last
month! Our team of 6 MBAs and 1 programmer absolutely requires the most
prestigious of programmers! You think I'm really going to hire someone that
screwed up a simple if statement?! PFT!

~~~
barry-cotter
Your startup bullshit is off. Stage 3A isn’t a thing. It’s seed, A, B, C &c.
YC doesn’t designate cohorts by number but by year followed by W or S, or
Winter or Summer. You’re not going to get into YC with a team of six MBAs and
one programmer and if you got in with a team of two MBAs and a programmer you
will not end up hiring more MBAs before more programmers.

~~~
arkades
Hyperbole is a type of humor.

------
bjornlouser
I'm in my final year as CS major and was really excited about graduation.
After reading this I think I'll switch majors.

Why didn't anyone tell me that I will get treated so poorly just ten years out
of school?

~~~
kemiller2002
In all honesty, it's not that bad. Some places are like how he described, but
there are far more that are not. You want to work at a Google or Microsoft,
yeah you'll probably run into something like that, but most places you won't.

In reality, unless you are building truly building a system that needs to
scale to a massive size, a company won't be looking for that information.
Don't fret it.

Of course this is a matter of opinion, but others have said being an
engineer/developer/programmer/whatever kinda sucks. I disagree. I think it's
the coolest job in the world. I highly recommend not switching until you've at
least tried it at a couple of places. There is always something new to learn
and to try.

~~~
jnbiche
> In all honesty, it's not that bad.

It absolutely _is_ that bad. If you've not had a shitload of experiences like
this, you've been very lucky or very sheltered by an unusual selection of
target companies.

On the other hand, I totally agree that being a developer is a very cool job.
It's totally worth it, but the hiring process sucks and only seems to be
getting worse.

~~~
icebraining
Maybe Europe is different, but I've interviewed in two different countries and
I never had this experience. There were at most short, easy technical tests
and a few open-ended questions about my past work, but nothing like this.

------
skizm
My problem is fitting hour long code screens in between 9-5. I don’t want to
take a day off work, but also can’t exactly do it at work... what are you
supposed to do when you need to take one of these for every company you
interview with?

~~~
myth_drannon
Bring your laptop to work and take a longer lunch break in some quiet cafe.

~~~
minimaxir
Most code interviews require you to take a phone call, which is not polite to
do in a cafe.

------
paul7986
I’m in the mid Atlantic area and after reporting my female colleague’s
harassment and then later finding myself harassed and pushed out i am
surprisingly having the damnest time finding my next job. I’ve been a Front
End Designer/Dev for the past 7 years and always got jobs quickly. Now I’m
wondering if it’s my age(42.. though look young for my age I am told) or these
Govt IT jobs I’m going for my previous peers are talking negatively about me
in circles?

It’s been crazy tough after 25 phone or in person interviews!

------
epx
Founding a company sounds easier in direct comparison.

~~~
s3nnyy
I am a tech recruiter and former programmer located in Zurich. Some companies
treat applicants like shit nowadays. Especially the "startups" and younger
ones. The best company I work with is 30 years on the market and they treat
applicants like half-gods. Their interviews are all conversation-based, no
homework, nothing, just two calls and then half-a-day onsite.

To some clients, I send the most competent people I can find and still they
have to go through three calls and a 4-8 hour "coding task" and only then get
maybe invited to an onsite. I have compiled a list of horror stories that I
saw in my recruiting career ([https://medium.com/@iwaninzurich/why-software-
engineers-dont...](https://medium.com/@iwaninzurich/why-software-engineers-
dont-get-jobs-three-horror-stories-77fd1ae3b875)). Since I wrote this, I
collected many other stories, like a candidate being rejected because he took
a call from a cafe and trivial stuff like that.

I think the internet made headhunting/recruiting more efficient but
counterbalanced that by also generating more spam that companies have to deal
with. Maybe companies get increasingly more spam nowadays and this is their
way to deal with this. That is also why they pay recruiters like me.

I see that the mismatch between what companies say they want, what they
actually want, what they actually need is becoming bigger and bigger and I
honestly have no clue how to solve this.

~~~
hocuspocus
> I see that the mismatch between what companies say they want, what they
> actually want, what they actually need is becoming bigger and bigger and I
> honestly have no clue how to solve this.

In the end, how do they manage to hire anyone?

The Zürich (and Swiss) job market isn't that big, but that goes both ways, the
available talent pool is also fairly small, and turnover is lower than in big
tech hubs.

Sure you have access to workers from all the EEA, but while salaries are high
for young singles/DINK, things change when you want to hire experienced
developers (I remember you're from Germany, I know people who moved from
Switzerland to Germany since it made more sense financially!)

~~~
bogomipz
>"I know people who moved from Switzerland to Germany since it made more sense
financially"

The Zurich market pays better, why would it make sense financially it salaries
are less in Germany?

~~~
hocuspocus
Try having kids in Switzerland :)

Also depending on your field of expertise (embedded systems in this case),
there are easily 1-2 orders of magnitude more opportunities in Germany.

~~~
s3nnyy
I think, having kids in Switzerland is only expensive if they are 2-3 years
old because "Kindergrippe" is not public like in Germany. Kindergarten and up
is public and free.

It's true there are not many embedded jobs, but I know at least 1-2 companies
(e.g., bbv.ch), contact me if you want more information (my e-mail is in my
HN-profile).

~~~
hocuspocus
Big difference in parental leave also. It's true that the costs are reasonable
once your kids go to school, and university is pretty affordable too.

As for embedded systems, that's not my field, but the one where my friend
works. After being laid off in Switzerland, he spent a few months looking for
a job (in the whole country), gave up and started to interview in the Munich
area where he could pick between several offers, all upwards of 90k/year.
Plenty enough to maintain his lifestyle.

~~~
s3nnyy
I just see that you are a Scala dev. Write me an email, please? You don't have
an email address on your HN profile.

------
NetOpWibby
I’m hating the job hunt. Everyone wants a web developer who’s been using React
for 10 years and has a PhD in Machine Learning. The good interviews I’ve had
inevitably lead to me getting passed over for someone with “a little more”
design or development experience (I’m a front-end designer AND developer).
Hella frustrating.

------
bproven
Ah my favorite question: "What are your salary expectations?" /s

~~~
krapp
A question for which the true answer ("as high as possible") is never the
correct answer.

~~~
mirceal
Money? My passion drives me! What is my passion? Money!

------
jamaicahest
_Another company asked me to create a web application based on a short
specification. I liked that I was able to pick any language and framework I
wanted to. Furthermore, the project was related to the company 's business and
was described very well._

So basically they asked you to solve a problem for them, without compensating
you. Personally I would have either rejected the task or asked for
compensation. But then again I'm a freelancer, so I know what my time is
worth.

------
s3nnyy
>Within a few days, I had applied to five companies online. I took a bit of
time to craft a cover letter for each of them. Then I was waiting for all the
inquiries to fill up my inbox."

>Nothing. Happened.

How long did you waited for them to get back to you and did you follow up
until they answered "we are not interested in you"?

Silence does NOT mean "No". I see software engineers doing this mistake (in a
job hunt) over and over and over again.

~~~
enraged_camel
On the other hand, I wouldn't want to work for a company where people's
responsiveness is measured in weeks. It means they are either unorganized,
overworked, disrespectful or a combination.

~~~
s3nnyy
I know what you mean but the HR "performance" is often a weak proxy for
measuring the engineering performance of an institution. The disconnect
increases with the size of the institution.

~~~
dilyevsky
there will be strong link between hiring experience and the kind/quality of
people they hire (your potential future coworkers), so that's one reason not
to talk to asshat recruiters.

------
drio
Thank you for sharing this with the world.

I am wondering about the impact that maximizing the overlap of interests
between you and the company would have in the process. Not only at the
technology level (important too), but at the business level. I imagine it
would help you to make your application stronger.

The more I advance in my software engineering career, the more that variable
increases in importance.

-drd

------
Joeri
TL;DR:

\- simplify your resume until it can be scanned in 30 seconds

\- apply at many places, it’s a numbers game

\- build up a local network of people likely to refer you by going to meetups

------
dmoy
Informative read. I do like how they answered one of their own questions later
on:

> Why is it that someone who worked at various tech companies, has an active
> GitHub profile and a blog, is asked to go through programming puzzles? I
> digress.

> While they said I shouldn't spend more than a "couple of hours" on it, it
> took me pretty much one and a half days to finish.

Bingo. (Combined with the disappointingly obvious statement that there are
somehow people with a decade of industry experience who can't actually code,
necessitating some way of determining that for an individual candidate)

~~~
jnbiche
Oh please. The "couple of hours" line is used for any range of "take-home"
coding projects, from ones that actual do take a couple of hours, to ones that
take a few days.

Also, how would programming projects reveal that you're a slow coder? I know
some people who can run through (memorized) coding puzzles quick as a whip but
who struggle to put together a working REST API with a few endpoints in under
a few weeks.

~~~
shortoncash
Haha, so true.

There was one interview with a company I did where they explicitly said not to
take more than a few hours but actually gave you a few days to complete it. So
I legitimately cranked something out as fast as possible in under 2 hours and
actually achieved the task at hand. But, since it was just 2 hours, I didn't
bother making a makefile or splitting stuff into multiple files, or I used
shortcut APIs.

In the end, every shortcut I used to get the job done in 2 hours became their
justification for passing. So yeah, don't actually do the job in 2 hours.

~~~
ThePadawan
Had a similar experience at an on-site coding interview.

I was handed a single file of about 5000 lines of code and told "please note
down what you would improve, just everything from formatting consistency to
architecture".

I got through around 1000 lines in the given time (can't recall how long that
was) and had to tell them "I found too many things wrong with it, here is the
gist".

I went on to work on internal architecture and code quality in that position.

So yeah, not all tests are made to be passed with flying colors, and not all
tests are made to be flunked. Anything in between will still give you valuable
output.

