Hacker News Reader

I've been pondering my thoughts on this, and I'm curious what you think.

Would you prefer Phone Screen +:

A) FANG/Valley style interviews multiple rounds of leetcode algorithm/data structure style questions and some whiteboard design/architecture.

B) Pair Programming. A few rounds of pairing on a problems to see actual code. Maybe some lightweight whiteboard design/architecture.

C) Take home challenge/assignment that you work on/add features to/add tests/talk about during your onsite.

I would go for pair programming.

The danger with pair programming is you easily get a partner who sees the activity as a competitive exercise / dick measuring activity* , and some engineers find enjoyment in proving to everyone else (including new hires) their superiority.

*excuse my language, but it is the most accurate description I could come up with.

i'd posit that if an employer can't find a decent pool of current employees to potentially pair program with an interviewee, they have deeper problems than getting that upcoming interview right, and need to correct for some past hiring mistakes ASAP.

i would definitely be looking for employment elsewhere if i my co-workers were so unpleasant that i thought they'd turn every pairing session into a pissing contest (and i say that as someone who generally prefers solo programming as far as immediate enjoyment goes, but who finds that pairing is often useful and/or necessary).

And then you know that employer has issues and to avoid them.

Yep. Exactly. Pairing is a two way street.

Idiots have a negative impact on any type of job search. I have been in interviews where I showed a valid solution for a problem but failed because it wasn't exactly the one the interviewer wanted. On the other hand if I did pair programming with somebody and it worked well this would be a strong indicator for a healthy comonay culture.

That's actually another reason why pair programming is good: The interview is just as much a signal to the candidate as it is to the employer. If the developer he's pair-programming with is a douche, it's a good sign for the candidate to run and not look back.

If you're asking for C with 4.5 hours of work (as per example above) that's fine if you're paying for their time.

Cheaper than a bad hire, stops you missing out on good hires who think "fuck that".

If C should be paid for, then should A be paid for as well? If not, why not?

In A both the interviewer and the interviewee are giving a similar amount of time. In C, only one is giving time. To compensate, the other should give money.

In C the interviewer is also spending time reviewing the assignment. Maybe not the same amount, but if you also have a handful of your current devs review it and give their feedback, the company time spent on it might not be trivial.

Also there is usually more than one person sitting with the interviewee when they come in, so the company time spent is multiplied at that stage.

> Cheaper than a bad hire, stops you missing out on good hires who think "fuck that".

Does it? If I have a developer job then I'm paid well and don't really care about the money which I have enough of, I care about the time which I have very little of.

If you're in the top 0.01% of companies to work for (and the applicant knows that) then it's probably a worthwhile time investment, but for the other 99.99% it's a waste.

If you are interviewing with a company, asking you to spend time in exchange for money is reasonable. If you feel you are above that exchange, personally, that is an effective filter for a potential problem employee.

> If you are interviewing with a company, asking you to spend time in exchange for money is reasonable.

These tests are typically a pre-interview step and they don't really work well for much apart from that. So at this point I'm not interviewing with the company and all I know is that they have an interesting job ad. Considering how far from reality job ads can be I'm not going to waste hours based on one.

We used to do C for open source stuff that we contributed to at our organization. Seemed like a good comprise because it isn't a completely futile exercise for the person going for the job.

B) for sure. i haven't had that used as an interview technique on me, but i've been on the interviewing end of that, and the feedback from the candidates was great. additionally, we felt it gave a great sense of what it'd be like to work with them, and based on the people we've hired so far using pairing as a component of the interview, it's a better predictor than anything else i've ever seen.

