Category : Culture

A reflection on our first co-op semester

In my first months as an engineer at Panorama, I eagerly looked for opportunities to bring prior experience in and have a big impact. I thought about the things my previous employers had done really well and how I could bring what I learned there to help make our engineering team better. What stuck out to me the most was that my last company had a really strong co-op/internship program, and we didn’t have one at Panorama yet. 

In past experience, co-ops and interns were a great hiring pipeline for full-time engineers. Having students join a few times a year provided opportunities for other engineers to mentor and teach them about how our systems worked and what life as a software engineer is like. Additionally, one of Panorama’s core values is that we contribute to our communities, including the Boston community, the education community, and the startup community. Giving these students an opportunity to learn from us through a co-op experience is a great way to do that. With all of these benefits, starting a co-op program at Panorama was an easy sell.

Image of core value:
We contribute to our communities.

In addition to our clients, we serve our communities more broadly, including the Boston community, the education community, and the startup community. Whenever possible, we contribute, and we give back. We release open source materials and share best practices. We help others who are doing important work.
One of our core values, displayed in our hallway of values.

We decided to start specifically with Northeastern University’s co-op program for a few reasons:

  • Our thorough onboarding process takes some time, and a 6-month co-op (instead of a 3-month internship) would give a better return on the time the engineer produces value relative to the time the engineer would spend learning about our company and our codebase.
  • Being a Boston-based company, we felt that focusing on a Boston-based university would enable most interviews to be fairly low-lift for the candidate and we would not have additional complexities of travel time.
  • The interview and employment cycle at Northeastern are well-defined, so we could keep interviewing to a short timeframe. We could also start with the January – June employment cycle so that we wouldn’t onboard the engineers in the summer when we also might need to spend our onboarding efforts on new graduates.

Once we decided to move forward with the program, we made a rubric to ensure fair resume review and made small changes to our interview process specific to the new role. After that, we went ahead and rated resumes as they came in and did the interviews. We successfully hired two co-op engineers, Spencer Pozder and Raquel Levy! As their summer nears the end, I sat down with both of them as they described their experience at Panorama.

How did you hear about Panorama?

Raquel: I heard about Panorama through the Northeastern NUCareers co-op portal! The posting really stood out to me as a place where I would actually be able to make a real impact and was really excited by the idea of using data to improve student outcomes!

Spencer: I first saw Panorama on NUCareers – I looked them up and their mission really resonated well with me! They were definitely my first choice once I started applying for co-op positions, and I am very glad that was the case now that I am here.

What was the interview process like?

Spencer: I was a little worried about my interview with Panorama; it was scheduled for 4 hours, which is the longest interview session I had done at that point. But the time really flew by: each individual part was interesting and everyone I met was inviting. Since starting my co-op, I have learned just how much Panorama cares about their interview process, and it has set a high bar for other interviews I will have in the future!

Raquel: Overall the interview process went really well for me. It started with a phone screen, and then a series of in-person interviews at the office. While at the office, I really liked that I got to meet so many different people and having 2 other engineers in each interview session made it feel more like a collaborative conversation than a test! I also loved the coffee/walk I got to go on. Getting to go on a casual walk with Jason (VP of Engineering) and Phoebe (a full-time Engineer) showed me a lot about Panorama’s open and friendly culture and gave me a great chance to ask a ton of questions. Across the board everyone was so inclusive and welcoming!

What do you normally do on a day-to-day basis?

Raquel: My day-to-day tasks are pretty much the same as any other full-time engineer on my team! It’s really great being treated as a full-time employee and getting to do real impactful work. Not only do I get to write, test, review, and deploy code on a daily basis, but I’ve also had great learning experiences getting to be on calls with clients, and working cross-functionally with other product/engineering/client success teams across Panorama.

Spencer: At this point I generally do the same engineering work as the other members of my squad – I take a JIRA ticket off the backlog, write some code (and tests) and get out a PR! I have been involved in some important work on the product since I started here, which has been a big change from what I have seen in other co-op positions.

What has been your favorite project?

Spencer: Handling the end of the school year has been an ongoing effort for my team, and it has been interesting to work through the technical problems it involves. Many new features need to be added, and lots of existing client integrations need to be adjusted to work automatically come September. It’s exciting to see this work take off though, and the difficulty has kept the work engaging!

