Don’t Get Attached, It’s Just Luck. My Interviewing Advice and Tips | Hacker News Reader

Don’t Get Attached, It’s Just Luck. My Interviewing Advice and Tips

medium.com

155 pointsmaxehnert106 comments

I have noticed that too often the interviewers look for people like themselves, which I find really naive - chances of you finding your own copy are slim to none.

A recent anecdote from my own experience. I've interviewed with this company. Everything seemed to go well, I had a talk with hiring manager, then with one of the guys from technical team where we discussed real world problems, etc. Everything goes well. As soon as I start thinking this could be the one, they say something along the lines of "let's see if this other guy from our team has some questions". So they bring the other guy who seems a little annoyed being dragged away from what he was doing (we're in an open office with glass walls, so I could see him at his desk). This guy turns out to be the "bad cop". He immediately goes down to more CS/academic level with his questions and eventually asks some question along the lines of "what does compiler do in a situation X when there is Y". Well, I am forced to answer that I have no idea (it's not exactly the kind of problem you normally encounter in real life), so the "bad cop" just nods his head in a forgiving manner and I know immediately it's a bust and that he's gonna veto me out. Sounds familiar?

Yes, that could happen if the person interviewing you has really deep knowledge of a very narrow area and somehow they've grown to think that this niche embodies all of software engineering.

I find that older, more experienced engineers tend to know not to ask these kinds of deep domain-specific questions (unless the are directly relevant to the position being applied for).

The unfair part about this type of interview process is that the interviewer assumes that what the candidate knows is only a subset of what they know - But they completely ignore the knowledge that lies outside of the intersection (which could also be useful).

This has got to be one of the most honest descriptions of how job hunting actually works ever written and posted on HN.

It's a sharp contrast to a lot of the stuff that is posted here that depicts job hunting like some kind of spiritual search for your life's passion.

I think this is a great description of the job hunting process early in your career.

Later in your career, if you have kept connections alive, the job hunt should look like this:

"Hi <member of network>,

I'm looking for a position doing X at Y, and I noticed you know Sara at Y. Do you mind doing intros? I'd really appreciate it."

...

intros/coffee with Sara.

...

resume to the hiring manager, perhaps through some automated system, but with a thumb on the scales

...

interview

...

hire/no hire decision based on mutual fit.

Now, this isn't about nepotism, it's about the power of having worked together. While the internet is great and you can learn a ton about a candidate (sometimes) by their online work, sometimes you can't. And nothing is as high bandwidth as having worked with someone. (Well, maybe a family connection.)

So if you can build your trust networks and get informal introductions to a company from someone who has worked with both parties, you're in a very strong position.

That said, as I stated at the beginning (and the author did as well), this post was fantastic for folks without such a network.

Yeah, I totally agree. There are really two ways to find a job, what the OP describes and, as you say, via professional connections you've built over your career. If you can get a job you like through professional connections that is hands down the way to go.

Personally, with the exception of my first job out of school, I've always used the professional connections route. I probably couldn't get a job doing what the OP describes to save my life. Luckily, my reputation is such with prior employers and colleagues that I could call any of them up and they would go out of their way to hire me.

> Later in your career, if you have kept connections alive, the job hunt should look like this

If you kept connections alive and actually have connections that move on to other companies. 95% of the connections I have made in 14 years are either retired or still at the companies they were at when I met them. How does this help me?

Interesting! Not my experience, so hard to comment intelligibly. As if that is going to stop me, this is the internet.

I guess I would still go into your network and see if they have met anyone who has moved on. Adter all, it isn't the direct connection that you are looking for (though that is preferable), but the second layer connection.

Otherwise I think you are either in the position of following the author's advice or trying to expand your network by working with people in other ways (side projects, moonlighting, open source, volunteering). I know how unsavoury that choice is.

Since I can't definitively speak to your situation, let me talk about ways to avoid it.

- work in a consulting shop early in your career.

- seek big companies over small as your first or second job

- prefer job dense locations early in your career

- volunteer your time when you have cycles. Work an event, write some code, etc

I realize these are not all available to everyone, they are just guidelines that will expand your network.

I forgot one of the best ways to expand your contact network: contracting. Find a company that can sell your hours and give them the 40-50% they will take. Make sure you add everyone you work with (clients, other contractors) to your network list (I prefer LinkedIn but excel will work).

In my experience, your network will get you an interview, but after that it's the normal interview hazing as described in the article. Because there are so many random, subjective factors at play, it's impossible to tell if a network referral will result in a job. As such, it's a bad idea to rely on them as your sole means of finding work.

I think both are real, just in a different context. Almost everybody is passively looking for an ideal position all the time. If you get recommended, see some job ad, or just see what's out there - you're looking for life's passion. I know I interviewed for some positions even though I already had a good job, just to see if there's a better option.

But it's different than when you're in / just out of uni (I still remember sending just under 150 applications...), or when you're just recently out of work with a family and a mortgage (and you need something now).

Really depends on your circumstances. I've been doing part-time gigs since I turned 18 and recently finished my PhD. When I searched for my first full-time job I interviewed with a bunch of companies in different industries in different countries. I got an offer from every one of them and it really turned into a search of where I think I would be the happiest.

Sorry to say it but if everyone says yes without further thinking, it means that they know they're screwing you ^^

