Tell candidates what to expect from your job interviews • Hacker News Board

Re: Tell candidates what to expect from your job interviews

#61

Post by pdimitar » Wed, Jul 01, 2020, 10:53 AM UTC

warent wrote: post #7

xen0 wrote: post #5

Earlier quoted context omitted.

I think it can only be fair to ask for feedback from a rejected candidate if you (the potential employer) are willing to give feedback yourself, which is rarely the case, especially from larger companies.

This might be what you'd think intuitively. I've conducted ~500 technical interviews, and in my experience candidates who are obvious DNP (do not pursue) often times really do not want your feedback or do not care about it, either because they think they're smarter than the whole process, or they're too busy turning inward to deal with an emotional breakdown. But those very candidates are the ones who are likely to l…

> An interviewer should be ready and willing to provide feedback if the candidate signals that it would be welcome.

And at which point would this happen, I wonder? All the interviews I went through during the last 4 months didn't have one person sound inviting along the lines of "we won't take you but if you think we can improve our process do let us know". Not one even hinted at that. It's all very... impersonal, cold and often feels like copy-pasted emails are being to sent to the candidate.

You are kind of assuming -- way too generously -- that the process and the interviewers are actually open to feedback. Most people, including in tech companies, are happy to tick boxes and check in / check out at given times of the day, and do nothing else more creative or requiring special attention (like recruiting).

---

EDIT: I tried giving feedback -- unsolicited -- after the rejection in my first 5-6 interviews. Didn't go well. You could tell people got offended by very simple points like "would have helped if you told me you will measure me with one extremely specific test while I am looking for a generalist role" or "what was the value of imposing a hard deadline on a homework while the candidate is going through several interview processes in parallel? does that tell you anything about their real productivity?", and a few others like "I am not sure that teling me 'I am not like the others in the team' is a valid point in remote working conditions where comms are mostly async and people don't chat that much". Etc.

In the end you get tired hitting a brick wall. People are generally not receptive to feedback and even react in a hostile fashion when it is given to them. Plus when you want to go through 35-50 interviews, at some point you really start counting the hours that each company is taking away from you before rejection and you figure it's not worth it to try and present feedback where it's clearly not wanted.

Re: Tell candidates what to expect from your job interviews

#62

Post by tumetab1 » Wed, Jul 01, 2020, 11:04 AM UTC

swarnie_ wrote: post #31

I've just finished this maddening process for the 4th time in my "career" and it was as frustrating as i remember. To all potential employers and recruiters: When a candidate asks you for the agenda or some indication to the structure a meeting will take its because they want to be prepared. They aren't trying to "cheat", they want to be as productive as possible. Unless your company operates some insane work methodo…

For some reason developers seem to assume that the recruiting process is immune to the regular company dysfunctions.

If they scheduled an interview without an agenda is because it's the norm to do that within the company when talking with outsiders. If someone jumps in to a call, it's their practice to have surprise guests within meetings. If someone ask you subject matter expert questions, it's how the company sees developers, as subject matter experts.

So, you were interviewing to a company which views, my guess, developers as subject matter experts, has people jump in into calls and doesn't prepare specific calls.

Re: Tell candidates what to expect from your job interviews

#63

Post by axegon_ » Wed, Jul 01, 2020, 11:19 AM UTC

twic wrote: post #35

axegon_ wrote: post #10

Perhaps a bit of an unpopular opinion but as far as interviews go, I think that seeing how someone reacts unprepared is a lot more valuable then seeing their work with them knowing what to expect. You see their ability to adapt and improvise, which is far more valuable then being picky about a particular library or technology. Yes, the quality of their tests will be lower, but that's fine and you can take that into a…

> Perhaps a bit of an unpopular opinion but as far as interviews go, I think that seeing how someone reacts unprepared is a lot more valuable then seeing their work with them knowing what to expect. You see their ability to adapt and improvise, which is far more valuable then being picky about a particular library or technology. I agree that you want to see someone thinking on their feet and tackling a new problem. B…

> I've heard people say this, but i don't see why it would be true. Is there reasoning behind this, or does it just feel smart?