Raquel: My favorite project so far has been getting to build support for a new SIS (Student Information System) in our platform. It was a really great learning experience because I got to see the project from start to finish and got to take on a lot of responsibility for getting the project completed. Not only did I get to establish new patterns and add lots of new code to our code base, but I also got to do research and investigation about the SIS, I got to work closely with the client success team as well as the client themselves to learn about their data schema and how it might align with our internal schema, and overall I got to touch pieces end-to-end of our full data pipeline which helped me learn a lot more about the system.

What is your favorite thing about working at Panorama?

Raquel: How easy it is to learn! From engineers with traditional CS backgrounds to former teachers and school administrators, to sales and marketing experts, there are so many people with a range of talents at Panorama who are all so friendly, collaborative, and always open to helping and answering questions.

Spencer: The people I work with. Everyone is so helpful and the entire engineering team is full of incredible developers.

What is your least favorite thing about working at Panorama?

Spencer: Sometimes I feel a good amount of Imposter Syndrome working with so many great engineers – but they do a great job of supporting me and I have learned a lot during my experience which has worked to combat this!

Raquel: Since Panorama has been growing so much and half of the team is on a different floor, it has been harder to get to know everyone outside of engineering. With that being said, the weekly company-wide catered lunches, full-team meetings, and other fun outings and events have been great opportunities to build connections with more people outside of the engineering team!

How does this compare to your previous co-op experiences?

Raquel: My last co-op was at a larger global company, and had a million different projects going on at once. It was nearly impossible to be friendly with everyone and having half of our team across the world in China and India made for early morning calls and long hours. I also was strictly a front-end developer and did basically the same type of work for my full 6 months there. Now, having been at Panorama I see how much I really care about working on a passionate, energized, and collaborative team. I have loved working at a smaller company and getting to wear many hats and grow in a wide variety of ways including a range of technical skills as well as collaboration and communication. I also love working somewhere where everyone really cares and it feels like there is always somebody to help!

Spencer: My previous co-op was at a larger software company where I felt much more like a cog in the machine. Panorama is great about involving me in work that directly affects clients, to the point that I have been involved in calls with clients about what we could do to directly improve their experience (I get to see educators get excited about what Panorama could do to help them).

Would you recommend a co-op at Panorama to a friend?

Spencer: I already have!

Raquel: Absolutely! I have already encouraged many of my friends to apply.

Would you consider working here after graduation?

Raquel: I could definitely see myself at Panorama after graduation! There is so much exciting work happening for a meaningful cause, and I know there is so much more for me to learn from Panorama. The people, mission, and learning opportunities would make it a no-brainer for me.

Spencer: Absolutely! There is a lot of career-development work here at Panorama that each engineer does with their manager to keep track of what work we have done, it is exciting to see what I have been able to accomplish and what kind of work I could be involved in in the future.

Raquel and Spencer have been kind enough to share their contact information if anyone wants to chat with them directly and

Photo of Jess (author) with Raquel and Spencer (co-op engineers)
Me (center) with Raquel (left) and Spencer (right)

We had a great experience with our first set of co-op engineers and were happy to hear that they felt the same. We look forward to many more semesters of hiring students as co-op engineers in the future.

If working with co-ops (or as one) interests you, we’re hiring!

Read More

Engineering in EdTech: How We’re Building a Better Future for Students

At Panorama Education, we’re aiming to provide a robust MTSS software solution to give educators the tools they need to reduce busy work and make the data they need easily accessible so that they can spend more time focused on helping students. MTSS (multi-tier system of supports) is already used by many schools to identify struggling students and create interventions to help them get on track, but the process is often undertaken with spreadsheets and lots of manual work.

MTSS tiers of support
MTSS tiers of support

Our engineering team is split into several squads, and mine, Intervention Squad, is tasked with making our vision for MTSS a reality. I couldn’t be more excited to be part of a project that will impact so many students across the country, and I’m confident we’ll succeed in this work is because of the culture at Panorama.


I have been in education technology for most of my career, approaching twenty years at this point. At my last job, I managed a development team building a student information system. After many years in this role, the time finally came to move on when I found myself missing being a full-time coder. One concern I had as I began my job search was finding myself as just another coder on a team receiving marching orders from up the chain of command.

When I interviewed at Panorama, it was clearly a different kind of company. The process was thoughtful and engaging, a far cry from the coding problem after coding problem assault I’d often experienced. I would enjoy working with everyone that interviewed me, I found myself thinking as I left the last round. When I got the call with an offer, I accepted immediately.