Lowball salary? No benefit? Bad company desperate to hire? There can be many explanations.

Or, possibly, extremely competitive candidate with a unique skillset.

Based on this limited info, he gp was probably very affordable. Which is fine, I was very affordable when I first came out of school.

Hey thanks for the kind words. I wasn't sure how receptive people would be to this when I originally wrote it out but I'm glad some people enjoyed it. Hopefully it helps a few people.

I've been coding since I was 14 (I'm 27 now) and went to uni; I usually never have a problem with technical interviews, but I applied for Facebook just to try out their interview process (because one of my academic-minded software engineering friends told me that he didn't pass the third interview - So I was intrigued).

I thought that their questions were mostly good but the interviewer makes you code live in realtime - I found this really stressful and I froze several times.

I remember one of the challenges they posed in one of the interviews was to flatten a JSON multidimensional array that had an arbitrary level of nesting. I implemented the recursive solution without any problem (which is the difficult part right?) but then the interviewer asked me to come up with a non-recursive solution - This is actually easier, but because I was under stress and was still thinking about the problem in recursive terms, I just froze.

I even asked "Do I need to use a fringe list?" (referring to a structure used in several search algorithms) but I don't think the interviewer understood my question and they weren't able to give me any guidance for what they were specifically looking for so I just asked to skip that question because of time pressure.

Then later they asked some really easy questions about HTML and CSS (which I've done thousands of time) but because of the IDE they made me use, I couldn't actually run the code to test (and under stress, I forgot the exact syntax for a few things).

I guess this is an interview process you need to really prepare for.

I suppose the process makes sense for FB; the feeling of 'being watched' which I felt in the interview is probably common while working there day-to-day (considering the open workspace environment) - They need engineers who can perform in such an environment. I'm definitely not one of them.

Actually to me this just sounds like a typical bad tech interview. The idea that you'll be live coding on the job with someone looking over your shoulder is kind of silly no matter where you work, even in an open workspace. Also, you'll probably use your own tools not their IDE, and if you did use their environment, you'd have ample time to pick it up. And so on and so forth.

I've frozen in interviews before under similar circumstances. The only blame I place on myself is not being a better interviewee... it really is a skill unto itself quite apart from the job and apart from programming.

I actually did a very, very similar interview before without any issues. The difference was that the previous time, the interviewer gave me a paper with lots of questions and left the room.

Is there no trial period in the US?

Every person we hire here (Switzerland) gets interviewed but because it is almost impossible to know if someone is going to work out there is a trial period of three months by law. Usually with a termination time of one week. After the trial you will usually need to give at least three month notice. You can get the most brilliant Coder but if he/she doesn't work with your existing team for what ever reason, he/she isn't the right fit for you.

You can only find these things out after they start working for you.

Unless there's an employment contract or collective bargaining agreement stating otherwise, people can be fired in the US at any time for almost any reason. That "almost" hides a little nuance, such as the reason can't be related to race, gender, or certain other "protected" reasons, but, "any reason" is a pretty good approximation. No notice period is required. If you're lucky, you get to walk out by yourself carrying a box of your stuff. Frequently people are escorted out.

That's horrible. And I'm from Romania, which is a second world country, basically.

We usually have a two week notice (it depends on the company and the position) and I've never seen someone escorted out. There's often a short inventory of company assets you used, and that's it.

It has its downsides, but the benefit of such a system is that it is easier to hire someone as well. It lowers the risk of hiring if you know that you can terminate employment just as easily, so the jobs market ends up being a bit more robust at the cost of a bit more volatility.

It should also be noted that for the sort of jobs we are talking about here there is a difference between being terminated 'for cause' (e.g. incompetence, theft from your employer, etc) and termination due to downsizing and the job itself being eliminated. In the latter case you will often get a package of benefits and the termination process is somewhat similar to the one you are familiar with.

However, no notice and escorting people out sounds more like power fantasy than something with economic reasons.

In the US, if there are mass layoffs at large company they need to give notice because of the WARN Act (100+ people) requires a 60 day notice. But many companies will just continue to pay those employees for 60 days but they aren't allowed on site (effectively fires, but still being paid)

I'd say it's more of a security concern than anything. The thinking being that you don't want a potentially disgruntled employee with little to potentially lose have access to your systems.

I was sure someone would say this. As a comparison: Romania is a relatively poor country, full of hotheaded invididuals ("Balkan" mentality). On top of that, we're apparently EU's #2 expat community in terms of total prison population. So both hotheads and also a lot of criminals (most likely thieves).

And yet we still allow our folks to walk unescorted for a few weeks inside the company premises.

After all, how many just-layed-off employees will want to steal or damage company property to top off their recent loss of job with criminal charges and a criminal record?

From the outside it feels like a bit of paranoia on the part of US companies.

I might be missing something, this is just my opinion as an outsider.

Let's consider the counter-argument and ignore any possibility for vandalism, theft, hacking, or other destructive activity by a recently terminated employee. Why would you want them walking around the building? What possible benefit is there to this? Why not just give them a hearty handshake, a thanks for your work, and tell them that they will be paid for the remainder of the termination period but don't show up at work tomorrow.

As for the paranoia part, it is definitely a bit of paranoia on the part of the company management but paranoia for a reasonable reason: there are numerous examples in the US of someone getting laid off or fired and returning to the office with a gun. From the perspective of management, why take the chance? If there is any hint that the termination will not be pretty you make sure someone escorts the person out and you have shown yourself to be taking due consideration if something unpleasant happens.

> What possible benefit is there to this?

Non USian here: regardless of who gave notice, the lame-duck period is normally used for wrapping up whatever work/project the departee was working on and handing it over to a colleague or manager. People generally are more worried about getting bad references than office shootings.

A trial period is a great idea only if the switching of jobs is not disruptive to both parties.

When you switch jobs in the USA, you switch health insurance and other benefits. Doing this for 3 months and then finding another job would be tedious.

Also, if it doesn't work out, what does the candidate do? Go hunt for another job with a negative signal on their resume? If I were a job seeker that would seem high risk.

This is the same reason contract to hire positions don't attract everyone. If you are good enough, the company will commit to you without the trial period, which candidates typically want.

Optionality has value, and both parties can't possess it.

> When you switch jobs in the USA, you switch health insurance and other benefits.

In Switzerland, you'll switch accident coverage and probably the pension fund. Still some work, but not as tedious as what I imagine the situation in the US to be like.

> Go hunt for another job with a negative signal on their resume?

Both parties are free to end employment during the trial period. Maybe the candidate didn't like the work environment? Also, the future employer stands to gain an employee pretty much immediately as opposed to wait for the usual 2-3 months(!) notice period. Finally, unemployment benefits in Switzerland are fairly generous (70% income over 20-ish months), which mitigates the risk to candidates somewhat.

Simply having a 3 month tenure on a résumé is a questionable signal to one's next employer, regardless of circumstances.

not specific to Suisse, but this can be PITA - actual hiring in bigger organizations take many more months, so hire&fire is a very costly exercise, time and cash wise.

As stated before, it's nicer to the employee on one side, but since everybody wants to hire proper guy to avoid firing&rehiring hassle due to these protections, interviews can end up on the ridiculous side.

you gain something, you lose something else.

I freeze under pressure, too, but I work in an open office and have no issue with that. It's not reasonable to literally watch over someone's shoulder while they're working. That's just interview hazing. They do it because the people who hired them did it, on down to the first engineering employee hired by FB who probably had it done to him/her because the people interviewing had no idea how to interview any better.

BTW, what's a "fringe list"? Googling that term shows me results pertaining to the TV show Fringe (which is great, but I'm sure not what you're getting at).

I guess it's not broadly used terminology but it was common when I was at uni: http://mnemstudio.org/path-finding-a-star.htm - It's basically a list which you use to hold nodes which you haven't visited yet and you expand them in-place and pop them off as you visit them.

Oh, right, like the "seen but not visited" set you maintain when doing BFS.

I have a coworker that said he basically walked out of an interview that asked him to write three different sort algorithms on the board - he was applying for your standard enterprise developer.

I agree with him. I'm not applying for a code monkey position. I'm applying for a senior software Engineer or architect. Someone who can use modern tools and create solutions.

I had two coding tests during my last round of interviews. One on a computer onsite where the interviewers left me alone with a computer and IDE and permission to use Google and the other a coding problem I had a week to complete, turn in on github, and the second part of the interview was going to be a code review.

I found both to be acceptable and relevant.

this is all good info. especially the take homes.

when i interviewed this time around for a new job, the most frustrating part were the take homes. lots of companies expect you to do a sample project that only grants you an audience to a technical phone screen. like, what? didn't i just pass your technical test? if i still have to show my technical prowess doesn't that mean you don't trust my resume, or trust that i honestly completed your assignment?

i also agree these take homes are not 4 hour affairs. they give you no direction so you can't sacrifice ui/ux for functionality because you have no clue how they judge it. i failed a large company's take home even though it was feature complete, but i sacrificed really slick/nice ui for a workable ui that i felt was passable given no direction.

i got a thanks but no thanks reply back.

as with regards to luck; another company i interviewed at, i aced their take home. then i interviewed with ~6 people who all said they liked me (or at least that was the feedback i got). but when i interviewed with the vpe, i failed a question about semaphores, (i knew what they are, but just didn't have the answer to a specific question the vpe asked) and failed the job app.

the job position was to be a front-end developer.

> "i also agree these take homes are not 4 hour affairs. they give you no direction so you can't sacrifice ui/ux for functionality because you have no clue how they judge it."

I had a take home for a UI position that I spent ~10-12 hours on. It was some pretty standard UI stuff and they had 5 points of functionality they wanted you to code. Make it responsive, have these sections in a different order on mobile, make X do Y when you click Z, etc etc.

At the interview, two technical peers walked through what I had submitted. Their questions made it really clear they had no idea what problems I was supposed to solve.

- Why didn't you write a complete RESTful backend to serve this data? (the instructions literally said not to)

- Why didn't you use a CSS pre-processor? (the code required ~30 lines of CSS)

- Why doesn't this button work? (it wasn't supposed to)

- Why doesn't this code work on a mobile device? (it worked just fine on mobile devices)

Really just a strange, strange experience.

Given their cluelessness, would you even want to work with them? I'm guessing you "failed" that interview, and it was probably a good thing, too.

I hear this a lot in these kinds of discussions. While I agree with you that these might not be the best people to work with, the equation looks very different after doing these kinds of interviews for 6 months and you really need a paycheck yesterday.

I disagree about the take homes. But this may primarily be because I've been hiring with a heavily weighted take-home for the last six months. Here's my reasoning:

1. I don't want to work for a company that uses CVs as a major part of its job screen, since they are nearly useless from an informational point of view. Steps that improve the quality of candidates also improve the expected quality of your future colleagues.

2. The take home gives significantly more information than a phone screen. Candidates who are rejected because they find the take home too hard, or who would have passed a phone screen but not the take home are saving time because they don't have to take any time off to come into the office for an onsite.

3. Having a good take-home means we can make the rest of the process more lightweight. We have an extension interview where we pair with you while you extend what you took home, and then you're done. This is much more respectful of your time than multiple days of algorithmic questions.

4. It's easier to make marking take-homes blind - i.e. to guard against various biases compared to phone screens and even in-person interviews.

5. The take-home is simplified, but similar to the sort of thing you will have to do in your actual work, so doing it gives you extra information about the job itself.

6. The take-home is designed to result in something that's fun. Many of our candidates say that they enjoyed doing it. Even some of the ones who fail it. Some even say it's a reason that they choose us over some other company.

It is true that some good candidates simply refuse to do take homes on principle since they have lots of choice. To try to combat this, we make sure we try to explain why it's worth your time.

If I told candidates 'congratulations, you've got a 1 day onsite interview' (where in the morning you're on your own and we send you home at lunchtime if you've not made good progress) instead of a half-day take-home (in which we are very flexible over how much elapsed time you need) and a 1.5 hour onsite extension, do you think candidates would prefer that?

I'm assuming you're referring to an un-timed homework assignment. Timed homework assignments are absolutely the devil and I don't think I'd do one of these.

My biggest issue with (un-timed) take home assignment is that often, as a candidate, this ends up with me investing a nontrivial amount of time, only to not hear anything back. If I'm going to spend multiple hours on something, I would kind of like something in return, such as feedback on my work. Very, very few companies will give any feedback since they don't want to be sued and/or have the candidate try to rebut the reasons why they were turned down.

Yeah, it's untimed in the sense that we don't specify an elapsed time it must be done in. People have different things going on in their lives, and you can't just assume they can drop everything for your test. We specify a suggested amount of time so that people know not to spend too much time on it.

On the feedback point: this is a perfectly reasonable stance. Perhaps I should give better feedback to our candidates.

Part of my concern is that I've seen candidates show me emails from their recruiters that have attached all the detailed feedback I've give to their previous candidates.

The other thing is that at some points in the hiring, you're really competing against the others in the pipeline, so you might have actually performed very well, just not quite as well as one of the others. I have also seen one candidate fail based on multiple independent personal disrecommendations rather than on performing badly in the test.

I have noticed in previous interview processes that a lot of people think they failed for a reason other than the reason they actually did fail.

I do think it'd be more fair for me to give better and more detailed feedback, but there are a lot of pitfalls with the most obvious version of that. Perhaps there's room for a bit of disruption with a good solution to this problem.

Triplebyte does a fair job on the feedback front. I've been through their process recently, and found it to be more useful for me than any other company's process (I chose the coding project over the standard process). I dislike that they still put candidates on the spot by writing code literally in front of them[0], but the feedback I got from them was actually useful.

I think your issue with candidates showing you emails from their recruiters is actually an issue with recruiters more than your process. Recruiters will do just about anything they can to make the placement.

If you're in a situation where a candidate excels on the test but gets passed over in favor of someone who did even better, then, good for you. :) "We decided to go with another candidate at this time, but here's a little feedback on your coding project," would go a long way with me. If you're really feeling generous, a referral into another company would be a great thing.

Someone who fails because of personal disrecommendations, you can just give them a generic "We reviewed your coding project and here's what we thought of it... but we decided to go in a different direction. Best of luck on your search." (I'm assuming these people fail because they're assholes, not because they're incompetent, right?)

---

[0]: Seriously, guys, if you're reading this... I chose the project interview because I fall apart when being put on the spot, and I told you that. I don't have someone watching over my shoulder at work... and it's a good thing, too, otherwise I'd end up having anxiety attacks.

i don't think pure cvs are the answer. i don't think a take-home is either. especially since a lot of companies expect you to put a lot of sweat into these take-homes.

if your take-home is a "half-day" which means... 12 hours? half a work-day? what? that does not sound appealing to me. unless you are actually building something unique, offering more stock, or more money, or a better work environment i am not sure how you can explain it's worth it to someone to go through your process and essentially wasting an afternoon to a week of their life doing the take-home. _especially_ when most companies will reject you for a lot of silly reasons.

in a perfect world your scenario would be "fine" and all your points your company may actually do. but across the swath of companies there is no guarantee of this.

for example you cite #4 as an point for doing take-homes, except i seriously doubt many companies mask/hide who the person coding it is. they usually just hand it to one of their engineers and go, "evaluate this" and now you're at the mercy of what kind of engineering person he/she is and whether they're currently too busy to give you a fair shake or any other myriad reasons.

you can barely get companies in silicon valley to admit there is bias let alone set up some blindness against it. unless they were able to submit the initial job application anonymously, how do you know your process isn't bias at that point from your HR person? maybe you do account for that, but how many companies realistically do that?

and again without knowing your company or your process, _every_ company with a take home says, "take your time", "we're not in a rush" etc but never actually tell you that they want just <X> and if you do <X> that's enough. people literally have no idea how you're going to judge their take home. maybe the question is unclear, maybe your view of a "good enough" ui to them is a ui that takes longer than the time you've alloted them. maybe you don't like it when they write their javascript without semi-colons but you don't bother to tell either the interviewee or the grader any of that. then there is also the problem that even with "correct" code a lot of engineers who review take-home tests just _love_ to nitpick to disqualify possible candidates. and if you _do_ have a process in place to guard against that, you would literally be the first company i've heard who goes that far in their interviews.

i don't doubt the way you're handling it is getting the results you want and is the best way to hire. but i doubt that's how other companies are handling it. now you expect people looking for jobs to be able to discern between you and the other group? you want me to apply and assume good faith that your process will only take half a day and is "fair"?

edit: i tried editing this to make it not sound very antagonistic, but it is late here in sf so it may come off like that so sorry if it does. i don't disagree that take-homes work for you. i just don't think most companies in the bay area have thought it out very much other than, "use take-home test in interviews"

half-day means four hours. I'm being generous there, because a skilled developer can create a good solution in 2 hours, but many find they want to put around 4 hours in.

In terms of what you have to do for the take home to be a success, we explain that fairly clearly these days. I'm now on the 6th version of it because I ask for feedback from the people who do it and try to improve the wording and make it more clear over time. I also provide contact details for people with questions.

It's also a fact though that simply achieving the task is not enough if the code you used to do it is sufficiently poorly factored or overcomplicated to a ridiculous extent. We don't mark people down based on superficial coding style. Fails get marked by more than one person, the marking team is small and regularly talks about the individual tests they are marking, but there'll definitely be situations where working code gets marked as fail.

The person marking the take home does so before they get access to the CV. They do usually know the name, we'd need a more complicated process to redact names from submissions, but it might be worth doing.

I am sure there are ways we can improve our process, and I am aware that there will be lots of companies out there with a process even worse than ours, but I wanted to talk about it, partly as a way of getting feedback with the aim of improving it more, and partly because I hope that others can learn from what we've done.

I have been pretty happy about the team we've built with this process compared to teams that I've been involved with building in the past, so there are definitely good parts to it. The two big concerns I have with it are 1. are we being equitable with peoples time and 2. can we reduce the number of skilled candidates who refuse to do it on principle.

I'm surprised this hasn't been mentioned. I have been on both sides. Take homes are awesome when used correctly.

They shouldn't be used for a candidate with a relevant opensource profile. In that case, you can already assert that they have the technical skills. You can ask them about their projects to make sure it's their work if you want. Personally I'd go straight to communication skills and cultural fit.

For a candidate without much opensource contributions, take homes help both sides:

- Candidates get the chance to prove that they are smart and fast learners (especially if you want to get into a slightly different area) - Companies don't have to worry about candidates who can't do fizzbuzz - Neither side have to do the horrid live coding (yeah, nobody likes that, even the interviewer)

The awkward thing for me is to deal with candidates who seem to be good at _something else_ (that is not a good approximation of the work at hand). I usually ask them why they want the position. Usually it's just that they "want to get into a slightly different area" and fortunately most agree that a take home is fair.

> The awkward thing for me is to deal with candidates who seem to be good at _something else_ (that is not a good approximation of the work at hand). I usually ask them why they want the position. Usually it's just that they "want to get into a slightly different area" and fortunately most agree that a take home is fair.

Trying to get companies to even talk to me about positions that are not like whatever I am currently doing is like pulling teeth. I used to work in real-time embedded systems, signal processing specifically. I shifted to NLP and ML for reasons, but one of them was not "I'm tired of/can't hack embedded and want to try something else". I would love for companies to give me take-homes to prove I can still do embedded. Instead they just ignore me.

> the job position was to be a front-end developer.

You lucked out then, I think. If they were looking for a front end developer and asking questions about semaphores, something is definitely wrong.

the position was for a front-end role, but the company itself is more "low level" than that.

it was just one of those situations where the vpe is a very smart person, but has no clue about the front-end, and apparently this was a pet question of the vpe. i don't think i "lucked out" since the people i would have actually had day-to-day interactions with were fine people. but yeah that is definitely a blind-spot for them.

The methodical approach is applaudable, and I'm really glad it works for people like the author. Maybe it is indeed the best strategy. But after a few rounds of doing this, it gets old. Not old as in, "I'd rather be watching westworld than drafting this cover letter". But old as in, "I'd rather be shoveling diarrhetic pig shit than doing this code exercise".

I really love being a software engineer. The job application process is the biggest threat to me keeping that passion.

I completely agree. It's incredibly frustrating to stop working on any side projects and stop learning any framework/library stuff to focus exclusively on algorithmic questions for weeks or months. That's why I tried to make it clear you have to just push through and give it everything you can so you can get back to doing fun stuff again. No one likes doing this but lowly developers that just need a job can't do much about it unfortunately.

Side question - how do these people interviewing at "a dozen or so places" manage it? Assuming most companies' interviews will force you to take a full day off work, and they will have different schedules and offer deadlines. Is there a trick to managing this that is eluding me? Even with taking a couple of weeks off it seems like it would be very difficult.

Without a job, one usually has lots of free time.

That still doesn't help much with lining up the offers, but I guess that's less of a concern when you're unemployed (I.E. you'll take the first decent offer you get). However, I feel like I have often read accounts of people with a job interviewing at 6-10 companies and I always wondered how.

> That still doesn't help much with lining up the offers

Larger companies are aware that you might be pursuing other opportunities, and are usually willing to postpone extending a final offer until the time you are ready to accept it or at least have other offers to compare it to.

Well, look for companies that are willing to do interviews during your lunch. Those are the companies you'd want to work for anyway, since they have enough empathy to understand that 2+ hour interviews are risky if you're already employed.

I mentioned I track everything and try to apply in a small timeline to bunch interviews together. Most places want 2-3 phone interviews before anything else which at most meant leaving work a half hour early (I just go in early or stay late another day). When it comes to on sites, well I guess I had a lot of vacation time from not taking any previously.

I hadn't really thought about that before, but yes the time issues could be very challenging to juggle if you aren't in an ideal situation.

Lots of great stuff here. It is a numbers game in many ways since I've been in interview processes where we turned down lots of people who go on to succeed in amazing ways at other companies.

I would be wary about recommending most people write cover letter templates. I can tell a templated letter most of the time. I'd recommend just writing a few sentences from the heart. Why you're great for them. Copy+Paste doesn't work, since each company is different and your background will connect in different ways. Keep it short and just ask to learn more.

Thanks for the kind words.

For cover letters, I think I'm using template more loosely and probably should have provided examples. The template part is for describing myself, however I still write out a paragraph or two specific to that company. I think I noted on researching the place before hand so you can include your favorite things about the place in the letter.

It's quite fitting that the dating scene in S.F. is often similar to tech interviewing. Play the number games, don't get attached, and move on. Nothing personal, it's just metrics. Is this what cutthroat economic competition does to people?

The dating scene is messed up for men in the Bay Area because eligible men vastly outnumber eligible women. It's as simple as that. All the unnatural relationship dynamics flows from this fact. More men study computer science, math, physics, and engineering than women do. Silicon Valley is a magnet for people in those fields. Silicon Valley ends up with way more single men in the 20-40 age bracket than single women.

If you a straight single male, you have an important decision. If you value the immense professional opportunies of the Bay Area more than finding a partner, then do move there. If you think that finding a partner is also very important, then consider finding your job someplace with better ratios. If the Bay Area 20-40 dating pool is something like 3 male to 1 female, that means 2/3 of single men will be without partners.

It's actually not quite that bad, but there are some areas where men outnumber women by over 40% [0]. The ratio is a little better in Silicon Valley, at about 1.14:1 [1]. The SF/Oakland/Hayward metro area fares a little better at 0.93:1 overall [2], but that doesn't take into account how difficult is is to access SF from the East Bay and vice versa. It doesn't take much of a skew to really mess up the ratios.

[0]: http://visualizing.nyc/bay-area-zip-codes-singles-map/

[1]: http://blog.sfgate.com/stew/2014/10/02/study-says-silicon-va...

[2]: Ibid.

When it comes to dating, simple gender ratios might not paint the complete picture because it's not just any man:any woman. Frequently, the prospective partner has to have a similar socioeconomic background: I'm not in the Valley so I don't know if that ratio is in the ball park of 1.14:1 for the "goes to Silicon Valley" male archetype

"When I go into ‘interviewing mode’ I stop working on side projects, I stop visiting bs sites like reddit, news sites, and even HN. If it isn’t going to help you get that job just cut it from your life. Focus intensely on learning and writing job applications until you get there. This process isn’t fun, why drag it out any longer than you need to."

That ... doesn't sound healthy, or productive. It is well established that there are diminishing returns to working longer hours on a task, even to the point of negative marginal utility. This is not true just for knowledge workers but, surprisingly, also held for factory workers during the industrial revolution. Not to mention the health impacts of spending so much time on a singular (soul crushing IMO) task.

I don't think it applies here. If you work on one task with one goal for longer, you do get exhausted. But I don't think it applies to repetitive tasks with different targets each time. You cannot "apply harder to the same company", but if you spend more time and apply to 30 rather than 20, you get a big improvement in the chance for positive response.

actually trying an unproductive technique is what is wrong. You need to be full time and using a productive technique, so I do agree that just sending out CVs 24 hours a day is wrong

actually this is the right advice. To find a job IS a full time job. No one wants to hear it but after running NemCV and getting data on around 15,000 job hunters, I saw that the people who treat looking for a job AS A JOB get a job over 10x faster than those who don't... Here is a link to the meetup we have run for 5 years too:

http://www.meetup.com/get-your-dream-job/

It's too bad I'm thousands of miles away from you. I would go to that meetup. :)

Maybe we could do a video session one day if you want to set up a video with a local meetup there and you don't mind broadcasting it publicly.

While it seems obvious now, the note that job listings with direct emails get first priority is something I'll keep in mind for the future.

I applied a similar principle to getting my first place in the Bay Area. I made a point to contact listings on CL that included phone numbers before other listings. I got lucky, and it worked out. :)

