I'm curious on how you all manage is an interview. Tell me what's up ... for academical purposes
For further actions, you may consider blocking this person and/or reporting abuse
Read next
How is Concurrency Control Maintained to Ensure Isolation?
Ujjwal Raj -
Using Django and Vue.js to create a web application on IRIS: Peeking into the Django framework
InterSystems Developer -
PHP 8.4: It's a small change, but `$date = DateTimeImmutable::createFromTimestamp(1732420815)` instead of `$date = new DateTimeImmutable(); $date->setTimestamp(1732420815);` looks pretty cool! 🤩
spO0q -
Modern Low-Code Testing Platforms
HamsterBoomer -
Top comments (5)
Admit when you don't know the answer. Too many people seem to think they need to know everything to ace the interview. No, it's for them to vet you and you to vet them. It's doing a disservice to both of you to try showing off. Just saying "I don't know the answer to that, but I'd probably start by trying A or Googling B and see where those rabbit holes take me." The interviewer may help lead you to an answer, but it shows you know what you don't know which is a huge plus on soft skills.
Assume you aren't getting the job. This could just be because I default to being an anxious overthinker, but by going in with the mental assumption that it all doesn't matter, I'm way more myself and comfortable answering and asking questions and being honest with who I am, what I know, and what I want out of the arrangement. It may seem like it's ballsy to say "I'd Google it" to a question you don't know, but secretly it's just that I assume they already think I don't know anything, so what do I have to lose by telling them my process I'd use to get to the answer I don't know?
Here are some ideas, for in the moment, when a question is asked:
LISTENING is probably the most important interview skill.
Listen attentively to each programming question so you can ask about any edge cases before jumping in. Thinking and talking about likely edge cases before getting into coding can help you remember to handle them in your code.
Listen carefully when they describe the team and role, so you can imagine what it would really be like to work with them. Try to guess what the best and worst parts of a day at that job might be, and ask about those things to make sure you understand the environment well.
Always listen to the interviewer talk about themself. If I listen actively to you talking about yourself, you'll probably consider me more likeable than if I shut you down or act disinterested. (If all they want to do is talk about themself, you just learned a valuable piece of information about that team's culture.)
If you have extra time and no real questions of your own, ask a question that'll get the interviewer talking about their own experiences with the role and company! Questions like "what do you think is the most important trait of a good workplace, and does this role have that?" or "what's your favorite/least favorite part about this company" can get them to volunteer all kinds of interesting information that you might not have known to ask for directly.
The second most important interview skill, after listening, is handling questions that you don't know the answer to. I think that only when an interview starts with questions you find easy and can easily get right, and eventually escalates to questions that you don't know how to solve, can the interviewer get a truly accurate picture of the extent of your skills.
My favorite technique for handling a question that I recognize is stumping me is to state what I'd do if I encountered it on the job. Would I check a man page? Google a particular query? Ask a mentor or colleague for help? An evaluation like "I've spent X minutes on this and I don't seem to be making progress. When I exhaust all the problem solving techniques I know so far on a real problem at work, I first search related queries to see if I've missed any avenues of troubleshooting, then ask a colleague or mentor for their advice in order to avoid wasting both my time and the time of the people who're waiting on me for a solution" has always worked well for me.
Research the company, and customize your pitch to the company (codewithoutrules.com/2017/01/19/sp...).
Whiteboard puzzles can be avoided or, at the very least, you can take control of how they go (codewithoutrules.com/2018/07/29/ge...).
Remember that you're there to assess them just as much as they are there to assess you.
If you don't keep that in mind, and spend all of your time just trying to impress your interviewers, then you can't guarantee that you truly even want to work there. But if you remember that it goes both ways, you ought to feel a lot more relaxed.
Also, tell the truth even if you think that it would sound better not to. If you only tell the truth about your thoughts, opinions, skills, and experience, then all you're really doing is having a slightly lengthy conversation - enjoy the conversation and they probably will too.