Tell candidates what to expect from your job interviews

> 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?

I recently got told by the VP of Engineering of the company I am now undergoing onboarding with, that if a senior programmer asks no questions about how the company['s teams] work and doesn't have any requirements, that to him sends the message they are desperate and don't know their value.

Other people told me that not asking anything means that the interviewee is not proactive.

I did not say it is a chore. I wouldn't be doing interviews if I didn't like it.

I just said it is difficult to do all of these well within 2h limit. This was to contrast with other people balking at longer interviews.

Also, if I ask the candidate a question or give a coding problem to solve I expect them to be intelligent enough to understand I don't want them to google the solution. Everybody knows what the interview is and what it is for.

If I wanted them to google the solution I would ask to perform the task at home EXCEPT I find giving the task to be done in own time unfair and unethical practice.

It is unethical because by spending no effort at all I am motivating potential candidates to spend huge amount of their own time to polish the solution as much as possible.

It is unfair because it does not let me to get to know the candidate at all. It promotes candidates who are willing to waste huge amount of their time.

Below are two examples of recent preparatory information given to me before interviews with two different companies. These are samples. I did not spend a few hours on each of these examples, but a few hours in total for each company. I probably spent Example 1:

"This interview is for your cultural fit. The interviewer will ask a series of 'tell me about a time when' questions. The core values of the company are x, y, and z."

So I spent a few hours reviewing those core values, and making sure I had anecdotes to cover each that represent me and my experience well. I rehearsed these answers, and made sure that I could articulate how my answer aligned with a specific value. I didn't have to flail around on the spot with no understanding of what the interview would be about. I didn't waste time in my answers talking about technical details that aren't relevant to an interview that is focused on personality and experiences outside of the technical.

If I did not know what the point of the interview was, I could easily respond to, "Tell me about a time you had a disagreement with a teammate and how you resolved it," by focusing on a technical challenge, and giving background on the technical details. If the interviewer weren't too good, or was just having an off day, they might not press to get details about the soft skills involved in solving disagreements that was really the point. This could easily become a failed interview question where they consider me obtuse and focused on the technical details at the expense of interpersonal ones.

With expectations firmly set and my own prep to make sure I had that story and that focus locked and loaded, I can make sure to focus on how I made sure all parties were heard, and that how I helped to foster a productive conversation, and how I made sure that I could back my side up with facts and figures, and how we had a reasoned discussion, and how we made a good decision in the end.

Then the interviewer doesn't have to keep digging when I gave an answer all about technical domain challenges. Then I don't have to feel defensive because the interviewer is digging. So we both have a better time in the interview. And I avoid being marked as "do not hire" for answering the question wrong without knowing.

Example 2:

"This interview is a high level technical interview, focusing more on systems architecture than code. You will be expected to whiteboard but not write code. Our interviewers will have several scenarios to choose from that focus on the following topics: a, b, and c."

So, I looked at that company's product offerings (this was for a customer-facing engineer role), in order that I might be conversant in their technologies. I looked for any whitepapers or blog posts about the topics, and made sure I was familiar with the architectural challenges of the topics provided. I made sure I understood how their products could fit together in a larger architecture, or where integration with third party systems was viable. These are not topic areas unfamiliar to me, so I'm not embarking on a full curriculum to understand these, but focusing my time on the topics I know will be covered.

I didn't waste time grinding leetcode, or even reviewing anything algorithmic for this interview.

When the interviewer presents a scenario, I don't waste time in answers that include fine technical details, such as how to configure the various services involved, or how one might program a solution to the scenario presented. I know I'm expected to whiteboard, so I make sure to illustrate as I am talking.

Again, my prep makes sure I'm on topic, so I don't depend on my interviewer guiding me to the right level of answer. A poor interviewer might let me go on for a long time, so that we can't finish in time. I would blow my chance by spending too much time in the weeds to get through everything they wanted to.

Even if I have a good interviewer who gets me back on track, if I've focused on grinding leetcode for this interview, I don't have systems architecture on my mind. I'm flailing around trying to refocus. Even if I get back on track, I'll have a much poorer showing than if I answer the questions appropriately (note, appropriate correct) to start with.

Separately from the examples given, there is another question of how well the interview topics fit the job. I am opposed to algorithmically-focused coding interviews for positions where it is not expected that the person in the role will have to implement algorithms as part of their day-to-day responsibilities. That said, if you are applying for a role where deep algorithmic experience is required as part of the day-to-day, then I would expect any decent candidates to not need to grind leetcode. If you're already doing this stuff regularly, then it should be a matter of brushing up, rather than grinding.

Technically, company is not a single mind that could have a viewpoint on something. It is a group of people, who sometimes have different incentives. Maybe someone's incentives make this a good strategy, even if it is harmful for the company as a whole in long term.

I don't know how exactly people in HR are rewarded, but I have noticed a few situations where the company had a generous salary range in mind, but HR fought against mentioning it. It didn't make sense from the company perspective, because the company wanted the people, and the salary was above market average so the potential candidates would have liked it too. The resistence of HR makes me suspect that their incentives didn't align with the company interest, but I have no idea how specifically.

I meant to be less specific than "hire someone", but I'd wager that once a subconscious impression is formed, you'd be more likely to bias your interpretation of whatever else they say.