we also ask for a presentation on prior work or a prior project, we do some architecture whiteboarding, and we have talkier personnel type parts. but currently, the hour and change pairing exercise is the only programming exercise, and we were happy enough with the results last summer that we're doing it again for an upcoming round of interviews. our setup was a PM, a tech lead, and a "driver" (the person at the keyboard, which is what i was in the exercise). interviewee is the "navigator" (and by not having to type, we get rid of some of the stage fright for syntax errors and such, and just get to see their thought process since it's a pretty compressed timeframe). best microcosm of real work i've seen. one important thing is to give the same exercise each time (one possible risk in our case was that we gave the candidate 3 possible things to choose from, but settling on what we thought was the best choice was part of the test, and all the candidates ended up passing that part, so we never had to compare WIP from two different coding exercises).

apologies for rambling or repetition, dashing this off before i go to bed. but i'm a big fan of this interview approach, and i think it's probably the best thing we've hit on so far in this field, for positions where that would be a reasonable microcosm of what day-to-day work is like. i think it's much better than making someone code on a whiteboard, or giving them a take home or solo exercise, because you get so much more info about other things besides how well they can bang out a single well spec'ed piece of code.

100% I prefer B. I'm happy to walk through code with someone, open source preferred, and show them how I'd go about changing it.

The idea of using a whiteboard to do software engineering is like asking a cellist to use writing to play Bach.

On the contrary, when I was last looking for a job, I hit a snag in that a company wanted examples of current projects, but I had none because I don't really program outside of work (I have other hobbies).

I wish I could add more to my anecdote, like how I solved this problem, but I avoided it entirely by taking a job offer from a different company the next day.

>I don't really program outside of work (I have other hobbies).

Oh, that's really no problem at all! Not everyone can just be at home in front of a computer all day, both at home and work, coding all day. What kind of a society would that lead to, haha. Anyway thanks for coming in, we'll be in touch.

Yep, also had that problem for years and finally saw something I could build with a reasonable chance of being useful, strictly to serve as an example. Hopefully it makes me the time back someday.

Funnily enough, nobody has asked to see it yet. They all want you to have side projects, but they don't actually want you to drone on about them for an hour. All this time I could have just been saying "Yes, let's talk about the intricacies of accounting for an hour, it'll be great" and passing that part of the interview through sheer aversive stimulus.

I really don't get this interview process, and why it's so ubiquitous. I wouldn't care if an interviewee could pass a whiteboard fizzbuzz test if he/she provided some samples of projects they've done. That would tell me much more about your proficiency and methods.

I'd be much more interested in finding out if we would have a cultural fit. You can teach certain skills, but if your personality doesn't fit the culture it's going to be a bad experience for everybody.

Exactly this. A lot of these "challenges" are about the theory but the real job is never about the theory of things.

I mean knowing the theory is a nice to have but I don't remember last time I used it on my daily job, especially after 10 years of experience.

Me: "This project you've assigned me is asking me to implement a basic REST API with 2 endpoints. Well... you could take a look at my github profile, I have at least one project that includes a RESTful API considerably more advanced/complex."

Them: "We have to be fair to all candidates, so you need to implement the interview project like everyone else."

I've never had an employer short-circuit an interview process (as in skip some/all of the BS tech screening) based on having actual, real work samples available for review.

What was once a “more objective” way to hire has become a restriction by HR departments - they will not let anyone in unless you pass whatever the bar was, in the exact way that everyone else has taken it. Have seen this at a bunch of mid-enterprise companies.

But how do you determine if someone's a cultural fit without expending your time and their time? Just seems unavoidable to me, though that's what people often complain about here. Like they want to get a job without putting in any skin of their own.

https://hashrocket.com/ had a pretty extreme interview where they flew me out to Florida to pair-program with them for a week. It was a really pleasant experience. Every day I would pair-program with someone new on production code. By the end of the week I knew exactly if it was the job I was looking for. (Great group of people though and wish I'd known how to keep in contact with people professionally in my early 20s)

So unless everyone can afford to do that, you have to extrapolate from far more limited data.

Could you elaborate on how do you go about keeping in touch with people professionally. It’s a struggle for me to even keep in touch with friends. I guess I need to sustematize it somehow, because otherwise I just don’t keep in touch with anyone. I’m 30, so it’s an issue.