There’s always a concern when starting a new job that you are being sold a bill of goods, that the rosey view you’re given while interviewing is conveniently omitting some unpleasant details. This was not the case for Panorama. I found a culture built on the idea of servant leadership: that everyone had a voice and that managers were there to enable engineers, not dictate to them. Instead of being told what to do, I was encouraged to think of solutions to any problems I saw and propose them to the team. It was a system of influence, not authority, where the best ideas ruled the day, not job titles and seniority.

Panorama employees whiteboarding ideas
Panoramians whiteboarding ideas

The result of this philosophy is a culture of engagement. Engineers aren’t expected to just write code all day, every day: we learn about our product domain, K-12 education; we create working groups to tackle important technical areas that can easily be overlooked in the rush to the next deliverable; and we all contribute to the technical direction of the company through discussions and RFCs (request for comments). Having worked at a company where an executive once referred to the rank and file engineers as “worker bees,” it is exhilarating to have given up a position of authority but still have input and agency. There are certainly challenges to having more voices in the room, but those challenges help our team build up collaboration muscles, improving communication and empathy.


Fast forward several months into my time at Panorama, and we found ourselves at the beginning of our MTSS project looking up at a mountain with a long trek ahead of us. Our ambition was simple but grand: we wanted to make a software system that revolutionizes how educators help students such that they all would be on track for graduation and success beyond school. So how do you climb a mountain? As we had learned in our past projects, you simply take one step at a time.

We went to our playbook: we all learned about the problem domain; we got external input early and often; we collaborated constantly; we built small slices of functionality and shipped them quickly; we never accepted technical debt; and we never said “good enough.” Soon, we had the early pieces in place and the feedback from existing clients and prospects was glowing, giving us the confirmation we needed that we were on the right path in our climb up the mountain.

Design wireframe and the final product
From vision to reality

We still have a long way to go before we realize our full vision for software that can supercharge MTSS. There are many steps before we reach the peak, and, truth be told, we may never get there: to say that we have finished the job and things are “good enough” is just not our style, so our climb will continue indefinitely. But thanks to our culture, we will also constantly release great software that pushes MTSS to better places. We will do that as a team of equals, always engaged and constantly collaborating. That’s the Panorama way.

Read More

Musings of a New Grad Engineer

I joined Panorama Education as a Full-Stack Engineer fresh out of grad school. I’ve been very fortunate to have had a positive experience with my first job out of college, and wanted to share some of the important elements of day-to-day work that have made this an enjoyable experience. The following is a brief snapshot of what I’ve learned and am continuing to learn based on my own personal experience.

Engineering is collaborative

Back in school, coding was usually a thing you do yourself. Sometimes you’re working on group projects, but most of the time, it was me and my laptop. At Panorama, I’ve learned that there are parts of software engineering that are done individually, but there is a huge part of work that is collaborative. There are many opportunities to dig into a problem as an individual, but nothing can really get done without at least one other person. It is impossible to build and maintain something of large scale and impact alone.

Take code reviews, for example. It’s a way to help prevent bugs and helps engineers keep each other accountable. Since starting at Panorama, what I had once seen as merely a safeguard against bugs has become a well-established system to give and receive feedback and to learn from each other. Code review is at its core collaboration.

Working with others is essential. And when you’re working on a team, coding is not the only thing you do. You might be communicating closely with designers or product managers. You might organize technical projects to completion. You might mentor others, or participate in pair programming. Yes, this may mean that you’re writing less code than you would if you were building out an entire system by yourself, but I’ve learned that this trade-off leads to systems that are more likely to be resilient and sustainable, increases knowledge sharing, and fosters an overall more enjoyable work culture.

There is value in focusing on growing where you currently are

During my first few months of Panorama, I found myself occasionally thinking, “I’m not growing as an engineer if I’m not daily gaining skills that will prepare me for the next company.” Tech culture says that you should start looking for a new company after 2-3 years, or maybe even after 1 year. It was also my old student mentality: “What do I need to do to graduate?”

But then I realized I didn’t want to leave. I enjoyed working with my coworkers, I was learning and being challenged, and I was motivated by the work we were doing. I didn’t need to leave, nor did I want to. I was focused on how to prepare for the next company, instead of stopping and appreciating the opportunities I had to learn and grow where I was.

There is nothing wrong with wanting to switch companies after a couple years, and there are many situations in which leaving a company is the best thing for someone to do. What I have learned, though, is that career advancement in software engineering doesn’t need to mean moving to a different company.

