Live data from Hacker News

Always Be Coding – How to Land an Engineering Job

medium.com

221–230 of 250 posts

Re: Always Be Coding – How to Land an Engineering Job

#221

Earlier quoted context omitted.

You don't have to decide during that interview. You can take your time. Look at the candidates' source code on github, bitbucket, look at their mobile apps, disassemble them, take a look at how well they write software, etc.

How could you verify the code is actually theirs in just one hour, and not something they've been coached on? The stakes are so high that we already have an awful lot of blatantly unqualified people trying to bluff their way through in-depth interviews, and making that easier is a huge step backwards.

> How could you verify the code is actually theirs in just one hour

You don't have to review the code inside of one hour. You can take as long as you want on that. The point was that when talking with them either on the phone, in person, whatever, you take only an hour. Code review can take as long as you please. I highly encourage you to look at source code before making a hiring decision.

Re: Always Be Coding – How to Land an Engineering Job

#222
post #9

Really good post, thanks David. I'm really curious as to how you landed an interview at Google (let alone a job) without a college degree. My understanding is they are very strict about that and it's hard to even get a foot in the door without a degree. [disclosure: I'm on a 10 year "hiatus" from my senior year in college]

I was contacted by Google without them knowing I had a degree, although they knew by the time I was scheduled for an interview. Apparently washing out in round one of Google Code Jame 2012 was enough for them to seek me out. I performed to expectation by similarly washing out of the interview. Steve Yegge wrote that you should apply to Google, no matter whether you think they'll take you or not, because it's a desira…

This presumes that a) You want to work at Google and b) You consider Google to be doing interesting stuff that it would be worth applying. I don't. They aren't.

Re: Always Be Coding – How to Land an Engineering Job

#223
post #119
post #98

Earlier quoted context omitted.

When I was talking to them I was informed the hiring process usually took around 8-9 weeks. First a screening call, then a phone interview, then sometime later an in person interview, then an evaluation day in a Google building with multiple interviews and talks with various parts of various teams, then they would let you know within a couple of weeks. Yeah, no thanks.

The process may span 8 or 9 weeks, but you'd probably actively spend about 8 or 9 hours. That's a couple hours on the phone, and 5-6 hours on site. Presumably, you expect to hold the job for next few years of your life, at a minimum. If you can't budget 10 hours of your time, and you can't wait for a few weeks for an answer, it just doesn't sound like you really want to work there. Unless you're in desperate need for…

I only have details for two people going through their interviews, but one of them took about 16 hours of in person time, and the other involved flying out to a different city for a day of interviews after ~6 hours of phone screening + a clusterfuckload of email time (partly due to some monumental incompetence on behalf of their HR department: when the recruiter involved left they said they had to restart the entire process).

Re: Always Be Coding – How to Land an Engineering Job

#224
post #51

Earlier quoted context omitted.

Exactly! This is why we, at my job, only hire software engineers after a (paid) two-day test period in which they actually build some new feature on one of our products. Nothing too fancy but interesting enough for them to be a challenge and representative enough for us to see what they're capable of. At least as important: they will have lunch with us, talk with us, have fun with the rest of the team, ... This allow…

How do you cope with people who are presently employed but want to interview? Do you expect them to find two days of absence from their present employer to test themselves at your company? I mean for me that's no problem, but I don't live in the US and therefore have pretty liberal employee leave arrangements. I know that many companies in the US are a lot harder on giving out leave. That said, it wouldn't surprise m…

Yes, people who are currently employed will have to take a few days off for this. As we're in The Netherlands that is usually no problem. One of the reasons we pay people for these two days is to compensate them for the two days off they'll have to sacrifice.

Re: Always Be Coding – How to Land an Engineering Job

#225
post #132

Earlier quoted context omitted.

Exactly! This is why we, at my job, only hire software engineers after a (paid) two-day test period in which they actually build some new feature on one of our products. Nothing too fancy but interesting enough for them to be a challenge and representative enough for us to see what they're capable of. At least as important: they will have lunch with us, talk with us, have fun with the rest of the team, ... This allow…

How big is your company? I can't imaging this scaling. This sounds good in theory, but I think one could only hire 1) people currently unemployed or 2) new grads who haven't had jobs. Also, I imagine plenty of good engineers balking at this type of time commitment in building out a feature when the company should likely be proving why the engineer would want to work there? Is your stack that simple that someone can g…

We are a small startup, currently with 11 people. You are right about the scaling issue, I suppose our approach would be more difficult in a large organisation. But why would we only be able to hire unemployed people or new grads? I joined this company myself when coming from another job, as did a colleague that was hired later.

Proving why an engineer would want to work with us is exactly why we interview with this system of two try-out days. How can we possibly convey that we're doing cool stuff in a one hour talk around the table? Besides, we think the try-out is not only for us to "judge" the candidate, it's also the ideal time for the candidate to see if he fits our culture and way of working, and if he actually likes what we're doing. Hiring someone that decides to leave a month later is waste of time for all people involved :-).

Of course we also do the regular "around the table" interview before we invite someone to work with us for two days. We have a chat of about an hour, tell the candidate we will contact him and then have some internal discussion. If everyone agrees we invite the candidate for a two day try-out. If we feel the candidate fits our company and we like his work, we usually try to make him an offer on the second day.

