Below is a post originally written by PowerToFly Partner Stash, and published on January 17, 2019. Go to Stash's page on PowerToFly to see their open positions and learn more.
Three years ago, we built the tools to help our users grow their savings. Today, that investment has spurred the growth of our team and platform.
Meet the team helping Stash grow in our latest Built in NYC feature: https://www.builtinnyc.com/2019/01/16/spotlight-wo...
*BuiltinNYC is a paid partner of Stash.
Below is an article originally written by Jeremy Quittner at PowerToFly Partner Stash, and published on May 26, 2017. Go to Stash's page on PowerToFly to see their open positions and learn more.
So how on earth did I get here? The answer is pretty simple.
It seemed to me that startups, and particularly fintech startups like Stash, represent growth. Globally such companies pulled in $17 billion in venture capital in 2016, an 11% increase compared to 2015, as Forbes reports. Stash is one of these companies, and its own organic growth–it's closing in on three quarters of a million customers–since launching has been impressive.
Stash's mission–helping consumers without a lot of money or experience with investing learn sensible ways to put money into the markets–appealed to me. I also thought working at Stash developing content for investing customers, would be a good way for me to put my skills as a journalist to work, while learning first-hand how fintech companies scale.
Notes on my first week working at Stash
Before starting, I had a flash of panic that my new job might resemble scenes from Dan Lyon's book Disrupted, with me feeling stupidly out of place in a frat house atmosphere of beer pong and nerf fights and bouncy ball chairs.
Happily this has not turned out to be the case.
It could be the company's mature atmosphere reflects its roots in the highly regulated financial services space. More likely, it's an indication of the company founders' experience: Both Brandon Krieg and Ed Robinson had either started other companies or had previous careers in finance before launching Stash.
About the only hat-tip to Silicon Valley-esque culture seems to be the kitchen stocked lavishly with snacks and a dedicated pump for cold brew coffee–that last detail never ceases to impress me.
The majority of Stash's employees may be younger than me and many of my journalism colleagues, but they're really smart and motivated, and they take what they're doing extremely seriously. Their sense of excitement about building a company focused on something new in Fintech is palpable from the moment you walk in the door.
Growth and ideas
And because the company is still small, it doesn't have the rigid hierarchy customarily found at big enterprises. The company executives work alongside everyone else, and they circulate around throughout the day, checking in and asking plenty of questions. Everyone's focused on increasing the rapid growth of the company, and employees are encouraged to share and test out new ideas on a daily basis.
In the course of my first few days, my colleagues have pulled me into marketing meetings that introduced me to new concepts about how content can be linked to customers, while others have asked me for input on naming soon-to-launch investment products. Engineers have asked for feedback on the latest features they've designed to improve the app.
Most of this is novel to me. In fact, I'm in an entirely new world. And that's exactly where I want to be.
I'm grateful for all I've learned, writing about startups and entrepreneurship for publications at some of the largest media enterprises in the world. Now I'm really excited to help a small company with a great idea grow into something really big.
Below is an article originally written by Kahne Raja, Lead Engineer at PowerToFly Partner Stash, and published on March 26, 2018. Go to Stash's page on PowerToFly to see their open positions and learn more.
- Cracking the Coding Interview by Gayle Laakmann McDowell
- Clean Code: A Handbook of Agile Software Craftsmanship by Uncle Bob
- Extreme Programming Explained by Kent Beck
- Stash Invest Careers. Join us!
If you love clean code and you want to help disrupt the fintech industry, then look no further!
Recently, we here at Stash have upped our recruitment game. Over the past few months, I've seen the company double with an outstanding crew of new engineers who truly care about what they do and how they do it. We are dealing with scale issues on all fronts and we need your help!
The mission at Stash is clear. Build financial systems that work for everyone — not just the wealthy.
It's a big challenge and we have a long way to go. A big part of that is growing the team with the right people.
As an engineer at Stash myself, I regularly host technical interviews. Here are some of my notes on what it takes to pass our first stage code pairing challenge.
Back to basics.
Interview preparation takes weeks… even months. Do it in batches and do it well. Enjoy the nostalgia. Enjoy the beauty of math.
Your regular tech work life patterns and practices are important but quite often they are not so helpful when doing interviews. Here are some ideas to help you prepare for the engineering interview at Stash:
- Read Cracking the Coding Interview by Gayle Laakmann McDowell.
- Read Extreme Programming Explained by Kent Beck.
- Watch as much Uncle Bob talking about SOLID principles as possible.
- Ask a friend to test you at a whiteboard over lunch.
- Choose a language and get comfortable with it (without an IDE).
Our first line of code.
When I sit down with you to pair online @coderpad, this is what I am looking for:
- A focus on data structures and algorithms.
- At least one passing unit test.
- A simplification of complex ideas.
I want you to start by slicing off a single conditional in two to three lines of code. Something we can compile, run, test, and discuss.
Example challenge: Leap Year.
Problem statement: write a function that returns true or false depending on whether its input integer is a leap year or not.
If we can get to this place within a few minutes, that is a great start! We should then be able to complete a number of variations within 10 to 20 lines of code.
Try to avoid spending too much time on the following:
- Web app / CRUD design patterns like Controllers and Repositories.
- Database structures and persistence strategies.
- Language comparisons and platform specific features.
After each interview, I assess candidates on the following metrics. Ability to think on your feet, communication, critical thinking, creative problem-solving, debugging, speed, management of competing priorities, organizational skills, and test driven.
Following this initial online code pairing session, you'll be invited in for a half day session with a number of colleagues.
At Stash, extreme programming and solid principles are at the heart of what we do. We move fast and embrace change.
Please don't hesitate to hit me up on twitter — @kahneraja. I'm always happy to help a candidate get ready for an awesome new career at Stash.
Below is an article originally written by Brian Beavers and Christina Chang at PowerToFly Partner Stash, and published on July 25, 2018. Go to Stash's page on PowerToFly to see their open positions and learn more.
Stash's employee and customer base have been on a rocket ship with no signs of slowing down. As our design, research, and marketing team have continued to grow at Stash, we realized that we needed a new way of getting eyeballs on our work and getting timely critiques.
Like many product design teams, we use a combination of Sketch + Zeplin for design, feedback, and specs for engineering. But shoehorning feedback into Zeplin seemed like a misuse of the tool to us. We take vacations and sick days. We are often heads down busy with our own tracks of work on our squads. We're in meetings or discussions throughout the building and can miss important threads on Slack or Zeplin. We often lack context behind certain projects, thereby missing the hypothesis and goals behind a particular solution.
So my first pass at revitalizing how we do design critiques was by setting a standing one hour meeting every Wednesday afternoon (midway through the week to allow for time to prioritize design work and iterate within our squads) with the following mission:
The purpose of this meeting is to have open and timely critique among team members and stakeholders. It is also to foster a more collaborative, human environment where we gather around, look at the work in-progress, and discuss our product solutions with each other in real life. The hope is that this will lighten some of the Zeplin discussions, give everyone a dedicated time to review work, push for more design consistency across squads and leave Zeplin for more engineering-based usage.
And this was the format:
- 1 hour long, 10–15 minutes each per squad or project (with timer)
- Take the first five minutes of critique to walk around the room to look at the work printed
- Write notes, questions, or feedback on stickies in relation to the project
- To keep the meeting efficient and keep everyone's attention, please take long discussions offline.
- No phones or laptops
- Stand up and discuss around each other's designs
- Attendees: All product managers and product designers from each squad, ux researchers, copywriters, and marketing designers
- Print out your flow or design(s)
- Set the stage for the audience. Walk them through the challenge or problem statement, the goals, and the hypothesis.
- Tell the audience what type of feedback you're looking for (user flow, interactions, general UI, copy, etc.)
- Tell the story. i.e. "The customer will be coming to this page from a button on home. Only customers who have a bank linked will see this."
- Tell the audience the goal(s) i.e. "We want to encourage customers to Auto-Stash more than $15/week."
Coordinator + Timekeeper (Another designer or PM):
- Focus the audience on the critique, the goals, the hypothesis, and the feedback the designer is looking for.
- Please keep everyone's time in mind so that all designers have enough time to present; especially if lengthy or non-relevant discussions come up
- Make sure everyone has the opportunity to speak up. Oftentimes you'll find the quiet ones provide the most valuable insights.
- Ask clearly defined questions i.e. "What were you trying to achieve with the placement of the icon there next to the headline?"
- Be candid and honest. It shouldn't be a compliment sandwich. Feedback should sound like, "Having Stash Cash preselected feels like an efficient way to move the customer through the funnel." or "When you show too many payment options, it gets confusing and overwhelming, especially on mobile".
- Tie everything back to the goals and/or hypothesis. It should not be about liking or disliking the design. How is it meeting or missing the business and/or customer goals?
- Provide directional suggestions, but avoid problem solving
This product and marketing design critique format worked for awhile. Then we ballooned to 25+ attendees. Having 25+ people stand around an 11x17" print-out of a flow required magnifying glasses. After a few months of print-outs, we pivoted to a structured Google Slides format where the goals, the hypothesis(es), and link to the prototype or Zeplin were presented on a TV.
*This image is for illustrative purpose only.
But we started to lose focus. Then attendance started to dwindle as work that was being presented became less relevant for some in the original meeting invite. And then we started to feel like the feedback wasn't quite as timely or as focused as it had been in the earlier iterations with 10–12 people.
So we went back to the drawing board.
Christina Chang (one of our new Product Designers at Stash) had a friend that recommended an intriguing critique format called Tactical Design Critiques. The dramatically different approach convinced us this was worth trying:
- Small groups only — for us this meant only involving our small product design team of 6–7
- One designer comes prepared with work to get critiqued, throws it up on a projector or large TV. The designer can't say anything to explain their work to the rest of the group.
- The rest of the group goes around the table, and one at a time says onepoint of critique or tension. Everyone is discouraged from giving compliments and building compliment sandwiches.
- If you don't have a point of critique, you can skip. If you don't understand a person's point of critique, you can ask them to clarify.
- Most importantly, you cannot ask the designer any questions and they can't jump in to respond and clarify.
- At the end of 25 minutes of critique, the designer can take 5 minutes to summarize and explain how they will take the feedback into their designs.
At first, this format felt like it was potentially limiting since designers are so used to providing context and defending their work. But, we quickly discovered that the designers became silent note-takers scribbling to capture feedback, and thereby less attached to their own work, able to step back and simply listen.
Because it often feels too intense in normal critiques to give so many suggestions, this format created the opportunity for comments on everything from copy to color to user flows to consistency. It's a twist on user testing, except with users that happened to be designers you work with.
We've found it to be a very refreshing way to deep dive into one user flow at a time, and hone in on problem areas without involving egos.
Design critiques, much like design itself, can never truly be "perfected" or "done", in our opinion. Audiences change, timelines change, team dynamics change, team needs or priorities are constantly shifting. As they say, change is the only constant. We're still figuring out what works best for us.
References to design critique formats we used to iterate on ours: