What’s it like to be an engineer at Clever? What does success look like for individuals and teams? From engineers with non-traditional backgrounds to engineers with Computer Science degrees, four engineers share their perspectives about their experiences, typical days, and growth while working at Clever.
Our engineering team consists of 50+ engineers and is an exceptional group. Not only do they support millions of students who depend on the Clever platform to access all of their educational applications, but they also work closely with our product and design teams to ensure we build the best possible product for our customers. Because Clever Engineering has eight different teams that collaborate regularly depending on the in flight projects, every individual’s experience is fairly unique.
To learn more about a few engineers, I invited four members of the team to share their responses to commonly asked questions from engineering candidates.
As always – if you’re interested in exploring what it could be like to work at Clever, take a look at our open positions, submit a general application, read more on our engineering blog, or reach out to us at email@example.com!
Day in the life of a Clever engineer
1. What does your typical day look like at Clever?
Ashley: My days at Clever are largely self-driven. My days are usually a mix of working on technical specs for an upcoming project, tackling bugs reported by customers, implementing a longer-term project, reviewing my team members’ code, or attending guild meetings where we talk about cross-team engineering concerns.
I live in the San Francisco Bay Area, which means that I have the option to go into the San Francisco office from time to time. Going into the office is quite flexible, but I enjoy going into the office for team events or even just to bond over lunch with coworkers on other teams who also came in that day
Mark: There are at max two meetings per day in a week for team coordination: standup happens daily but can be accompanied by sprint planning, retrospective, socialization, etc. Other hours focus on two primary directives: pushing initiatives the team has taken on or assisting other teams in achieving goals. This focus changes slightly with on-call.
Initiatives are projects that security team engineers will work on (see “”decide and plan what you work on””). These projects are never solo ventures. Even while remote, spontaneous synchronous hangouts are a message away to help unblock you. Otherwise, there is plenty of system understanding, spec writing, documentation behind the things that are now known, and ultimately code writing.
Helping other teams comes from everyone knowing the importance of safeguarding user data. Whenever a team asks for security’s eyes, it’s like a threat model in disguise. It’s then the security engineer’s job to understand context, identify threats, communicate risks, and end with (hopefully reasonable) compromises. Ultimately, there will be compromises, but it’s the security team’s job to navigate towards safe harbors while clearly explaining how we might get there.
Finally, on-call handles requests (and other miscellaneous tasks) that coordinate communication externally. These are plenty: triage inbound review requests, field security questionnaires from external parties, see to security researchers’ requests, lead for security-related incidents, or be a steady security presence wherever needed. Additionally, some tasks do not relate directly to one of those security team initiatives, and the on-call engineer works to field those occasional issues.
Overall, the work you do as a security engineer is versatile, but one where you’re there to help out the immediate team, the immediate org, and the company as a whole.
2. What is your favorite part / thing about working at Clever?
Briana: I love knowing that I’m building and maintaining products & features that are beneficial to both students and teachers everywhere. Also, even with being remote, Clever is such a fun place to work! I also like the size of the company and how easy it is to reach anyone.
Ashley: Clever is not so big that I feel like a cog in an isolated team, but not so small that I feel like I have to shoulder large burdens by myself. I always feel like I have the support of fellow engineers and coworkers in other roles, and I love the collaboration between teams.
James: Sometimes it feels like a bit of a cop out answer, but the people! I used to think you join a company for the mission and stay because of the people. It turns out this is only partly true, because from the first moment I talked with people here, I knew I wanted to work here. We have a lot of people who really care about what they do and who they make this great product with, and it shows in the day-to-day interactions you have with people, which on occasion includes Slack threads about everything and nothing at all, covering songs or hosting a mock e-team announcement panel at our company retreat, or just ranting about what’s bothering us in a retro.
Growing your engineering career at Clever
3. Can you give an example of something tricky or challenging you’ve overcome recently?
James: For me, it would be the initial rush of our back-to-school season. With districts and apps making so many changes, joining Clever for the first time, or bringing on new administrators, we tend to get more questions that trickle down to the engineer on call. We deal with this partly through preparation by adding a secondary on call engineer, going over our alerts before the busy period; partly through mitigation by taking on projects less likely to result in disrupting educators; and partly through just making sure we take care of ourselves, from a few just-for-fun BTS slack channels to some Clever-provided goodies to being warmly encouraged by managers and teammates to take care of ourselves.
Mark: Collaborating to give timely, relevant information to teams is essential. The security team is now working to provide relevant information about potential vulnerabilities and how to handle them. We’ve been discussing internally and with other teams to get a sense of what we want to cover: what’s the highest priority in terms of risk, what do we want to scan, how do we measure effectiveness internally, how do we communicate this with other teams, etc. To understand how this would work in practice, we worked with a couple of teams to determine a timely cadence for identifying and patching relevant threats.
This project’s first iteration taught the team a lot. Primarily, we have some thorny issues to tackle around scaling for the information we’re continually consuming and delivering relevant information to security engineers for threats and actions to take. Rethinking the data we take in and what we actively want to scan will help scale for the entire organization. Additionally, better quantifying relevant threats should help the signal-to-noise ratio for everyone involved.
4. How do you continue learning new things while at Clever?
Briana: It is probably my favorite thing about the job. Whether it’s through a pair programming session or code review, I am always learning something new from fellow Cleverites.
James: Starting from learning our tech stack, a lot of which I hadn’t used before, I’ve been able to learn my role here comfortably. On top of that, we’re also encouraged to investigate and learn about new things that might improve Clever, which could involve hopping on exploration calls with district administrators or researching how some technology or practice could be applied here. We also have Learning & Development seminars on topics from leadership to bias to feedback skills to finances. Finally, we are encouraged to seek out our own personal learning, whether picking our own books or attending conferences that Clever will reimburse, or utilizing LinkedIn Learning and writing about what we learned.
Mark: The entire engineering organization is always working on something new. With the team’s collaborative nature, interfacing with other teams exposes you to new concepts and ideas. This cycle comes up plenty during security reviews because of: understanding the problem space, identifying the potential threats, contextualizing their importance, and communicating the tradeoffs. There are also internal projects for the team to deliver better security for Clever employees and all the districts. Overall, new problems will always want to be addressed, which means new systems that will need deliberate planning. Also, novel attacks and “yet another thing to be compliant with” always drive new issues to handle.
5. How do you measure success in your role? What about your team?
Ashley: “Impact”” is very difficult to measure, especially the more senior you are as an engineer. It can’t be measured purely in lines of code or number of documents written. One example I give to younger engineers in their career is: imagine a bug that is causing the company to lose huge sums of money. After days of investigation, it turns out the fix is a one-line configuration change. In terms of lines of code written, this is almost none – but in terms of impact, this is actually huge.
At Clever, impact for me means improving access to education and ease of use of educational applications for teachers, students, and other members of the education system. For my team, it also means supporting the application developers and their ability to use us as a platform.
James: Each of our engineering roles has its expectations defined in terms of the impact you should have, the knowledge and leadership skills you should exhibit, and DEI actions you should be able to make. This allows us to work with our managers to make sure we’re not only doing well in our current role, but that we can aim to keep improving in our engineering career.
Within my team, success involves being able to help identify processes that need to improve, whether that’s improving our system for customer impact or making our engineering lives easier. It also involves all of us making sure we remember to take care of ourselves and making sure the others are doing so as well.
Mark: My main goal is to provide people with a better understanding of potential risks and threats while informing them about the security benefits. This goal informs the work I choose and aligns well with the projects my team takes on. Thankfully, this goal coincides with the team’s overall purpose, to mitigate overall risk for Clever.
These goals dovetail nicely with Clever’s goals. Districts need to be able to provide their data to a secure platform. Applications need to be able to pull the data securely. If the security team can provide both at a scale the world can rely on, then we’ve done a successful job.
The tech stack, tools, and processes for engineering teams
6. What are the languages and technologies you use on your team? Do I need to know these before joining Clever?
Ashley: Clever relies on many micro services that in turn are built on Amazon Web Services. As a general rule, more “backend” services use Golang and more “frontend” services use Node.js and React. You do not need to know these before joining Clever, but familiarity with micro services in general, even in other frameworks and languages, is always a plus.
Briana: On my team, we use React and Typescript on the front-end and Golang on the back-end. It is not necessary to know these specific languages at all! There is always room to learn and grow and it is encouraged.
Mark: Comfort with a web development language and a server-side language is beneficial. Here at Clever, you’ll probably run into TypeScript and Go, respectively, for most of the work. Knowing these languages isn’t a requirement, but knowing similar languages and understanding the threat models, ecosystem, and pitfalls while working in such helps with writing code and assisting other engineers. Infrastructure-as-code (via Terraform and AWS CDK) is also used.
Apart from these, you may interact with other languages and technologies (mobile development, Windows development, user authentication and authorization flows, IAM), and be asked to diagnose issues with such. Again, we don’t expect expertise for this but look for reasonable justifications and explanations for the issues you may face.
7. How do you decide and plan what you work on?
Ashley: On most Clever engineering teams, product managers and engineering managers decide together the priority and scope of projects that need to get done for the team. As an engineer, I can usually voice preference for different types of projects – for example, a more backend project versus a more frontend project, or one product versus another.
This isn’t to say that we’re a top-down organization either. Designers often recognize fairly quickly the pain points in our customer-facing websites, or even engineers notice bugs or imagine large-scale improvements for our internal systems. These concerns are often surfaced informally in Slack and then synthesized into longer-term projects during planning.
James: This is a combined effort between everyone involved: the manager, the product manager, the engineer, the customer, and other engineers. It starts by having a need identified, usually from outside; maybe district admins have been asking for some particular feature, or a student information system is making an update. Sometimes we identify some tech debt that needs addressing, some feature we want to test out for districts, or a problem our engineers are facing.
Regardless of where the task comes from, the product manager is primarily responsible for coordinating the timeline of when tasks are picked up, but with a back-and-forth between all interested parties. We want to know how much effort something is expected to take and how much benefit it will bring to know if it is worth taking on, and this requires input from all sides!
8. What is your team’s structure and process? What kind of regular meetings do you have?
Briana: My team has the typical stand-up Tuesday -> Thursday where we all meet for about 10 minutes and then break-off into our respective project stand-ups. Every other Monday is sprint-planning or sprint-retro and every other Friday is a project sync.
James: Our team, like many of the engineering teams at Clever, has landed on a two-week-long sprint. This means having a session every two weeks to talk about what we got through, what problems we had doing so, and what we’ll tackle in the next two weeks. We also have standup meetings where we discuss this on a more granular level. There are also meetings every two weeks to demo progress in projects to the broader engineering organization, and a meeting each month with customer support to make sure we are making steady progress in improving our customers’ experience with Clever. We also have some other fun meetings every two weeks: a lunch and game session, and another lunch slot with our sister team.
Mark: Overall, the team is pretty flat. There is one manager and five engineers with a general knack for security in different domains. However, the goal is that anyone on the security team could pick up anyone else’s work. We rely on asynchronous communication and documentation for this, leveraging runbooks and tickets to record knowledge. We do have a few recurring meetings (standup, sprint planning, sprint retro), with an absence of meetings on Wednesdays.
What to expect interviewing and onboarding as a Clever engineer
9. Is there anything I should know or learn before joining Clever in order to succeed?
Ashley: Clever tries to be a blameless culture. If a project or a team fails, usually it is not the fault of an individual within that team – it’s often a confluence of factors such as lack of time or due diligence. We take our work seriously, and part of that work is anticipating how to work better together in the future.
James: There’s nothing in particular you need to know or learn before joining Clever to succeed, but if you’re looking to join Clever, I would recommend having some familiarity with OOP practices, architecting software, and being part of team projects. In particular, developing an ability to note what parts of a system – whether software or hardware – need improvement to solve a given problem is something you might use in your time here. If you practice with code challenges, give yourself an extra challenge of doing something like “now what happens if 1 million people use this at once?” or changing the specifics of the requirements.
Mark: Clever helps districts and edtech applications safely get the former’s relevant information to the latter. Wherever you join in this process, there will be many others to learn from and teach. To me, success comes from being able to help solve this issue in a reasonable, straightforward, secure manner. If you believe you can (and enjoy the edtech space), there’s a spot for you.
10. What will my first day(s) be like when joining Clever?
Briana: The first couple days will definitely be full of onboarding stuff and getting your dev environment set-up. Luckily there’s a dedicated slack channel to answer all your questions along the way.
Ashley: You’ll have a whirlwind tour through the company, its many products, its history, and its roadmap. These sessions will be run live – meaning you have the chance to ask people on many different teams what’s happening on the ground right now.
James: Your first weeks, you will be setting up your system, going through a new engineer checklist that includes some exercises to get you familiar with some of Clever’s architecture and practices, rotating with teams to see what life is like all throughout Clever, and taking on some introductory tickets in each team you visit. You’ll probably send out an email to everyone to say hi, join (too many?) Slack channels about everything from your team’s work to what your D&D character is doing. At the end of your first or second week, you’ll be introduced in our company-wide Assembly.
Mark: There’s a lot of context for where Clever operates in this space. You’ll learn about school districts, the applications we work with, and Clever’s role in connecting the two. Also, there’s an introduction to the team you’re on, plus an introduction to the organization as a whole, culminating with light changes to push a change to production.
Learn more about Engineering at Clever
Clever engineering is divided into eight teams: Infrastructure, Data Engineering & Internal Products, App Store, Security, Portal, Identity & Analytics, Secure Sync: Sharing & API’s, and Secure Sync: Dashboards & Data Ingestion. Each team has 4-10 engineers and is supported by an engineering manager, and some teams also have a dedicated product manager and/or designer(s). In total, we have over 65 engineers – and we’re growing!
Learn more about the engineers you’ve heard from in this post!
- Ashley Gau is a senior software engineer on the Sharing & APIs team. As one would expect from the name, the Sharing & APIs team is concerned with what Clever data apps are allowed to access and how apps are shared among Clever users.
- Briana Mayes is a software engineer on the Portal team. The Portal team gets to support the classroom directly with the Clever Portal and help bridge the communication gap between school and home using Clever Messaging, the Clever Parents mobile app, and the Family Portal.
- James Saylor has worked at Clever for 2.5 years. He’s a software engineer on the Data Ingestion & Dashboards team, which is responsible for bringing in data from all sources and make sure they all get massaged into a format that we can work with at Clever.
- Mark Cabanero is a security software engineer at Clever, making sure we protect all data from our employees, our apps, and all our schools.
Interested in Clever?
If you’re interested in exploring what it could be like to work at Clever or if you are ready to submit an application, please take a look at our open positions, submit a general application, or reach out to us at firstname.lastname@example.org!