Takeaways from Leading a 3-Week Technical Interview Bootcamp

What I love (and sometimes really hate) about becoming a software engineer is that you're perpetually living on the edge — and nine times out of ten, you're pushed right off into the deep end.

When I first accepted a short-term role as an instructor for a 3-week Technical Interview Bootcamp at Medgar Evers College, I genuinely felt out of my depth. In two weeks time, I needed to create a finely-scoped curriculum, brush up on my technical skills, and prepare to lecture and engage for four hours a day over 3 weeks. Emotionally, it was a mix of wanting to be the best instructor I could be — sharing my wide range of interview experiences, best and worst practices, and lessons learned the hard way — and a little ego that pushed me forward to be ready by January 6th. Week 1, Day 1.

Quick tangent: Crazy how ego works as a constructive force. While in the trenches of curriculum development, I often (weirdly) imagined myself wearing a sport coat, laughing, smiling, and engaging in deep technical discussions with the next generation of software leaders. It feels silly to write down or say out loud, but my ego envisioned it — and it actually happened. I manifested it. lol crazy.

January 6th arrived, and so did I. With the curriculum and schedule gut-checked by some friends (shoutout to Chris Wardrip), I felt confident about the road ahead:

• Week 1: Tell Me About Yourself, Technical STAR Method, Arrays, Strings, Object-Oriented Programming
• Week 2: Stacks, Queues, Linked Lists, Binary Search Trees, Hash Tables, Graphs & 2D Arrays, Company-Specific Preparation
• Week 3: System Design, Client/Server, Databases, Design Patterns, Scaling
• Guest Speakers: Arush Shankar (Persona) & Steven Truong (Stripe)
• Bonus Lectures: Application Strategies & Resumes

It's aggressive for three weeks. My justification was — and still is — that I'd rather give students a full grasp of the technical interview landscape rather than just drilling a single concept that's "famously" asked in interviews. After the bootcamp, it's on them to solidify and deepen their understanding of the concepts covered.

Don't get me wrong — fundamental problems like twoSum are essential, especially when paired with discussions on runtime complexity and post-code analysis. But solving the algorithm itself is just one narrow part of technical interviewing.

I won't dive too deeply into the curriculum itself or the choices I made about what to include or omit. Instead, I want to focus on what I took away from this experience — as a student, an instructor, and a software engineer.

It was a particularly unique experience because, 99% of the time, I was a student alongside the cohort — reinforcing the concepts I was introduced to some time ago. It served as a reminder of how far I've come while also highlighting parts of my game that need serious improvement. Let's get into the takeaways.

1. Having easy ways to test if you're right or wrong

Take a look at this code snippet:

def test(expected, actual):
    if expected != actual:
        print(f'Fail: Expected {expected}, but got {actual}')
    else:
        print('Pass!')

# Test cases
test(max_value([4, 7, 2, 8, 10, 9]), 10)
test(max_value([42]), 42)

One of our guest speakers, Steven, shared his advice on technical interviews: put in reps and develop a repeatable system until the nerves go away and muscle memory takes over.

This code snippet is one part of his process. It's rather simple, but it showcases a strong attention to detail — especially when it comes to demonstrating to an interviewer that your potential solution is both correct and objective.

2. Using print statements

console.log("Current index: ", i)
console.log("Current value @ index: ", array[i])
console.log("Storage Cache: ", storageCache)
console.log("-------------------------------")

It's an age-old adage at this point, but having well-placed print statements lets anyone looking at your code see exactly how data is being processed and modified.

• The processing part helps visualize how loops work, how computations happen under the hood, and how values flow.
• The modification part is even more important — you might not want to modify certain aspects of your data, depending on the problem statement.

Here's a classic example of reversing an array — one in place and one that creates a new structure in memory:

def reverse_in_place(arr):
    print(f"Before reversing: {arr}, Memory ID: {id(arr)}")

    left, right = 0, len(arr) - 1
    while left < right:
        arr[left], arr[right] = arr[right], arr[left]
        left += 1
        right -= 1

    print(f"After reversing:  {arr}, Memory ID: {id(arr)}")
    return arr

arr1 = [1, 2, 3, 4, 5]
reverse_in_place(arr1)

# Output
# Before reversing: [1, 2, 3, 4, 5], Memory ID: 139913317023232
# After reversing:  [5, 4, 3, 2, 1], Memory ID: 139913317023232

def reverse_new_array(arr):
    print(f"Original array: {arr}, Memory ID: {id(arr)}")

    new_arr = arr[::-1]  # Creates a new list
    print(f"New reversed array: {new_arr}, Memory ID: {id(new_arr)}")

    return new_arr

arr2 = [1, 2, 3, 4, 5]
reverse_new_array(arr2)

