It's hard to believe, but, starting mid-october 2023 I conducted 60 technical interviews and hired 10 people into our team. It's been extremely tiring: around 80 hours of active interviewing, plus writing interview reports, plus screening CVs and take-home assignments, plus onboarding new members — all while doing my normal work stuff. Still, I feel like I learnt a lot in the process — things that would help me as a candidate in the future, and might help you land your next job.

Note that I'm a fairly relaxed interviewer, and, as an internal startup of a large tech company, we generally have a more humane hiring process, so your mileage may vary. Still, I've done my best to pick the tips that I feel are universally applicable.

Here are nine insights I took out of this experience, in no particular order:

Be generous with your "expected income".

Say you're a solid higher-middle engineer, and you ask for a senior salary. My thought process: OK buddy, it's a bit more than reasonable now, but I won't have to fight for your promotion 8–12 months from now when you get there, and I don't have to spend another 12 hours of my own time (and leave my team understaffed for another few weeks) looking for a real hardcore senior, so I'll let you have it. Now suppose you ask for a junior salary. It's suspicious — why is your bar so low? Is there someting about your work performance you're not telling us? So, do your research on reasonable salaries for your level of experience, and aim slightly above that.

Ask the right questions.

I always leave time for the candidate to ask me questions — obviously, this lets the candidate probe what it's like to work at our team, but it's also the best opportunity for me to learn what really matters to the candidate. I've never been much of an asker myself, but now I see that "Thanks, I have no questions" does not look good — if anything, it paints you as someone who doesn't care. Here's a short list of good questions:

1. What does the daily work in this role look like? Harmless.
2. What features are you building next? Caring about the overall product, nice. Sometimes the answer is "I can't disclose this secret", but not that often.
3. Anyting about processes or team structure: how many people are on the team? How often do you release? What regular meetings do you have? Interested in organization, might want to be a team lead someday, great.
4. Anything tech-related: which framework do you use? Why did you pick framework X? How do you test your app? Especially suitable for junior- to middle developers who are most involved in hands-on work.
5. What kind of tasks do you see me doing? Again, just a good neutral question, because responsibilities for any role differ wildly between companies.
6. What growth / promotion opportunities does this position have? Cool trick, flipping the feared "where do you see yourself in 5 years" question against the hiring manager.

Here are a few questions that are not very good:

1. Do you use jira and github? It's a minor detail, won't you be able to work with youtrack and gitlab?
2. Do you sometimes work late? Only if something breaks, but overall this question makes you seem a bit lazy. People on poor teams that routinely overtime aren't likely to answer this question honestly, at any rate.

Social skills matter.

I understand that not everybody is super outgoing, but if we already feel awkward 1 hour into our acquaintance, why work together — to feel awkward for months to come? Just a few tips anyone can follow:

• Be energetic. You're tired, I'm tired, we're all tired of endless interviews. Are you just tired today, or generally always too tired to get anything done? I know it's easier said than done, but try and show me all the energy you have left.
• Show respect. People enjoy being respected. Very easy one: you have a great product. Sounds like you have a great engineering culture. This is one of the most interesting interviews I've ever seen. Like, I know you don't necessarily mean that, but subconsciously I'm very pleased: "oh yes, I'm very proud of my interview process, thanks for noticing"

On a related note...

Provide conversation opportunities.

Q: Do you use TDD? Bad answer: "no". Good answer: "no, but I've heard of it. Interesting approach. Does your team use TDD?" Now you get to spend 5 minutes talking on your terms instead of being bombarded with random questions, and you come off as someone curious about stuff.

On another related note...

It's easy to hurt people.

People normally ask you about stuff because they care about it. So, again, the interviewer askning "do you use TDD?", presumably, likes TDD and uses it. So, the worst answer: "no, TDD sucks, it's pure waste of time for idiots." A rare interviewer might appreciate you having a strong opinion on a topic, but to most this just paints you as a jerk, kinda like "Here's a photo of my children — "I hate children, and yours are especialy horrible". Not smart.

Smart talk is not your friend.

Saying stuff like "our front-end guild evaluated several cutting-edge approaches to testing universal applications" only makes you seem smart if you can elaborate on that topic: what these approaches were, the pros and cons you found, what tradeoffs you made for your final decision. If you can't answer a follow-up question beside "we settled on jest, not sure why", it was better to stay away from that topic altogether. Related: "in code reviews, I always consider the optimality of the algorithm selected" (proceeds to estimate the time complexity of comparison-based sorting as O(1). I never ask this unless the candidate boasts about her algo skillz).

Admit your mistakes.

Don't know an answer? Your code has a bug? It's always better to admit it and then try to come up with something at the spot than trying to talk your way out of it. Event loop? Sure thing, I'm an expert on loops. It's the way events are looped. Uses logarithmic weighing. Again, this makes you look like a candidate with big mouth and small hands. I have seen a couple of people who could talk their way out of any situation, but I honestly think with such skills you'd do better in a different line of work, like international relations, or selling financial services. Note that you really should give it your best shot — giving up at the first sign of trouble is not a good impression. If you genuinely have no idea — see conversation opportunity: "Event delegation? Tough luck, never heard of it. Would you tell me about it so that I learn something new today?"

Make yourself memorable.

It's hard to keep detailed profiles of 10 candidates in mind — after a good interview streak all I remember is the general impression (great / OK / horrible) and a few truly notable things. This guy worked for some crypto scam that went bust, that girl had a cute dog that was trying to eat the camera. The worst you can do is be a totally neutral candidate — we've had an interview, but I can't remember any details. So try and sneak some anecdote, or wear a silly scarf — something to remember. This point is especially important for intern / junior positions — online JS bootcamps do a good job of covering the basics, and it's really hard to differentiate these candidates. The memorable thing doesn't have to be professional, or even positive (even though it sure won't hurt) — your best bet would be some original personal project.

Ask for feedback on the spot.

Asking how you did at the end of the interview doesn't hurt. Yes, some interviewers will be hesitant to answer — at large companies, the feedback is normally sent through the recruiter, and you're never sure if sidestepping this process would get you into trouble. Besides, if the feedback is not complimentary, you're essentially asking for conflict at the spot, and people normally avoid conflict when possible. Still, it's a chance to adjust your expectations (if the interviewer says, looking you in the eyes, that you've done great, it's a good sign), and you might get actually useful tips that would probably get lost passing through the written report, and then through the non-technical recruiter.