I'm starting to feel the same about the take home tests. Too time consuming.

I agree completely. It really pisses me off when you complete the take home test and then get called in for another 8 hours of whiteboard technical interviews.

WTF is the point of giving these work sample tests if they're not sufficient proof that you can do the work? And how can anyone think actually programming things into a computer is superseded by asinine whiteboard sessions that have less in common with the day-to-day of programming?

IMO, after the take home test, the in-person should be a couple hours or half day for personality fit and maybe some loose questions to determine if you actually did the test yourself. Mainly, the in-person interview should determine if you can tolerate sitting next to each other all day.

So I've started giving negative Glassdoor reviews to companies that abuse these tests, either by handing out broken or excessive ones or by wasting a full day of my time with algorithm questions AFTER accepting the test. I suggest everyone do the same.

I think it can work both ways. Tasks like that can be time-consuming, but would you rather take a day off for an on-site interview, or spend ~1h doing it at home? There's some line that shouldn't be crossed of course - I think companies shouldn't give the test to everyone - just those who are actually considered after some screening. But I've been on both sides: taking and preparing the test, and I think it's a good idea as a 2nd stage filter.

My test was completely open-ended. Trivial task (script to copy data from .csv to a sqlite, optionally notify on the queue at the end), but make it as production-ready as you can/want. I don't think I could learn as much about people's abilities during an interview, as I could from that task. I mean, the 1 person who made a proper package, a short .rst install & use documentation, and included crazy unicode test cases was immediately on the top of the list.