Concerning our stack: it's all Ruby and Rails, and a lot of Amazon Web Services. Our engineers all have at least 3 years of experience with Ruby and Rails (or similar) and we are usually only looking for somewhat experienced people. We simply don't have the time nor the budget to train a new hire for a few months. To get going on a try-out feature a candidate usually only needs Ruby, git, an editor and a small introduction to our codebase from one of the engineers. Most of them are productive within two hours of entering our office on their first try-out day. Of course these try-out features are very isolated and require little to no background knowledge of the entire codebase. Once the candidate is hired we will take sufficient time to get him comfortable with the code.

Re: Always Be Coding – How to Land an Engineering Job

#226

Earlier quoted context omitted.

Exactly! This is why we, at my job, only hire software engineers after a (paid) two-day test period in which they actually build some new feature on one of our products. Nothing too fancy but interesting enough for them to be a challenge and representative enough for us to see what they're capable of. At least as important: they will have lunch with us, talk with us, have fun with the rest of the team, ... This allow…

I forget the exact details but my current employment agreement has a paragraph saying I won't do contract or consulting work while I am a full time employee here. Ethically, I would never be able to interview for your company. Don't most companies like tech companies operate in a similar manner? If so, aren't you limiting your hiring pool to either programmers without those types of agreements or thise whom are ethic…

Interesting point! As far as I know we've never run into this issue. We are in The Netherlands, so perhaps that makes it easier. However, were this ever to become an issue with a particular candidate, I'm sure we are flexible enough to work around that. The two day try-out isn't set in stone, it's just a way for us (and for the candidate) to see if we like each other. There are plenty of other ways to solve that if a try-out poses legal issues.

Re: Always Be Coding – How to Land an Engineering Job

#227

Earlier quoted context omitted.

> But, at least here in the US, we currently have way more demand for good developers than we have supply. Basic economics says that your model will not work. The problem is that hiring someone who can't code doesn't help me. And a bad engineer is worse than no engineer at all. It's not like a grocery store where a bad employee is just really slow and a really bad employee steals things costing me a percent of a perc…

> A single bad engineer could theoretically destroy a company if they were savvy enough. This sentence does not compute. Anyways, I think a big portion of the "hiring problem" is that companies are too afraid of hiring a "bad" developer. They somehow have this notion that if they fail to hire a great developer then its no big deal, but if they accidentally hire a bad developer, their company will all go to shit. This…

I think bad in this sense is malicious as opposed to incompetent.

Re: Always Be Coding – How to Land an Engineering Job

#228

Earlier quoted context omitted.

No one here is objecting to being tested and challenged. People just want to be tested on how well they can actually perform the job and build solid products, not how well they can memorize algorithm implementations. It's like screening Marines based on whether they can build a rifle by hand. It's a cool skill and could be useful in some ways, but it's not the job.

Hiring is a two way process. They're looking for employees, and you're looking for a salary, colleagues, boss, etc. A company that fucks up an interview fails. My toughest interview process involved driving 200 miles to spend a day doing psychological tests (after my interview). I got the job. Really, the hirer failed the interview, but I wanted out of my current job. Whose fault was that? Turned out to be a great jo…

I have lost jobs based on those bullshit, pseudo-scientific psych tests. Some of them are straight out of the back of an issue of Cosmo. If I was a moral-less dirtbag I would still have scruples about trying to sell a company on personality tests as part of an interview process.

Re: Always Be Coding – How to Land an Engineering Job

#229

Earlier quoted context omitted.

> A single bad engineer could theoretically destroy a company if they were savvy enough. This sentence does not compute. Anyways, I think a big portion of the "hiring problem" is that companies are too afraid of hiring a "bad" developer. They somehow have this notion that if they fail to hire a great developer then its no big deal, but if they accidentally hire a bad developer, their company will all go to shit. This…

I think bad in this sense is malicious as opposed to incompetent.

There is almost nothing about multi-hour coding interviews that does anything to filter out the malicious, unless they happen to be incompetent as well. Screening out malicious people is a very hard task.

Re: Always Be Coding – How to Land an Engineering Job

#230

Earlier quoted context omitted.

> But, at least here in the US, we currently have way more demand for good developers than we have supply. Basic economics says that your model will not work. The problem is that hiring someone who can't code doesn't help me. And a bad engineer is worse than no engineer at all. It's not like a grocery store where a bad employee is just really slow and a really bad employee steals things costing me a percent of a perc…

> A single bad engineer could theoretically destroy a company if they were savvy enough. This sentence does not compute. Anyways, I think a big portion of the "hiring problem" is that companies are too afraid of hiring a "bad" developer. They somehow have this notion that if they fail to hire a great developer then its no big deal, but if they accidentally hire a bad developer, their company will all go to shit. This…

Agreed. Many people parrot this line, but I have not seen anyone put actual data behind it. I have seen made-up scenarios about what could happen. Those usually stick to near worst case situations, though, with no indication of the actual risk.

People also seem to minimize or ignore the cost of a no-hire. If your company has an open position it is trying to fill, it should be feeling pain. Work isn't getting done. Projects or clients can't be bid on. Current engineers are working overtime to meet commitments. If you can look at this situation, shrug your shoulders, and say, "Eh, we're going along fine. We can wait several months for a perfect fit.", then I think you need to re-evaluate why you have an open position in the first place.

I would like to see some actual data to back up this conception. Something that gives the actual statistical risk. As someone mentioned on another story here recently, humans tend to over-estimate the risks of negative events. I think the risk of bad hires in SV has been seriously over-estimated.

Post reply on HN