We chatted with our software engineer, Andrea Minhas, to learn more about her day-to-day, what it’s like to work on the web team, and her favorite parts about working at Beyond Finance.
How long have you been on the team and what do you do?
I’ve been with Beyond for two and a half years now. I’m on the web team, so I help maintain and build features for a variety of user-facing web apps we have.
How did you first get interested in engineering?
I was working in marketing for around three to four years, and the way that my organization was structured was that anything related to social media or “web” was in its own little digital department. I got really interested in how things worked with our website, so I started doing my own WordPress sites on the side. I just found it very interesting. I was always looking for the newest tech thing in marketing, and I thought, “I could be on the other end of this — I could be actually involved in the tech and have a real insider’s scoop on it.” I had the opportunity to go to coding bootcamp, and lo and behold, I’m here now!
What kind of tech do you work with?
The primary framework that we work with on the web team is Ruby on Rails. We have a little bit of Javascript in our apps as well, and there are few engineers on our team who focus on that front-end side, but I personally haven’t touched JS here too much. I have to say, I actually love the simplicity of working with just one or two languages and frameworks.
What’s your team dynamic like?
My favorite part of Beyond is the culture. We all work really well together, and it’s nice to be able to learn from everyone. Today, my coworker posted in a Slack thread that she wanted to get some thoughts on a project. And we all chimed in and there was really no ego to it — just, “here’s what I think.” I feel like we try to approach things from the perspective of what will make this easy for all of us, instead of “it’s my way and this is how things should be done.” It’s really about what would benefit the larger team, and everyone is open to helping each other.
Could you break down your day-today at Beyond — perhaps using today as an example?
9:00 a.m.
At the start of the day, I like to check to make sure there’s nothing urgent that immediately needs my attention.
9:30 a.m.
At this point, I’m either checking our “Code Review” Slack channel to see if there’s a review someone hasn’t already picked up, or I’m coming back to a project I reached a stopping point with yesterday.
Today, I’m continuing work on a larger project involving building out an API that pulls from Salesforce all the data a client might need to see in their dashboard — when and how much their next deposit is going to be, what their current balance is, stuff like that. We’re calling the new API “Glue” because we’re basically gluing the front-end, the consumer-facing web application, to the Salesforce data. It’s a replacement for an older, outdated API. Because of the scale, I have a partner on the project. We work on the design together, plan out our sprint cards, and divvy up the work. It’s kind of a non-traditional pairing situation and it’s been really fun.
10:00 a.m.
If there’s a team meeting on any given day, it’s usually at 10:00 a.m. Today is Wednesday so we have our “Mid-sprint Check-in,” which takes the form of a virtual, asynchronous Slack thread (so not strictly a meeting!). Sprints involve breaking larger goals from product managers into smaller cards, and setting targets for what we can accomplish in one-week increments. So today’s check-in is really about asking, “How am I progressing with my work? Am I going to be able to finish it this week?” And if the answer is “no,” we figure out what the blockers are and where someone else can step in and help get things unblocked.
The other meetings that come up at 10:00 a.m. are a Tuesday stand-up, a “Demo Day” (every other week on Wednesdays) where we share the things we’ve been working on with each other, and a Thursday virtual, async stand-up. This type of virtual check-in is nice because it allows us to see each others’ statuses and respond when we have a free moment, while cutting down on meeting time.
All in all, we now spend pretty minimal time in actual meetings. We were getting a little meeting-heavy when everybody first went remote, so the team submitted some feedback to management about needing more time to code. The engineering leaders really value input from the team so they made that happen.
10:30 a.m.
Last week, we got one of the API endpoints working, so this morning was spent incorporating that into the app. My project partner and I are working on a specific page that lists all the transactions a client has made. So we’re really just pulling it from our new Glue API into the Beyond Finance web app.
If it were a Friday, we’d have our weekly “Retro” meeting at this time. These can be opportunities to say, “This project ended up taking a lot longer than intended — why did this happen?” Or, “Why did this bug cause a spike in errors this week?” And then, “How can we improve on this in the future?” But Retros are also an opportunity to review what went right. We like to recognize what went smoothly, and give people on our team a shoutout for doing good work.
12:00 p.m.
Noon is usually when I take my lunch, but it floats around depending on if I’m in the middle of a Slack conversation, or have an early or late meeting. My lunch break tends to span between half an hour to an hour, depending on how much I have going on that day, both personally and with work.
One of the things that I really like about Beyond and our team is that we’re pretty flexible with schedules. You don’t feel like you can’t step away from your computer for a bit if you need to. I always have the flexibility to just post in Slack and say, “Hey, the sky is falling and I need to go take care of the sky falling.” Or, if I already have a scheduled doctor’s appointment, then I’ll let the team know ahead of time that I’m going to be a little late, or leave a little early. And that’s fine.
1:00 p.m.
After lunch, I was able to continue work on our Glue API. My project partner and I worked on hammering out some of the details because this is something new. We chatted for a bit with one of the PMs about what exactly he wanted to display on the page in the event of an error. Then we talked to different members of the team and asked, “can we get your input on this? Your thoughts? How can we best handle this?”
We do a fair amount of that, actually — especially on bigger projects because for one thing, we like to be cohesive, but also, everyone’s work impacts everyone else on the team.
If this was the first Tuesday of the month, we’d be having our “Tech Roadmap” meeting at this time as well. When you’re developing an existing app for a while, you start to develop tech debt — things you need to clean up and improve. Maybe we had to build something really quickly to get out a feature and we just kind of did it “quick and dirty” to get it working, but we actually think we could do it in a much better way if we had more time. So we’ll look at that in this meeting. We may also take this time to say, “Hey! There’s this cool new Rails design pattern people are using. Why don’t we throw a card on the tech roadmap for one of us to explore that?” We try to explore new ways to do things.
Tomorrow around this time (specifically Thursdays at 1:15 PM), we’ll have our sprint planning meeting. We’ll go through what team members might still be working on and when they expect to wrap that up. Then we look at the cards entered by product management or our team members, and assign them out to different people. But we also have the opportunity to say, “That’s a card I want to take! That’s something I want to work on,” instead of something always being assigned to you.
2:00 p.m.
Yesterday afternoon, I’d gotten to a stopping point where I was like, “Okay, I’ve pulled in this new data and I’ve gotten this page to display with such-and-such data so far.” But there were still three more data points that I needed to chat with my project partner to figure out. So this afternoon, we hopped on a Slack call and just talked about where we’d be pulling those from, how it’s currently structured in Salesforce, how we want to change the structure to use fewer API calls, and which application we want to put that code in — our main web app or a special client gem we create. We also started some light planning on the work we want to do next week, and how we want to break that down.
3:00 p.m.
I like to use the afternoon for some real heads-down coding time. That’s what I did today.
4:00 p.m.
I try to stop coding around this time each day if I can. If I’m in the middle of something, I may keep going until five, but what I’ve really been trying to do is take time to continue my engineering education. While I code almost exclusively in Ruby now, when I first started here I had more JavaScript experience. So now I’m looking into some of the intricacies of the language, and really diving into those specific, vanilla Ruby nuances. In this last hour of the day, I’m usually taking time to read a book or read an article.
This actually came out of a one-on-one with my supervisor at the time, Sergio (our VP of technology). I asked him what he did to improve when he was at my level, and he encouraged me to take the last hour of my day to just read whatever I wanted to, to help me brush up on my skills.
Does your team ever do pair programming?
We don’t really do traditional pairing where one person “drives” and one simultaneously reviews the code. What we do have is a weekly one-hour pairing session where you work together with a more senior engineer. It’s very much like “Hey, I want to learn a new skill and I know that you have a lot of experience with this — let’s work on something together so I can learn more about such-and-such technology or a specific piece of our system.” It’s really nice to have that. It’s a time for us to get help, is the way that I like to put it.
The other version of “pairing” that might occur is like the partnership I’m in now with my current project. This kind of “pairing” only happens rarely, but with a huge project it can be helpful to collaborate with someone through meetings and planning, split up the coding work, and do that individually.
How has the transition to fully remote work been?
Because of the nature of development work, we were already flexible when it came to working from home. If you weren’t feeling well, but you still felt like you could get some work done — or for those on the team who have kids, if school got canceled for the day — they could stay home and still get work done. So in that sense, I felt like we were already pretty flexible.
But the transition to fully remote? I mean, it went really smoothly. For me, it was a bit of an adjustment to have so many remote meetings because I had never been at a company that had such flexibility with remote work. But it’s awesome now. I love it. I like that I can go to my kitchen and grab lunch. I like that I can make my own coffee. And I feel like when I really need heads-down focus time, because I’m at home, I can get that. And then, of course, it’s nice not to have a commute.
You mentioned you love the culture on your team. Do you have any other favorite things about being an engineer at Beyond?
There are a couple things. One is our “Demo” meetings. I don’t know that it’s something very common on other engineering teams. It actually came out of our transition to remote work. We thought: “How can we stay on top of what everyone else is working on too?” Each “Demo Day,” someone on the team does a super informal presentation that covers what the initial business problem was, what the engineer’s been working on, and what they’ve already done. It’s nice to feel like we all know what our teammates are working on.
My other favorite thing is the people here. Everyone I’ve encountered — on my team and throughout the rest of the company — is genuinely kind and respectful. And besides that, there’s not the mentality of one certain demographic that owns engineering, or owns finance. It’s not one homogenous type of employee. And I think that diversity breeds understanding, which is incidentally one of the reasons I think everyone is so approachable, across the entire organization.
To learn more about life at Beyond Finance and explore open roles, check out our Careers Page.