Live data from Hacker News

Three questions to turn the table during technical interviews

bellmar.medium.com

111–114 of 114 posts

Re: Three questions to turn the table during technical interviews

#111

Earlier quoted context omitted.

Plus any professional place will obviously have processes and rules in place to not discuss other candidates with a candidate. Sure you might be curious to know, but that is a waste of breath to ask an interviewer during a technical interview. Ask the recruiter if you must.

I have asked “How do you feel I can improve as a candidate in the future?” Basically asking for a mini retro at the end of the interview process. I have found it acts as a decent proxy for how strong/weak I have done. But it also allows me to get some feedback to improve for future interviews. There has been at least one job that me asking this question directly resulted in an offer as well.

Asking for feedback at the end of the loop is great. A bunch of mega corporations are specifically instructed to give you absolutely nothing, but it's always worth asking.

Re: Three questions to turn the table during technical interviews

#112

Earlier quoted context omitted.

I like the middle two questions a lot, and I try to ask them as well. I think the other two are flawed, though: > What are the bad things about this job? Too vague. Most interviewers won't be ready to shit talk their employer with this question and will say "nothing." A better question would be some variation of "What would you change about the way your team works if you could?" Frame the question properly so that th…

> Most interviewers won't be ready to shit talk their employer with this question and will say "nothing." I don't think that's true. During times I've been an interviewer, I've been open about the bad parts of the job. And if everyone tells you nothing , then that in itself is valuable information - that they're all fucking lying to you.

"Bad" is relative. Someone may believe that something is industry standard and not worth talking about e.g. crunch time in games. Also, plenty of people internalize the bad bits of their jobs and won't think to discuss them unless you ask specifically. It's like asking for feedback from colleagues to their face, unbounded requests for criticism are psychologically hard for humans to answer.

Re: Three questions to turn the table during technical interviews

#113

> “There’s an IC sitting out there who just had an amazing idea for a new feature/product. What happens?” Man, I bet my answer and my VP's answer to that are gonna be rather different.

Maybe the question could be sharpened: "Can you tell about some examples where an IC in your company had a good feature idea, and what ended up happening?"

The problem there is that there's always ONE example. If you ask this in a Google interview, I guarantee they will tell you that "GMail started as a 20% project."

Re: Three questions to turn the table during technical interviews

#114

Earlier quoted context omitted.

> The hiring process sucks and it sucks that this method of filtering works, but it does work. How do you know this? (That this is not just sampling error, survivor bias, and/or confirmation bias) I speculate that a good hire is almost random. Context matters as well. I worked with someone that was horrible, to later find out they were the other dev that I was going to work with later on a contract job. The different…

This filter works because people that are really good at what they do naturally tend to actually care about the surrounding tools/processes involved. Someone that has no opinions at all about those tools/processes is just showing up, and people that are just showing up are not usually as good as people that are passionate about the work. That said.. it is stupid/insulting/weird to interview assembly-line workers as i…

I take you are referring to a different filter. I was responding to:

> "the unfortunate truth is that filtering for someone who's already in a good situation is actually a really good filter "

Be what it may, the "caring about tools/process" filter I also think is fraught with issues. (1) candidate might have already been described what the tools/processes are several times already. Perhaps even up front in the job description. (2) I've learned that tools and processes need to be evolved, gently suggested. It does not go well to say, yeah, drop scrum, do fewer CRs and only when important, add an auto-formatter and all these things. Secondarily to that, those things are not necessarily that important. It is work about the work there, better often to just do the thing then to spend too much optimizing the effort to do the thing. (3) a candidate should be asked what they would change in tools and process. Volunteering that can show a lack of "business focus". (4) any issues in tooling/process might be pitched as opportunities for impact that the candidate could have. In reality those things get political and it might not be a position that is empowered to really change much. So why deep dive into that during an interview - the person is being hired to do a thing, not to just do tooling (unless it is a tools efficiency job of course!)

At the same time, I would agree that someone with no opinion likely has no breadth in the process aspect of development. Yet, does that matter? It is more important for a team to get along than to try to 10x itself by going full bore on process efficiency. The latter is a myth. Focusing on that myth likely is going to be endless meetings/discussion about process and not business problems.

What is more, tools and process are context dependent. What works at a big shop (eg: FB, amazon), or the last shop - might not work at all at the next shop.

I'll emphasize as well that tools/process are best evolved with focus on areas of greatest need. That is a learning and discovery process. Getting a clear signal during an interview of whether someone understands that, or have just followed the scrum guide without much thought could be a real challenge. Asking someone even if they follow the scrim guide is nebulous, many have not read it, they might say they have but clearly have not. Yet more, the saying of "if you're still following the scrum guide a year later, your process is not agile"

Ergo, I suspect the "cares about tools and processes" will be a noisy filter. Caring too much creates discord on a team and ultimately is distracting. Sussing out willful indifference vs indifference due to business focus (eg: "I really don't care, just point me at the business problems and the rest is bullshit that I'lljust have to suffer through"), vs just shows up. I believe differentisting that alone is a big challenge (and potentially susceptible to a variety of biases). Yet more, is that the most important thing to focus on during an interview, is that really a valuable filter? I'm not sure. Sometimes having a few people not care is good, less bikeshedding.

Post reply on HN