Not at all. The lack of questions shows a lack of interest. In every test I've ever prepared I've deliberately left one or two questions which are near impossible to answer and no one has ever been able to correctly answer them so far. The least you can do is ask about those. Or what does the release cycle look like or how is the development being tracked - literally anything, just to indicate that you genuinely are interested and not "I simply want this job".

Re: Tell candidates what to expect from your job interviews

#64

Post by pdimitar » Wed, Jul 01, 2020, 11:23 AM UTC

jrockway wrote: post #32

hardwaregeek wrote: post #4

Also get feedback from candidates, especially rejected ones. The people who get offers will assume that the process works, since it validates their self-worth. Even if the process is very stupid. I've had processes that were so so bad from top companies. Like "here's a repo, clone it, write a program that will be judged by automated tests that you can't see". I had to basically guess what the tests were going to do,…

I think it's instructive to look at this from the other side to see why these processes exist. At my last job, I wanted to hire a frontend engineer with some experience beyond tweaking HTML and CSS (we used gRPC/Web and Typescript, so some actual programming experience was going to make them pretty productive, and that's what I was looking for). Anyway, I wrote up a req and posted it to the usual career sites, and wi…

> You have so many candidates in the pipeline that missing one good person is a cost that's acceptable for having to spend 30 minutes with someone that probably can't actually program.

VERY debatable. I've chatted with dozens of HR and CTO people during the last 4 months of interviewing and looking for a job. They all complain "there are no good candidates". Without exception. (And I know you addressed that one paragraph below this quote.)

You're not wrong that selecting good candidates is extremely hard. I know it is. But the companies have to find a way to do better. I know many examples of world-class programmers being passed on by employers who, if they actually paid attention, would kill for them (and often times they contacted them anywhere from 6 to 18 months later, only to be predictably laughed out by the now-happily-employed person).

Re: Tell candidates what to expect from your job interviews

#65

Post by Dayshine » Wed, Jul 01, 2020, 11:26 AM UTC

axegon_ wrote: post #63

twic wrote: post #35

Earlier quoted context omitted.

> Perhaps a bit of an unpopular opinion but as far as interviews go, I think that seeing how someone reacts unprepared is a lot more valuable then seeing their work with them knowing what to expect. You see their ability to adapt and improvise, which is far more valuable then being picky about a particular library or technology. I agree that you want to see someone thinking on their feet and tackling a new problem. B…

> I've heard people say this, but i don't see why it would be true. Is there reasoning behind this, or does it just feel smart? Not at all. The lack of questions shows a lack of interest. In every test I've ever prepared I've deliberately left one or two questions which are near impossible to answer and no one has ever been able to correctly answer them so far. The least you can do is ask about those. Or what does th…

> Or what does the release cycle look like or how is the development being tracked - literally anything, just to indicate that you genuinely are interested and not "I simply want this job".

What if I'm so interested in the job that I simply don't care about those things? If you're doing amazing work, who gives a crap about the small details!

Re: Tell candidates what to expect from your job interviews

#66

Post by pdimitar » Wed, Jul 01, 2020, 11:43 AM UTC

sokoloff wrote: post #53

brailsafe wrote: post #27

Earlier quoted context omitted.

Afaik, research suggests that interviewers know after 20 seconds whether they'll hire someone. I don't have references and don't know if this would translate well to tech interviewing, but I'd wager that the vast majority of a 7h interview day is totally pointless.

I wonder how much of that is like-me bias with the risk that 3 short interviews might get us (even) more homogenous employee populations?

> I wonder how much of that is like-me bias

