Article

A Flatiron School Facilitator on What Makes Software Engineering Students Succeed in 2026

Mike McGee

Written By Mike McGee

Liz Eggleston

Edited By Liz Eggleston

Last updated January 8, 2026

Course Report strives to create the most trust-worthy content about coding bootcamps. Read more about Course Report’s Editorial Policy and How We Make Money.

Some of the most valuable lessons in software engineering don’t come from tutorials or textbooks – they come from watching where people get stuck, how they recover, and what ultimately helps them level up. For nearly a decade, Cernan Bernardo has been in the middle of that process. A former Flatiron School student turned Senior Software Engineer, Cernan now serves as a Software Engineering Facilitator at Flatiron, where he mentors and teaches aspiring developers and junior engineers. His insights reveal why curiosity and communication often matter more than raw technical ability, how standout portfolio projects tell a clear story, and why learning to embrace struggle is one of the most important skills a new engineer can develop.

Cernan, you attended Flatiron School yourself as a student in 2016. What ultimately convinced you to make the leap into coding?

Before transitioning into tech, I spent almost eight years as a financial advisor, helping clients with their retirement portfolios. However, during the last couple of years working in that industry, I'd come home after a long day wanting to learn how to code. I enjoyed building sites with HTML and CSS on platforms like Treehouse and freeCodeCamp, and ultimately decided to make a career change.

In 2016, I enrolled in a Flatiron School bootcamp. This was a significant year – not only was I changing careers, but my wife also found out she was pregnant with our first child. It was a scary time, with my life about to change in two significant ways, but my wife was supportive of my passion, which gave me the confidence to leap into coding.

What inspired you to transition into teaching and mentoring after your own career change?

While going through the bootcamp, getting a job was the main goal, but I naturally gravitated toward helping my fellow students. I enjoyed seeing that "light bulb" moment when a concept clicked for them. After graduation, I decided to shift into a teaching role to dedicate more time to mentoring. Plus, it was a little self-serving: the immersive bootcamp was a fire hose of information, and teaching allowed me to slow down and dive deeper into the material, reinforcing my knowledge of the subject.

How did your progression through roles – from Flatiron School student to Section Lead, Faculty Manager, and ultimately Software Engineer – shape your philosophy on teaching and mentoring developers?

Each role progression naturally informed the next. Starting as a student clarified what I wanted in an instructor. As I transitioned into a teaching role, I realized I needed my manager's support. This continuous feedback loop was vital. Ultimately, as a software engineer, I applied this same mindset to mentoring junior developers: "What did I need and want to learn as a junior?" This iterative experience profoundly shaped my approach to teaching and mentoring students and developers alike.

Flatiron School has a unique instruction model. What does it mean to be a “Facilitator” at Flatiron School? How do you support students these days?

The facilitator role differs significantly from that of a traditional instructor. We serve as a technical guide and learning partner, moving beyond simple lecturing to foster understanding. Our focus is on connecting core software engineering concepts to practical, real-world applications – it’s not just how the syntax works, but how you would use it. Crucially, we meet students where they are, tailoring the session to address their specific struggles even if they are behind the structured curriculum. It is less a teacher-student dynamic and more a collaboration.

What's the best way for students to use Facilitators or Mentors effectively?

The key is treating the relationship with the facilitator as a partnership, not just a source of answers. I am most effective when a student comes prepared with specific questions, clear goals, and what they have already tried to overcome their blockers. They shouldn't just present the problem; they should present the problem and the steps they've taken to address it. This skill is vital as a junior engineer. Just as an engineer wouldn't simply tell a senior, "I have a bug," but would instead say, "I have a bug, and here are the two or three things I've tried," students should approach their facilitator similarly. It's about being a partner in learning, perhaps asking, "Is there anything that stands out to you, or can we debug this together?" Finally, students must be receptive to feedback and follow through on it to accelerate their growth.

In your experience, how does a bootcamp grad evolve into a senior engineer? Is that progression a matter of time, specialization, or mentorship?

Time is a factor, but the transition is rooted more in a fundamental shift in mindset. Experience matters, yet accelerated growth came from learning to think beyond my own code. Early on, the focus is on shipping features and closing tickets. As I gained experience, I became intentional about considering trade-offs, long-term maintainability, and the impact of my decisions on other engineers, the product, and the business. This involved asking why we were building a feature, not just how to build it.

Mentorship also played a significant role, both as a junior mentee and as a mentor to a senior. Observing how senior engineers reasoned through problems, handled ambiguity, addressed bugs, and communicated was invaluable. Ultimately, the shift to a senior role was less about performing the work and more about changing my perspective and understanding the intention behind a project, which then informed how I built the feature.

Building on your mindset evolution, was there a skill that became unexpectedly vital to your growth?

Communication. Initially, being a strong engineer was solely about writing, knowing, and shipping clean code. While that's still true, the ability to clearly explain my decisions, ask good questions – especially about a feature's purpose – and effectively give and receive feedback became essential. This includes working with non-technical stakeholders. In a remote work environment, excellent written communication – via Slack and email – is crucial. It reduces rework, builds trust, and allows teams to move through the development process much faster.

Having worked with hundreds of students, what common patterns do you see in those who ultimately succeed, even if they initially face challenges?