# Output
# Original array: [1, 2, 3, 4, 5], Memory ID: 139913317023360
# New reversed array: [5, 4, 3, 2, 1], Memory ID: 139913317022976

The second snippet features a slick one-liner that many students love for its simplicity. However, it overlooks what happens under the hood. By leveraging Python's id() function alongside print statements, the differences between the two become crystal clear, even though they both achieve the same result.

3. Having an opinion, and backing it up

This one inherently comes with experience. I'm not claiming to have the most or the best experience in the world, but the simple truth is: the more you work with technologies, the more you understand their shortcomings, strengths, use cases, and interactions within an architecture.

With that experience, you develop opinions — but more importantly, you gain a deeper understanding of trade-offs. That's something you won't get just from building toy or pet projects. I build toy projects all the time — they're great for quickly getting the hang of syntax and under-the-hood concepts in new languages or frameworks. But nothing compares to the lessons learned from real production experience.

That said, there are plenty of ways to form opinions about technology, even without deep industry experience. Through smaller builds, reading reputable blogs, contributing to open source, or even just scrolling through Twitter, I've started internalizing some widely held perspectives:

• Python is great for readability but slow for high-performance applications.
• JavaScript can be a mess but is unavoidable for web development.
• Rust is safe but has a steep learning curve.
• React is great for UI flexibility, but state management is a headache.
• TypeScript is great — until you start wrestling with complex types.
• GraphQL is overkill for simple APIs.
• Docker makes deployments easy, but debugging containers is painful.

However, having an opinion isn't enough. If someone follows up and asks why state management is a headache, for example, you need to back it up. Otherwise, your credibility crumbles fast. Here's the level of depth I'd expect for myself in a response:

React's flexibility in building UI is fantastic, but state management quickly becomes a challenge as applications grow. useState works well for local state but struggles with shared state, leading to prop drilling. The useReducer hook helps with complex state logic, but it doesn't solve global state issues. The Context API eliminates prop drilling but can cause unnecessary re-renders. For large-scale applications, Redux centralizes state, offering structure and debugging tools, but at the cost of boilerplate and complexity. Choosing the right approach depends on scale, complexity, and performance needs, making state management one of React's biggest trade-offs.

4. Public Speaking

Maybe it's the ego, but this was my favorite part of the bootcamp. I loved jumping in front of the room, slides ready, presenting concepts with not just technical depth but also my own words, analogies, and — for lack of a better term — flair.

It takes time to develop this, but once I accepted that I'm just a goof, presenting became so much easier. Don't get me wrong — I still get nervous. I still stutter and struggle with annunciation. But I think anyone can be a great public speaker with reps and a reflection of who they want to be in front of a group of people.

Technical public speaking is a whole different ballgame. Walking through concepts or code line by line challenged my technical depth, forcing me to constantly question whether I was explaining things in the best possible way. It made me slow down, be deliberate, and choose my words carefully. In real dev settings, how you articulate a problem or solution matters — sometimes in serious ways. A single miscommunication can lead to confusion, delays, or even outright mistakes in execution.

5. Genuine Relationships

Arush and Steven are two of my closest friends, and they were kind enough to volunteer their time to share their work and professional journeys. Their guidance has been instrumental in my growth as an engineer, and I sincerely can't thank them enough for showing up for the cohort the way they did during the guest speaker sessions.

Throughout my core lectures, I constantly tied everything back to why this matters for the job hunt. And if I'm being honest, the most important part of job hunting isn't just technical prep — it's relying on genuine connections built over time.

I've never liked the word networking — it feels transactional, like it strips away the effort and care that go into forming real relationships. Genuine connections take time, trust, and mutual respect. And in the long run, they matter way more than handing out résumés or adding people on LinkedIn (both of which I take part in, for the record).

6. No Magic Sauce

A core component of this bootcamp is that it's ungraded — because the job hunt is ungraded. No one will be there to hold you accountable for results except you.

At the end of every slide presentation, when announcing homework for the day, I always wrote:

You get out what you put in.

I reinforced this daily because I truly believe imposter syndrome fades with consistency, similar to what Steven alluded to in his presentation. If you want to feel like less of an imposter, there are ways to work yourself out of it. There is no magic sauce, and no one person is better or "more talented" than the other.

That said, it's not as simple as A → B. There are so many nuanced factors — race, religion, identity — that contribute to imposter syndrome. But building consistency and putting in the work can be a powerful strategy for pushing back against it.

With all that said, this has been an incredible experience — one that pushed me to become my best professional self. I'm incredibly thankful to the team at Medgar Evers College — Kalyssa, Venice, Dr. Zavala, Wayne, Katya, and Jonathan — for trusting me with this opportunity. I hope this experience yielded constructive results for all of you, and I look forward to building on it together in the future.