Those take home tasks are rarely 1 hour deals, so it's not a question of spend an hour at home or take a day off for an on-site. It's usually spend X hours at home and take a day off for an on-site.

Do you really think that "crazy unicode test case" person really only spent an hour on your test?

> Those take home tasks are rarely 1 hour deals

This seems to be the common complaint, but really this is discussing the idea -vs- the implementation. Some examples here of checking specific things that were not in scope, or tasks that take whole day are really disappointing. And I agree there are loads of really crappy tests out there.

But yes, you can create a test that's easily doable in 1h. As for the crazy edge case tests: probably. It's still a reasonable thing to check for, but often people don't. (having a non-ascii name helps here) If you have simple enough and open-ended enough tasks, I don't think extra time helps the candidates in any way. I mean, either you have experience doing something or you don't. Even if you spent, for example, X hours researching "what does production-ready mean?" and related topics, I don't believe you'd produce as good result as someone with actual experience. (yeah, I could see that in the answer)

I will concede the point that if it literally takes an hour, and it means I don't have to write code in the interview with someone watching my every move at all, then, yes, I would gladly do such a test. I'm still skeptical that a test that requires writing production-ready code and tests would really take only 1h.

So you prioritized for people willing to sink many hours into your assignment. The need to sink many hours into a homework assignment is the criticism.