So 8 hour onsite interview is ok for you, but 5 hour home work is not? Where is logic in that?

Where did he say anything about an 8 hr on-site interview?

Most companies would be very happy to screen 100 potential hires with 5 hours of homework each.

Very few would be willing to commit internal time to 100 onsite interviews of 8 hours each.

So the latter sends a signal to the potential employee that their time is at least as valuable to the company as the time of the interviewer(s)

No, no it would not be okay. A couple hours over a couple different days, followed by either contract to hire or a short paid sample is how I hire, if and when I do it.

There's no substitute for actually working with someone.

An 8 hour onsite interview costs me 8 hours and it costs the company 8 hours, so they're not likely to bother with it unless they think I'm in with a good enough chance to be worth the investment.

A 5 hour homework assignment costs the company nearly nothing, but it still costs me 5 hours. This means the company has no incentive not to waste my time.

When you spend 5 hours on an assignment alone, stressed because you need a job & your time is short, only to not get a response after several email follow ups, you will see the logic.

I wouldnt do this for the same reason i worked at a gas station over taking an unpaid internship:

If the company isnt willing to make some investment in you, they arnt worth investing your time into.

The only time that sort of thing makes sense to me is for very high level positions, and then at the level of achieving a mutual vision for the direction of that department (or even the whole company for a C level hire).

For lower levels such work should be compensated, the best solution there is to do some actual work, get paid for it and then the company can make up its collective mind if they want to hire the candidate or not.

Last year a applied for an Android position at an up and coming Banking startup in London. Loved the company and what they were building, but their pre face-to-face interview process comprised of probably around 2 days of work if one were to finish it all.

It's almost as if they were trying to get me to build a whole feature for them for free, as it involved a complex UI that I knew they wanted to add into the Android app.

Maybe companies that want that level of work done in their code "tests" could offer a small amount of compensation. I had already been screened on the phone, so they knew I wasn't a time waster.

There's some trade-offs here, because there does need to be some sense of how good a developer they are if you're hiring them as a developer: the distribution of skills is so broad at each "level" (junior, mid, senior, principal), and cultures so different you need some way of understanding if they really do have 5 years experience of LanguageX, or 3 months of it repeated 20 times...

What I prefer to do is ask them to show me some example code they think is "good" (ideally their own, but perhaps from an open source project), and some that is "bad" (ditto), and write a paragraph or two on _why_.

Colleagues prefer to ask people to do coding exercises, and that's fine, I won't criticise, I've done it before, but I hate the fact we are asking people to do toy problems that don't represent real World problems.

My favourite process that I don't get to do much now (I have to conform to somebody else's policies these days), is just to sit and talk through a candidate's favourite project or problem.

Why did they choose that problem? What tools did they use? Did they consider alternatives? If it was a personal project did they write tests, and why/why not? If it was something they were paid to do, how did they input vs other people, etc.? Get a sense of them, try and build some empathy for what makes them excited.

Get somebody in a room with a coffee and just listen to what makes them not shut up about some code they worked on. It can't be the be-all and end-all, but it's better than asking for another todo list app.

And then I also like to do an architectural thinking exercise. "Let's pretend we're building [well known piece of software] from scratch. What do we need to build, what do we need to think about?". Go through it, you draw their idea on the whiteboard, not them. Ask which technologies they know about for each piece. Find the edge of their comfort zone.

All more useful to me and my assessment of somebody than asking them why manhole covers are the shape they are, how many windows there are in a nearby city or asking them to build a scaffold generated app that nobody would ever use.

> Why did they choose that problem? What tools did they use? Did they consider alternatives? If it was a personal project did they write tests, and why/why not? If it was something they were paid to do, how did they input vs other people, etc.? Get a sense of them, try and build some empathy for what makes them excited.