Structured professional development on the engineering team is relatively new, and it isn’t perfect. Engineering at Panorama recognizes that and thus treats our levels document as a living document. We as engineers can give input into the development of this document and contribute to its evolution over time, and this evolution is transparent across the department. What I’ve grown to appreciate is the openness to feedback and the collaboration that exists here in building out what professional development looks like for Panorama engineers.

This overall approach in fostering engineering growth has played a key part in my experience at Panorama that keeps me here at this company. Structures and culture are in place such that my accomplishments are recognized, my weaknesses are improved with guidance and patience, and feedback is essential.

Imposter syndrome is still there, but good company culture can help some

Initially at Panorama, I realized that there lingered a mindset that I had developed during my college days— I had believed that the number of lines of code I churned out every week was directly correlated to my success as an engineer. And if it wasn’t the number of lines of code, it was the quality of the code and how fast I was able to churn out that high quality code. A lot of this mindset had been influenced by the technical interviewing process in the software industry: “I didn’t pass that technical interview. That must mean I’m not good enough of an engineer.”

Your ability to pass a technical interview is not at all related to your worth or your ability as an engineer. But sometimes, that imposter syndrome voice sneaks up even if you know that what it’s saying is false.

I don’t have a silver bullet for how to deal with imposter syndrome, but I do know that the company culture I’ve had the privilege of being part of has helped some.  Panorama is really big on taking time to reflect. Weekly squad retrospectives and Before-Action-Reviews and After-Action-Reviews for projects are some examples of reflection being built into our daily work. This culture of reflection has encouraged me to reflect more personally. I’ve learned that reflection is so crucial in recognizing the patterns of thinking I fall under and determining if they are constructive. Spending time to do so makes it easier to identify that imposter syndrome voice.

There is also a strong belief amongst my coworkers that mistakes happen, and they should be used as experiences to reflect on and lessons to learn from, not something to be punished for. My coworkers are not just open to, but are eager to share mistakes and lessons learned from mistakes of the past. Having these models of humility in engineering has been gradually shaping my mindset on my own mistakes, as well.

Feedback from my manager and my peers has also been helpful for me in terms of imposter syndrome. When I feel like I’m falling behind, instead of being unsure if I’m doing well or not, I can trust my coworkers and managers that they will tell me what areas I can grow in, and what areas I’m doing well in. And if I’m not getting that feedback, I’m empowered to ask for it. As I have more feedback conversations with my peers and my manager, I’m repeatedly reminded that there is a shared understanding that we are here to support one another. That has really helped with imposter syndrome.

I’ve written about these lessons I’ve learned here, but I do still waffle between my old and new mindsets. I still sometimes ask myself if I’m really “being an engineer” if I’m not sitting alone coding 100% of my work week. When that happens, I remind myself that working on big problems is best done as a team. I still question if I should be spending time practicing technical interview problems so that I crush my next interview should I leave. When that happens, I ask myself if that desire to leave is rooted in job dissatisfaction, or in some perceived tech industry expectations. I still suffer from imposter syndrome. When that happens, I take a step back and try to reflect. It’s not easy, and the cycle repeats sometimes. But let this be a reminder to myself, and maybe to you, that it is OK— this is what growing looks like.

Read More

My reflection on being the first designer at a tech startup (Letter to Julia)

Hi Julia,

Hope you had a great weekend. It’s so great to hear about your new position! (Can you share a link of your new company? Would love to check it out!) Here are some of my thoughts as the first designer in a tech startup.

Read More

What I’ve learned after half a year of working remote

Early last year my wife and I got the great news that she had been accepted for a research fellowship at the NIH in Bethesda, MD. Although very excited for the opportunity, that unfortunately meant that we had to move down there and leave Boston. At the time I had been working for Panorama for just a few months, but it was definitely enough time for me to get hooked with the company’s mission, its energy and above all my coworkers who I already called friends.

It has been over half a year now since I went remote, and with the new year I feel it’s time for a little retrospective.

Read More

Our Engineering Book Club

Every Wednesday afternoon you will find the engineers at Panorama huddled by the couches or gathered around the desks by the projector. Why? It’s Book Club time!

The Book Club started back in June 2014 when we realized that all of us had favorite programming/technical books which we loved talking about and wanted everyone else to read. So we decided that we’d all read a book together and then share our thoughts, learnings, questions. And then, every Wednesday, we discuss for half an hour what the chapter taught us, what we agree or disagree with and how can we incorporate the learnings in our daily work.

Read More