Phone interview - 1h during work hours. On-site interview - ~3h total, but probably a whole day off work. Test - ~1h at any time you choose.

I'm not sure I follow your logic. They would spend just as many hours, at a more inconvenient time of day without the test. I did the task myself to a level I'd expect at the time to make sure it does not take "many hours". If that simple task would take people many hours, then I hope they didn't apply... (or they would probably fail very soon if hired at all)

The candidate gets no benefit from doing your take home test. In an interview the candidate learns something about the company. Also the ~1h requirement just isn't realistic if you give an open-ended test - you penalize the people who actually spend 1h and reward those who spend more time.

As the other commenter pointed out, you don't control how many hours a candidate spends on the assignment. All you see is the end result, and the guy who spends 8 hours will generally end up with a more impressive result than the candidate who spends 1 hour, and this reflects time spent far more than candidate quality. If you give an "open ended" assignment, you are encouraging candidates to spend a ton of time and then lie and claim they spent very little time, because that looks impressive.

Do you really think "the 1 person who made a proper package, a short .rst install & use documentation, and included crazy unicode test cases" spent only an hour?

they're the worst. about 6 years ago i applied for a job at expensify, and they gave me a take home test. when i sent it back, they couldnt read the code. they asked me to condense it all into one file called main.php. (i separated into controllers / views for a web app)

