A Sister Circle Workshop — From failure to frameworks: everything I wish someone told me
I'm a software and data engineer who has sat exactly where you're sitting. I've attempted the technical gauntlet at some of the most competitive companies in the world, and I've learned more from the losses than the wins. Here is a look at my professional journey:
Livermore National Laboratory
New Relic
Meroxa
Zocdoc
These rejections didn't define me. They refined me.
We surveyed our community and built this session around your real concerns. Here's what you said:
80% of you said this matters most. Here's what strong portfolio projects have in common:
Not a tutorial clone. What pain point does it address?
Problem statement, tech stack, architecture decisions, how to run it.
A live link beats a GitHub repo every time. Use Vercel, Netlify, or GitHub Pages.
Include "Why I built it this way." Interviewers care about your decisions, not just results.
The 70% Rule: Meet 70% of requirements? APPLY. Men apply at 60%. Women wait until 100%.
Set a minimum viable goal: "I will apply to 3 jobs this week." Not 30. Three.
Use accountability partners: Tell someone in Sister Circle. Check in weekly.
Lead with the headline: State your answer in one sentence, then elaborate.
The "So What?" test: After each sentence — does the interviewer care?
The 3-bullet rule: Limit to 3 key points. They'll ask for more if needed.
Practice the pause: 5 seconds of silence shows composure, not weakness.
They're evaluating how you think, not just your code
Talk out loud: "I'm thinking a hash map here because..."
Start with brute force — it's okay. Then optimize.
If stuck: "Here's what I'm thinking..." beats silence every time
Practice: LeetCode, Pramp, interviewing.io
"What does onboarding look like for this role?"
"Walk me through a recent project the team shipped."
"How do you measure success in the first 90 days?"
"How does the team handle technical disagreements?"
Tailor to who you're talking to — engineers, managers, execs
Two frameworks that transform panic into process:
For Behavioral Interviews — structure your story with clarity and impact.
For Technical & Algorithm Interviews — plan before you code.
Set the scene (20%)
Your responsibility (10%)
What YOU specifically did (60%) — this is the meat
Outcome, quantified if possible (10%)
Common questions: "Tell me about a time you disagreed with a teammate," "Describe a tight deadline," "Tell me about a time you failed."
"Tell me about a time you had to learn something new quickly to complete a project."
Pair up and practice for 10 minutes, then use this checklist for feedback:
Was the Action section specific enough?
Was there a measurable Result?
Did it stay under 2 minutes?
Did they say "I" instead of "we"?
Restate in your own words. Clarify inputs, outputs, edge cases. ASK QUESTIONS.
Walk through test cases. Find edge cases: empty input, negatives, duplicates.
Array, hash map, tree, graph, stack, queue — which fits your problem?
Plain English or pseudocode before coding. Plan first, always.
Follow your algorithm. Talk through your thinking out loud the entire time.
"Write a function that prints numbers from 1 to 100. For multiples of 3, print 'Fizz'. For multiples of 5, print 'Buzz'. For multiples of both 3 and 5, print 'FizzBuzz'."
"Write a function that prints numbers from 1 to 100. For multiples of 3, print 'Fizz'. For multiples of 5, print 'Buzz'. For multiples of both 3 and 5, print 'FizzBuzz'."
A fixed range — integers 1 through 100. No arguments needed.
Printed strings (not returned). Side effects only.
Numbers divisible by BOTH 3 and 5 → "FizzBuzz". The order of our conditions will matter.
"Should I return the values or print them?"
"Write a function that prints numbers from 1 to 100. For multiples of 3, print 'Fizz'. For multiples of 5, print 'Buzz'. For multiples of both 3 and 5, print 'FizzBuzz'."
(plain number)
(divisible by 3)
(divisible by 5)
(divisible by both — the tricky one!)
(another both case)
"Write a function that prints numbers from 1 to 100. For multiples of 3, print 'Fizz'. For multiples of 5, print 'Buzz'. For multiples of both 3 and 5, print 'FizzBuzz'."
No special data structure needed.
We're printing, not storing. No need to collect results.
The rules are simple conditionals, not lookups.
A loop (range 1–100) + conditional logic (if/elif/else).
"Write a function that prints numbers from 1 to 100. For multiples of 3, print 'Fizz'. For multiples of 5, print 'Buzz'. For multiples of both 3 and 5, print 'FizzBuzz'."
Loop through integers 1 to 100
For each number, check: is it divisible by BOTH 3 and 5? → print "FizzBuzz"
Else, is it divisible by 3 only? → print "Fizz"
Else, is it divisible by 5 only? → print "Buzz"
Else → print the number itself
"Write a function that prints numbers from 1 to 100. For multiples of 3, print 'Fizz'. For multiples of 5, print 'Buzz'. For multiples of both 3 and 5, print 'FizzBuzz'."
def fizz_buzz():
for i in range(1, 101):
if i % 15 == 0:
print("FizzBuzz")
elif i % 3 == 0:
print("Fizz")
elif i % 5 == 0:
print("Buzz")
else:
print(i)
fizz_buzz()Did you talk through your thinking? Did you catch the edge case? Did you plan before coding?
Mention time complexity O(n), suggest how you'd extend it (e.g., configurable rules)
"Given an array of integers, return the two numbers that add up to a target sum."
Let's work through this together — 15 minutes:
Inputs? Outputs? Duplicates allowed? Is array sorted?
[2, 7, 11, 15], target = 9 → return [2, 7]
Hash map for O(n) lookup
Iterate array, check if (target − number) exists in hash map
Write it together, talking out loud
"Given an array of integers, return the two numbers that add up to a target sum."
An array of integers (e.g. [2, 7, 11, 15]) and a target integer (e.g. 9)
The two numbers (or their indices, depending on the variant) that sum to the target
Assume exactly one solution exists. Can the same element be used twice? No.
"Should I return the values or the indices?" / "Are there duplicates in the array?" / "Is the array sorted?"
"Given an array of integers, return the two numbers that add up to a target sum."
(2 + 7 = 9 ✓)
(2 + 4 = 6 ✓)
(multiple pairs possible — clarify!)
(negatives work too)
(duplicate values — same index can't be reused)
"Given an array of integers, return the two numbers that add up to a target sum."
Trace for [2, 7, 11, 15], Target = 9:
"Given an array of integers, return the two numbers that add up to a target sum."
Create an empty hash map to store numbers we've seen
Loop through each number in the array
Calculate the complement: complement = target − current number
Check if the complement already exists in the hash map
If YES → we found our pair! Return [complement, current number]
If NO → add the current number to the hash map and continue
"Given an array of integers, return the two numbers that add up to a target sum."
def two_sum(nums, target):
seen = {}
for num in nums:
complement = target - num
if complement in seen:
return [complement, num]
seen[num] = True
return []
# Example
print(two_sum([2, 7, 11, 15], 9)) # → [2, 7]Did you mention brute force first? Did you explain WHY a hash map? Did you talk through the complement logic out loud?
Mention O(n) time / O(n) space tradeoff. Discuss returning indices vs. values. Ask about follow-up: what if there are multiple valid pairs?
Practice questions: Generate role-specific interview questions
Mock interviews: Have AI play the interviewer and give feedback
Code review: "How would a senior engineer improve this?"
Company research: Tech stack, recent news, culture, competitors
Do NOT use AI during live interviews (unless explicitly allowed)
Do NOT copy-paste AI answers in take-homes — you'll get caught in follow-up
DO use AI to learn, sharpen, and prepare more efficiently
"AI is a tool, not a shortcut. Use it to sharpen, not replace."
What does the company build? Who uses it? Why? Show you've done the research.
Even juniors who think about systems at scale stand out immediately.
Revenue models, unit economics, what moves the needle for the business.
Post about learning, projects, and insights from your journey. Consistently.
Active repos and open source contributions signal that you're shipping real work.
Teaching is the best learning. Write about problems you solved.
"You don't need to go viral. You need to be consistently visible."
You can prepare perfectly and still get a curveball — an interviewer's bad day, a question outside your domain, a role that shifted mid-process. Some things are outside your control. Focus on what isn't.
Preparation, attitude, and consistency
Interviewer's mood, internal candidates, team priorities
The Failure Recovery Framework:
24–48 hours to be disappointed. That's valid.
What went well? What didn't?
What's ONE thing you'll do differently next time?
Let it go. The next interview is what matters.
Bills don't wait. Multiple rejections erode confidence. Imposter syndrome hits hardest when you're already down. Here's how to protect yourself through the process:
Choose a sustainable number of applications per week — and stick to it.
Lean on Sister Circle. You don't have to do this alone.
Callback? Win. Final round? Big win. Keep a "wins" journal — every positive interaction counts.
You are not your interview performance. Full stop.
Use every "no" to fuel your growth and sharpen your approach.
STAR and PEDAC are your anchors under pressure.
Headline first. 3-bullet rule. The interview goes both ways.
Set boundaries, lean on community, separate identity from outcome.
Every expert was once a beginner. Your seat at the table is earned — and waiting.
"What's the one thing you're taking away from today?"
Cracking the Technical Interview: Strategies, Frameworks & Resilience