Apologies in advance for the finnicky video sync - we had some hardware issues that unfortunately I couldn't fix in post. Fortunately the audio is stellar!
This was a lot of fun @hello_interview! Thanks Stefan for having me and I hope it's helpful for all the SWEs out there prepping for interviews. Feel free to ask any questions you might have and I can take a pass.
Great insights on lot of topics Austen! Thank you. Q1: Any specific advice for someone who is not working currently and finding it hard especially to explain their situation to HM? Q2: What are specific signals HM look for especially in these type of candidates?
Thanks Stefan, great questions! Applying for Staff+ roles and I appreciate the thought that has gone into coming up with these questions. Relevant and relatable
This clears up so many things I had about behavioral interviews, wish I saw them before I went through all my interviews. 😅 This is probably the most useful advice video I've seen about behavioral interviews for more experienced candidates. I feel like a lot of behavioral advice is geared towards entry level folk.
Thanks @thebehavioral and @hello_interview - this is really helpful to prepare and start with. I am looking for some help with following questions: 1/ What to consider while appearing for EM vs Sr. EM role? Some of the major difference to take care while choosing example of situation and some of the tips while answering? 2/ I have often seen similar questions in both Behavioural and People Management round, what type of signals interviewer is looking both the round (separate list of signals)
Thanks for the video! I would like to know more about project archetypes and conflict archetypes. Would you be able to enumerate them? I think it will be helpful for candidates to see which of their experiences best fit which archetypes so they know what information they can omit when storytelling
These aren't well established or an industry standard or anything---I bet Kent Beck has some list somewhere, lol---but here it goes... On projects: * Business identifies need for [feature], we built [feature] end to end, working with PM/Designer/Senior Eng/Data Science/QA/etc. * Infrastructure needs implies need for [feature/service/etc], we built it end to end * Product encounters [performance/reliability/scaling challenge], we had to spin up instrument -> investigate -> experiment -> improve cycle * Legacy code was slowing team down b/c of [implementation time/oncall burden/etc], we had to pause to refactor while not killing business * Tech debt burndown: structured project to improving test coverage/observability/etc * Team had [no/bad] CI/CD pipeline and we had to [build/fix] it * We had to make a build/buy decision for [key piece of infrastructure]; we evaluated both sides and decided On conflicts, here are few: * PM/EM wants [feature], engineers push back for time/cost reasons * Engineers want [refactor], but PM/EM push back for time/cost reasons * More senior eng has concerns about implementation approach * Designer unhappy with implementation quality vs time/cost * Customer unhappy with product/time/cost * Partner team doesn't want to implement needed feature to hit your team's deadline * Engineer wants to adopt [new tech] but team is resistant What else can people come up with? I also made a note to write up something more extensive soon on the newsletter. Stay tuned!
Even as a mid-level, some of these archetypes are familiar to me. I had never considered them STARR-worthy because my decision on the resolution and resulting action was just simply what the situation called for. Simply put, I just did what any diligent employee would have done. My actions would not be considered particularly notable or "heroic". Knowing that these are considered archetypes is helpful because: * it prompts me to revisit my memory bank for stuff I have filed away as "business as usual" which can be reclassified as STARR stories * it alleviates my impostor syndrome knowing that these are the type of stories the interviewer is expecting to hear, and that qualified candidates tell Thank you for your response and I am looking forward to your newsletter on this!
@@hc3680 Right and that's a frequent response I get from mentees, but remember that while interviewers do want to hear about stellar projects, they are hiring you to do a lot of "average" projects---most projects are average after all, that's what average means. You certainly want the interviewer to walk away with the sense that "this candidate can solidly deliver business value using relevant technologies." Hopefully you can impress them with additional things but you do need to meet that bar.
Just a suggestion: Please make a video on SAAS based health check systems. Requirements would be something like, users can choose how often the health checks should occur
While in a Behavioural interview, when someone asks "tell me about a fav. project", how much details are needed so that it does not feel too much ? should the answer focus on me or the project ?
This question is usually a bit of both: you and the project. Try to keep your responses to 2-3 minutes getting across the main things you want to get across, then pause and see what the interviewer wants to hear more about. They’ll ask you for further clarifications!
Apologies in advance for the finnicky video sync - we had some hardware issues that unfortunately I couldn't fix in post. Fortunately the audio is stellar!
This was a lot of fun @hello_interview! Thanks Stefan for having me and I hope it's helpful for all the SWEs out there prepping for interviews.
Feel free to ask any questions you might have and I can take a pass.
Great insights on lot of topics Austen! Thank you. Q1: Any specific advice for someone who is not working currently and finding it hard especially to explain their situation to HM? Q2: What are specific signals HM look for especially in these type of candidates?
Thanks Stefan, great questions! Applying for Staff+ roles and I appreciate the thought that has gone into coming up with these questions. Relevant and relatable
Appreciate that!
high quality content like this is why Hello Interview is my go-to for interview prep! absolutely amazing
This clears up so many things I had about behavioral interviews, wish I saw them before I went through all my interviews. 😅 This is probably the most useful advice video I've seen about behavioral interviews for more experienced candidates. I feel like a lot of behavioral advice is geared towards entry level folk.
So glad you found it useful! Please share it with friends!
Thanks @thebehavioral and @hello_interview - this is really helpful to prepare and start with. I am looking for some help with following questions:
1/ What to consider while appearing for EM vs Sr. EM role? Some of the major difference to take care while choosing example of situation and some of the tips while answering?
2/ I have often seen similar questions in both Behavioural and People Management round, what type of signals interviewer is looking both the round (separate list of signals)
Actually, would love to see a mock Behavioural that you have done in HelloInterview. (in a similar way you did with the Design interviews)
Trying to think of a way to do this since behavioral is pretty private. We’ll come up with something!
Thanks for the video! I would like to know more about project archetypes and conflict archetypes. Would you be able to enumerate them? I think it will be helpful for candidates to see which of their experiences best fit which archetypes so they know what information they can omit when storytelling
These aren't well established or an industry standard or anything---I bet Kent Beck has some list somewhere, lol---but here it goes...
On projects:
* Business identifies need for [feature], we built [feature] end to end, working with PM/Designer/Senior Eng/Data Science/QA/etc.
* Infrastructure needs implies need for [feature/service/etc], we built it end to end
* Product encounters [performance/reliability/scaling challenge], we had to spin up instrument -> investigate -> experiment -> improve cycle
* Legacy code was slowing team down b/c of [implementation time/oncall burden/etc], we had to pause to refactor while not killing business
* Tech debt burndown: structured project to improving test coverage/observability/etc
* Team had [no/bad] CI/CD pipeline and we had to [build/fix] it
* We had to make a build/buy decision for [key piece of infrastructure]; we evaluated both sides and decided
On conflicts, here are few:
* PM/EM wants [feature], engineers push back for time/cost reasons
* Engineers want [refactor], but PM/EM push back for time/cost reasons
* More senior eng has concerns about implementation approach
* Designer unhappy with implementation quality vs time/cost
* Customer unhappy with product/time/cost
* Partner team doesn't want to implement needed feature to hit your team's deadline
* Engineer wants to adopt [new tech] but team is resistant
What else can people come up with?
I also made a note to write up something more extensive soon on the newsletter. Stay tuned!
Even as a mid-level, some of these archetypes are familiar to me. I had never considered them STARR-worthy because my decision on the resolution and resulting action was just simply what the situation called for. Simply put, I just did what any diligent employee would have done. My actions would not be considered particularly notable or "heroic".
Knowing that these are considered archetypes is helpful because:
* it prompts me to revisit my memory bank for stuff I have filed away as "business as usual" which can be reclassified as STARR stories
* it alleviates my impostor syndrome knowing that these are the type of stories the interviewer is expecting to hear, and that qualified candidates tell
Thank you for your response and I am looking forward to your newsletter on this!
@@hc3680 Right and that's a frequent response I get from mentees, but remember that while interviewers do want to hear about stellar projects, they are hiring you to do a lot of "average" projects---most projects are average after all, that's what average means.
You certainly want the interviewer to walk away with the sense that "this candidate can solidly deliver business value using relevant technologies." Hopefully you can impress them with additional things but you do need to meet that bar.
Just a suggestion: Please make a video on SAAS based health check systems. Requirements would be something like, users can choose how often the health checks should occur
Feel free to vote! www.hellointerview.com/learn/system-design/in-a-hurry/vote
good stuff!!!!
While in a Behavioural interview, when someone asks "tell me about a fav. project",
how much details are needed so that it does not feel too much ?
should the answer focus on me or the project ?
This question is usually a bit of both: you and the project. Try to keep your responses to 2-3 minutes getting across the main things you want to get across, then pause and see what the interviewer wants to hear more about. They’ll ask you for further clarifications!
Thank you so much for sharing this useful information.(by crystal)
Awesome!
What are some good examples of conflicts to talk about for senior engineers?
Major technical disagreements, challenges with partner teams, pushbacks against manager (depending on company).