It seems to me like they failed the tech interview then. Just move on...

>> When I go into ‘interviewing mode’ I stop working on side projects, I stop visiting bs sites like reddit, news sites, and even HN. If it isn’t going to help you get that job just cut it from your life.

While I agree that interviewing is a bit of a crap shoot, the above paragraph from the OP is actually a pretty good argument for not doing anything to prepare for it.

If going into interviewing mode means you stop working on your own stuff, or having free time, or generally doing stuff that a) you enjoy and b) make you better at your work (rather than interviews) then you're paying a cost alright, and it's at least comparable to the cost of take-home coding exercises.

If you're just applying anywhere you can it probably means you don't care where you go anyway. If you apply in sufficiently many places eventually you'll find the one place where they like you, you like them, you got what they want and they're willing to hire you.

In fact if you take the time you'd waste in getting good at interviewing and invest it in learning a new language, or framework, or following a MOOC etc, you'll probably end up with much better qualtiy work, because your actual work skills will get better. It might take a bit longer to get there but you'll (probably) stick around for longer and you'll get more out of it.

(Is it okay to post things like this?)

I've written a self-hosted search utility for HN threads posted by whoishiring which I'll be using in my upcoming job hunt in a month or so. It performs regex-based full-text searches of top-level comments in threads posted by whoishiring. I hope it can help someone in their hunt!