> Get somebody in a room with a coffee and just listen to what makes them not shut up about some code they worked on. It can't be the be-all and end-all, but it's better than asking for another todo list app.

> And then I also like to do an architectural thinking exercise. "Let's pretend we're building [well known piece of software] from scratch. What do we need to build, what do we need to think about?". Go through it, you draw their idea on the whiteboard, not them. Ask which technologies they know about for each piece. Find the edge of their comfort zone.

I've seen your interviewing approach in action and it works brilliantly. This is pretty much a step-by-step of the way my last hiring manager interviewed and he never failed to build very strong dev teams.

I can't agree more.

If a company asks cookie-cutter questions and gives out cookie-cutter exercises to complete, then they shouldn't be surprised when they also make a number of bad hires that were just developers that knew how to pass these "tests".

On the other hand, as you say, if you sit down, ask them to talk about their experience, and shut up and listen, you're going to learn really quick if they are a BS artist or actually know what they're doing.

I also really like your idea of working through problems with the interviewer. I imagine it gives the interviewer some pretty important insight into how well the person breaks down a complex task into some semblance of an architecture, as well as how good they are at keeping such an architecture clean and simple.

I was discussing this with a friend just last week. He too believes it is wrong to ask for a home assignment. But I have serious anxiety problems so I find whiteboard coding tests terribly difficult. Same thing with pair programming -- it's fine when you know the other person as colleague, but impossible for me in a "judgy" interview situation.

I'd rather do it at home.

Sure, that makes sense. It's also probably accommodating to people with disabilities as well.

The part I have the major problem with is the average length. Peak was 8 hours, I just chuckled and said thanks but no thanks.

2 hours? Sure. No problem. Even 3 hours is fine.

Agree. The discussion with my friend was actually sparked by the home assignment someone asked him to do. That was easily a 10-hour job. That's way too much. He correctly declined.

Once a potential employer baited me into writing a module that would determine a sentiment from given text and few more things. They liked what I did so they invited me to face 2 face interview. During the interview they had given me a task to integrate my code into their product's API and explain to his developers everything as I went along. I completed the task and their product's API has been enhanced. They thanked me and told me they'll give me a feedback in few days. After a week I got an email from them saying I am great, but I wouldn't be good cultural fit. Out of curiosity I checked their API month or so later and they had my code in production (or whatever left from what I did). Have I got scammed?

Yea, I got tricked into doing something like that once. It is infuriating to see a new feature announced in a software product that's identical to an interview 'homework' assignment you had been given a month prior. "Wow, great solution! However, we've decided to go in a different direction..."

Whether they directly used my solution or gave that problem to several interviewees and picked the implementation they liked best I couldn't know. But I certainly felt used. There's a certain popular piece of software I refuse to use to this day because of my experience interviewing with them (fortunately, they have competition now).

Eventually you get to a point where your gut will tell you whether an 'interview project' is a toy problem or something that might actually be useful.

Bear in mind that if they didn't pay you, and there was no signed contract, they do not own your code. You may not be willing to hire a lawyer, but you could have some fun harassing them anyhow.

That said, do be sure it's your code... pretty much by definition, if you accomplished it during an interview, they could accomplish it in the same or less time themselves freshly and legally... for all you know, they'd already written it, just hadn't deployed it yet, and were using it as an interview question precisely because they had just written it themselves and it was fresh on their minds. Given the prevalence of NIH syndrome, this would even strike me as the most likely explanation unless you have some sort of really solid proof it's your code... generally, even when a programmer should take somebody else's two or three hour work they'd rather do it themselves!

I think it's because of the blowback on whiteboarding interviews. Damned if you do, damned it you don't.

I'm in this situation myself and I'm quickly reaching my breaking point.

In one instance, I submitted an "exercise", which I spent ~six hours on, one week ago and haven't heard _anything_ back -- not even a confirmation that the submission was successful. I had been on the fence about following up, but fuck that, I'm going to do it right now. Thanks for the nudge. ;)