A student's success often comes down to two main factors. First, their response to struggle is critical, as almost all students will struggle at some point. Successful students view difficulty as a challenge to overcome, consistently seeking help and asking questions the moment they feel blocked, rather than waiting until they are completely stuck. Second is taking ownership of their learning. They treat confusion as a signal to seek assistance and revisit the fundamentals – like reviewing a README or lesson – to break down what went wrong. Building these routines and responding positively to struggle are traits that translate directly into success as a software engineer, where continuous learning and problem-solving are essential.

In your experience reviewing numerous Flatiron School student portfolios, what distinguishes a great project from a good one?

A good project satisfies the requirements and works. A great project, however, reveals the student's thought process. It’s not just the code; it’s the ability to articulate why certain decisions were made – the structural choices, the trade-offs considered. A great project shows that the student put genuine thought into the work rather than just meeting the basic criteria. While visual appeal is a bonus, the real differentiator is a student's ability to tell a compelling story about their design process.

What is the most significant change you've observed in the tech industry this year, especially considering the rise of AI? When advising coding bootcamp students, how should they balance focusing on AI tools versus mastering programming fundamentals?

The most significant change has been AI's rapid transition from a niche tool to an integral part of the daily development workflow, actively shaping how we prototype, debug, test, and reason about code. However, the core problems in front-end development remain constant. Students must master the fundamentals – HTML, CSS, accessibility, JavaScript, state management, and browser mechanics. This mastery is what will distinguish strong engineers; relying solely on AI to generate code is not enough. AI acts as a force multiplier, accelerating an engineer's work. Still, it cannot compensate for a lack of foundational understanding, context, or the ability to debug issues when they arise. Ultimately, AI will augment, not replace, engineers.

You mentioned AI's integration into daily workflows. Could you tell us about one of your recent projects as a senior software engineer?

I recently completed an important feature: developing the multi-step enrollment and authentication onboarding workflow for our application. This entire flow uses Xstate to model state transitions and events, ensuring deterministic and reliable application behavior. I particularly enjoyed this project as it was my first time implementing Xstate. It was a full stack effort – a React/Next.js front end and a Node/Express back end – and I found the process of building it over the last couple of months very rewarding.

What skills or habits do junior developers most often underestimate when entering the workforce?

Junior developers often underestimate the importance of communication, especially written communication. This includes documenting features, writing detailed pull requests explaining their thought process, and being clear in async discussions via tools like Slack.

Another critical habit is asking questions early. Don't delay asking a question because you fear seeming unprepared; the sooner you ask, the sooner you can move forward.

Finally, try to understand the broader context. Even as a junior, ask about the ultimate goal and "why" behind the feature you're building. This shows non-technical stakeholders that you care about the product and are not just pushing out code.

Given the importance of communication, what roles are your software engineering graduates best prepared for, and have employer expectations shifted recently?

Our software engineering graduates are well-prepared for entry- to mid-level roles, including front end, full stack, and back end developer positions, where they can contribute immediately. Their success is built on a solid foundation of practical skills, including Git and GitHub collaboration, as they build real-world applications. Employers continue to seek engineers who write clean, maintainable code, understand web fundamentals, enjoy problem-solving, can learn independently, and thrive in a team environment. Flatiron grads demonstrate growth in all these key areas.

What is a common mistake new developers make during their job search, and what is your advice to avoid it?

A frequent mistake is optimizing for volume over quality. Students will apply to 50 jobs a day and become frustrated when they don't hear back. Instead of this high-volume approach, they need to focus on tailoring their applications. This means identifying the specific industry and companies they want to work for, then taking the time to customize their resume and write a specific cover letter for each role, highlighting skills relevant to that position.

What is one piece of advice for Flatiron students today that will remain relevant five years into their careers?

Always be learning. The tech world evolves rapidly; technologies and frameworks popular a couple of years ago may not be today. Maintaining a growth and learning mindset – being open to experimenting with and testing new technologies – is crucial to growing as an engineer and avoiding becoming stuck in the past.

Thank you for your timely and timeless advice: be curious, open to feedback, communicate, and focus on solving problems by understanding the "why" as much as the "what." Your insights are highly valuable. 

You can read Flatiron School reviews on Course Report. This interview was produced by the Course Report team in partnership with Flatiron School. Thank you.


Mike McGee

Written by

Mike McGee, Content Manager

Mike McGee is a tech entrepreneur and education storyteller with 14+ years of experience creating compelling narratives that drive real outcomes for career changers. As the co-founder of The Starter League, Mike helped pioneer the modern coding bootcamp industry by launching the first in-person beginner-focused program, helping over 2,000+ people learn how to get tech jobs, build apps, and start companies.


Liz Eggleston

Edited by

Liz Eggleston, CEO and Editor of Course Report

Liz Eggleston is co-founder of Course Report, the most complete resource for students choosing a coding bootcamp. Liz has dedicated her career to empowering passionate career changers to break into tech, providing valuable insights and guidance in the rapidly evolving field of tech education.  At Course Report, Liz has built a trusted platform that helps thousands of students navigate the complex landscape of coding bootcamps.

Also on Course Report

Find the path that fits your
career goals

Match with Bootcamps
Explore Courses

Sign up for bootcamp advice

Enter your email to join our newsletter community.

By submitting this form, you agree to receive email marketing from Course Report.