https://github.com/cashweaver/hn-who-is-hiring-search

"Things like knowing the box model, closures, map/filter/reduce, object vs array, prototypes, bind/call/apply, event delegation. These made up almost ever single first phone screen interview I’ve ever had."

Seems pretty hefty for a junior-frontend-position.

You're right, I should have been more clear. I wasn't applying for junior positions anymore but most of the technique is what I did the last time I applied for jobs when I was looking for more junior positions.

really? this to me just seems like knowing the language you're going to be working with every day. If you don't understand these concepts, how could you be an effective developer?

Why do rejection emails say "good luck" at the end?

Because you, the recipient, must now continue the job hunt, so luck in finding a better employer would come in handy.

But why is this pleasantry about "luck" and not something else? You don't hear employers say "keep studying" or "we wish you a good effort" or "we hope you build cool stuff".

Isn't the employer referring to luck an admission from the employer that interviewing has a lot to do with luck?

Because "keep studying" can be construed negatively: You're not good enough. Unsolicited advice isn't usually a good idea politically.

Saying "luck" implies several things: - You just weren't the right fit. - I don't wish to imply your skills are lacking. - I hope you succeed, even though I wasn't able to help.

> Because "keep studying" can be construed negatively: You're not good enough. Unsolicited advice isn't usually a good idea politically.