I am just crawling out of 4 months of hell of interviews and homeworks. And I can tell you: probably 90% of it. :(

Re: Tell candidates what to expect from your job interviews

#67

Post by jeff_jefferson » Wed, Jul 01, 2020, 12:01 PM UTC

gozzoo wrote: post #36

jeff_jefferson wrote: post #21

Earlier quoted context omitted.

I think you've just failed that part of the test. If you've got more than an extremely simple project there are multiple point s where you should commit. If you implement a piece of logic with passing tests, then commit. It takes seconds to do but makes reviewing so much easier.

Or the company failed to attract the most suitable people for the job. As I said - I don't see a reason for multiple commits for a few hours project. It is not how people start a new project. This is an exploratory phase, you check this, test that. Very often it becomes a mess. Eventually your idea of the project gets clearer, then you clean the code, or start again from scratch. I don't see why these steps need to b…

By specifically mentioning this, I would imagine it is something that is important to them. Therefore, somebody who doesn't agree with this way of working is not "suitable". In my experience, hiring people (however good) who do not agree with the company's core practices doesn't end well for either of them.

Unless it is something completely new to me and I am basically "playing with the tech" (which this does not seem to be) this is exactly how I would start the project. I find it easier to be organised from the start. Especially if, when I do take a wrong turn, I can revert easily to a previous commit.

Re: Tell candidates what to expect from your job interviews

#68

Post by viraptor » Wed, Jul 01, 2020, 12:37 PM UTC

sokoloff wrote: post #54

fogetti wrote: post #47

Earlier quoted context omitted.

I am sorry but this tells me exactly one thing: that you don't know how to write a job description. If you have written your job description tailored to the ideal candidate you would have had a smaller candidate pool and a better match to the actual job.

Unless you somehow require proof that the applicant meets the requirements, I don’t see how that prevents the spray-and-pray applications.

This is not from an IT position, but my wife uses "mention word XYZ in the email subject" in the requirements. This filters out a few people who just spam their CV regardless of job description. It also filters out people who are applying to a job that really requires attention to details in written communication.

Re: Tell candidates what to expect from your job interviews

#69

Post by collyw » Wed, Jul 01, 2020, 12:45 PM UTC

Dayshine wrote: post #51

twic wrote: post #44

Earlier quoted context omitted.

There are two ways of working in programming. One is to make disciplined incremental progress: write a test, make the test pass, do minimal cleanup, commit, see a refactoring opportunity, do it, commit, write another test, see a related bug, write the bug down but don't fix it, make the test pass, clean up, commit, tackle the bug, commit, etc. The other is to flail about wildly until you have something which more or…

Sure, but I'm not sure how much progress you're going to make in the 2-3 hours one would spend on a speculative take-home task (they've stated there is no guaranteed interview). You're going to be judged on how well the end product works, so if we start with the following tasks, and you have 180 minutes. 1. 20 minutes: their stack's boilerplate/tooling 2. 10 minutes: unit testing boilerplate 3. 20 minutes: integrated…

"It should only take you 2 or 3 hours".

Estimates are almost always under.

As you point out the most basic project setup takes time. And I am working on a home laptop, not my work machine, so I don't have everything installed in the same way as I do for a work setup (that's usually at least a days work in itself on a new work machine).

Also it is not uncommon to find some strange issue that will take a couple of hours to fix if you are unfamiliar with it. Last technical test I had involved using Django's chache framework. I have used Django a lot, but not really used the cache in depth. I got everything working in the end and they failed me for the most trivial reasons.

Re: Tell candidates what to expect from your job interviews

#70

Post by Huggernaut » Wed, Jul 01, 2020, 12:47 PM UTC

odshoifsdhfs wrote: post #33

vinaysshenoy wrote: post #3

Earlier quoted context omitted.

We ( https://obvious.in ) documented our entire hiring process on our Playbook ( https://playbook.obvious.in/hiring/hiring-process/engineerin... ). Took us about a week to write everything down the first time and then we continuously updated it until it reached the current state. We had the advantage of being a "public by default" company, so there was no need for approvals of any sort.

Can I honestly ask what is the point of this question: > Why do you want to be at Obvious? I never understood this. Unless you are Apple or Google or some other big brand, most likely people found your job through a job forum or even HN and never heard of you before. Then most likely the answer is money. So what is the point? I just stopped filling up job applications that have this. Seems so counter productive. Heck…

No, it's not hard to understand, but that doesn't do you any favours.

I'm not saying that someone needs to be so desperate to work somewhere (that would probably be bad), but if a candidate can't express why they have an interest in a particular role then that's of note, especially if I'm comparing to someone who can. Pretty much everyone wants to exchange their time and knowledge for money, but they could do that anywhere, so why here?