For the second installment in our “Who is Valon” series, we decided to capture a day in the life of a Valon Software Engineer. Michelle Deng was one of Valon’s earliest hires, and below she gives us a look into how and why she champions homeowners!

What’s your role at Valon?

I’m the Engineering Manager of our Payments team. Valon’s engineers have a few types of formal roles: individual contributor (IC), tech lead (TL), engineering manager (EM), and tech lead + manager (TLM).

I work closely with a Tech Lead on my team, and together we’re responsible for the technical direction and output of the team. I also support the performance and long-term career paths of the engineers on my team. Finally, I do my fair share of coding as well!

How is working in mortgage servicing different from an engineering perspective?

Well, my prior job was more consumer-focused. Compared to a lot of other tech companies, mortgage servicing has more complex regulations and business logic. So, treading the balance between modeling that correctly and translating that to elegant, scalable systems, while also building quickly, nimbly, and with many unknowns at the current moment in time, that’s probably what’s most unique to mortgage servicing.

​Why Valon?

I joined Valon in October of 2019, quite early compared to most people here. At the time of my interview, there was one other engineer (who wasn’t one of the founders), and I was coming out of a job at a very large company. What I wanted from my next role was to work somewhere very tiny, where I could learn how to build things from scratch.

​Large companies build everything in-house. When you decide how to do something, there’s already a canonical in-house tool with which to do it. There are in-house support systems whenever those tools need new features, or when something goes wrong.

That’s not true at a startup—at a startup, you build some things from scratch. Otherwise, you need to decide when to build what for your current set of needs, without over-engineering. Then you decide when to rely on tools that other enterprising engineers out there have built, when to use third-party libraries, things like that. So, a big draw of startups, for me, was becoming more acquainted with the ecosystem out there.

I wanted to work somewhere where it felt like every minute of my day was truly valued by the company and my team. I wanted to work somewhere where the core product had a strong utility, where it could make an important part of the user’s life better.

What fun projects have you worked on at Valon?

I’ve done a lot of contributions for design systems work at Valon, even though it’s not really tied to any of my teams. Another engineer, Paul, and I have set foundations for a lot of the web platform work that Valon has done. I’ve really enjoyed working with Paul and Katy to come up with the right design system primitives, and then to create compliance that encapsulates them, so that other developers (ranging from much to little React.js experience) can use them effectively to create flexible web pages that our web application needs.

Do you have any advice for engineers interested in working at a startup?‍

Think about what is most important to you, what kind of learning you want to do, both in terms of tech stack and business problems. Valon has tons of complicated real world business logic backing the system.

Also know that it’s early! Things are flexible, the tech industry is very forgiving, and you’re not picking a road that will lock you in forever, so if it doesn’t work out, just try somewhere else!

What do you think makes someone a good fit for Valon?

Really wanting to build a real world utility, and wanting to have a promising business organized around that utility, is something that’s very common of folks who choose to come to Valon. People choose us because they want to build this thing that they think will be good for the people they’re building it for.

Walk us through a day in your life.

On an average (remote) work day, the pattern will be:
‍
Wake up: Do my own thing for a while (including some form of coffee). Then, I’ll respond to Slack messages.

Eventually between 11am and 1pm, the first meetings start showing up on my calendar.

‍Between 1pm and 5pm:

‍Our company chooses to block meetings between 1pm and 5pm, and during that time the focus is just meetings, about half of which are team planning or cross-team project oriented content. Then, a few interviews or hiring calls scattered in there.

‍​

After 5pm:

Things taper off to some follow up conversations as a result of the day before, one-on-ones with various folks on and off my team, and some code reviews.

‍

‍Later:

‍After I feel like that queue tapers off, I’ll check off my project work in order of what is most urgently needed today. I usually fit in my individual contribution work toward the evening.

Thanks so much, Michelle. Lastly: what are you watching on Netflix?

‍Hm… Korean dramas!