They're rejecting you because you weren't good enough (or because they suck at actually identifying talent).

> Saying "luck" implies several things:

None of which are good things about the process, because a process should be designed to drive the percent influence of luck to as close to zero as practical.

> - You just weren't the right fit.

Bullshit non-reason.

> - I don't wish to imply your skills are lacking.

We also don't want to admit that we may not have any idea what we are looking for or how to evaluate it.

> - I hope you succeed, even though I wasn't able to help.

If I don't need improvement but I succeed elsewhere in a similar job, that just means you screwed up.

I think it roughly translates to: I hope you have more success in the future

Because "keep studying" would just sound condescending.

I personally find "good luck" and "we reject many good candidates" it be even more condescending.

It's a pleasantry. It's a part of communicating in a tactful and empathetic way.

It cleanly cuts the applicant loose, leaving zero ambiguity as to their chances with the current prospect company, while at the same time saying "you got spunk, kid; I like you and I'm rooting for you", all in two little words.

It shows that they have no ill will towards you.

I can't imagine going through that much trouble trying to find a job as a developer. My m.o.:

1. Contact my list of (currently) 14 local recruiters from different companies with my resume, and tell them what type of job I'm looking for, salary, and location within the metro area.

2. They send me a list of jobs with the descriptions abd salary range - something you can't usually get without a recruiter - and I tell them which one I want to be submitted to.

3. Keep a list of the jobs, status (submitted, phone interview scheduled, in person interview scheduled, waiting for response), recruiter information, etc. so I don't get double submitted.

Historically, since 1999 and three years out of college, it has taken me about a two-four weeks to find a job, usually paying significantly more.

The last round I just went through. I had 13 prospects, 7 phone interviews, 3 in person interviews, trying to schedule the other 4, and will probably have four offers by the end of the week. This is with me being picky on location, salary, and environment.

I'm not trying to say that I'm a special snowflake. I know a lot of people that I work with that could do the same.

If a company makes you an offer early in the process, how long are they typically willing to wait (while you interview with the other dozen companies)? Esp if you save the ideal companies for later in the process.

My perspective is skewed because I'm a uni student, but although there's really good stuff here, a lot also sticks out to me as the kind of advice I'd be giving to someone who just wants something to pay the bills, not someone who wants to do something they really want to do.

The high volume apps and crapshoot stuff - 100% yes.

Stuff like template cover letters? Nuh-uh. I have a structure that I stick to - hey, saw you guys are doing X and I think X is cool and wanna help y'all build it up, blablabla - but it's not a fill-in-the-blanks template.

> Additionally have a good set of STAR questions ready and memorized. [...] Tell me a time when you disagreed with a manager… those types of questions that we all hate, but you MUST know them and be familiar with them.

I can spot a memorized behavioral from a mile away, and it is without fail a terrible move. I mean, yeah, go through the questions, jot down a note about that time Alice did that thing or you had to help Bob out with that other thing in case you blank out when you get the question, but don't come up with an answer and memorize it. The point of these questions is to demonstrate that you're cognizant of team dynamics and the need to manage and navigate them.

No, you can't spot a memorized story. You can possibly spot a poorly memorized story. It's the difference between learning a speech off by heart and knowing the material backwards.

Without probing questions, no. On technical matters and some interpersonal matters, though, you can use a variation of 5 Whys to quickly drill down on certain decisions or details. The only way to pass that is to actually know what you are talking about.

Exactly. Memorize the incident, what you want to convey about it, and how to emphasise your angle on it. Don't rote-learn a single telling, and don't blow it off and think "ok I'd talk about that time I saved the orphans, next!"so that in the interview you're all "I was on my way back from preventing a bank robbery...wait no, it was a mugging...and i went past the orphanage on 5th Ave, or 6th, you know the one?"

Reply on news.ycombinator.com