Become a PowerToFly VIP
For less than one coffee a week, receive exclusive content, access to live chats with female thought leaders, and more when you sign up to become a VIP!

Get Ready For An Awesome New Career At Stash

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.

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.


Inside Tips for Landing Your First Programming Job

Partner Content

Below is an article originally written by Sarah Gray, Engineering Manager and Software Engineer, at PowerToFly Partner PromptWorks, and published on March 10, 2017. Go to PromptWorks' page on PowerToFly to see their open positions and learn more.

As the spring semester winds down, I've been getting meeting requests from soon-to-be grads to discuss how to get that all-important first programming job. I find myself giving the same advice over and over … which means it's probably time for a blog post. So, these are my inside tips on how to have an advantage when trying to land your first full-time gig.

Background: Why is it so Hard to Hire a Junior Programmer?

Most employers will want to spend significant time on-boarding and mentoring junior devs before considering them independent contributors. Though junior developers are needed and employers want to provide a strong foundation, that ramp up time is expensive.

It's easier to invest in a junior candidate if they demonstrate that the on-boarding period is money well spent. Dedicated, curious juniors are priceless. As bootcamps continue to saturate the market for junior developers, junior candidates of all stripes are wise to differentiate themselves. Here are some tips on how to have an edge.

N.B.: You don't have to follow all of these suggestions. Acting on a smattering of these tips will help you stand out during the job search.

Be a Known Quantity

It's easier to know that a junior is a good investment if you see them participating in the local dev community. That participation hints at a deep desire to learn and grow. And, as a job seeker, I find personal connections to be the most effective way to look and apply for gigs.

  • Go to Meetups that you are genuinely interested in. Ask questions, meet people.
  • Participate in your local dev slack team. Ask questions, meet people :)
  • Develop some sort of public, professional presence. Think twitter, stackoverflow, or linkedIn.
  • Blog about what you are reading, your projects, and your experiences. Long format communication really helps the reader understand your thought process. Show off your problem-solving mindset and demonstrate grit.
  • Consider getting a mentor in your local dev community. Mentors can be a welcome touchstone as you suss out development opportunities and begin your career.

Develop a Resources List

Many employers will want to know how you stay on top of industry developments or may ask you about current events in the tech world during the interview. It's good to be informed. And, in the long run, it's advantageous to be aware of changes within the fast-paced software industry.

Take some time on a regular basis to brush up on events in the field. Here are some of my favorite resources:

Have a Low Signal to Noise Ratio in Your Resume

Sigh. This is the crummy part where I tell you to edit away things you toiled over and care about. The point of your resume is to make a strong case for yourself, knowing that a reviewer will spend 30 - 60 seconds reading your CV. Your related skills and experience should shine, but that means being a merciless editor and focusing your resume content.

  • The usual resume advice applies. Typos, poor organization, and space filler will dilute the impact of relevant information.
  • Make it easy to scan your resume for technical skills and how you met challenges. Use action words like "optimized", "researched", and "implemented." Back action words up with quantitative evidence if you have it, eg., "optimized our data compression algorithm, increasing our Weissman score from 2.8 to 5.2."
  • If you have deployed code and you can show it off, make it easy for your reader to access it. Github and Heroku links are great. Make sure that your code is well groomed and has a thoughtful README.
  • Note all of the professional development stuff you are doing like attending Meetups, blogging, etc.
  • Briefly cite unrelated prior experience when it demonstrates consistent employment or increasing responsibility.
  • Only keep fluff sections, like hobbies and volunteer experience, if they relate professionally. For example, note your passion for Ultimate Frisbee if you are applying at Wham-O, nix it for all other jobs.
  • Keep the objective section if there is a compelling reason for it, like if it's the only way to marry some other area of experience with your development experience – and that combination directly relates to your job search.

Further Resume Reading:

Shameless Plug

Oh hey, you made it to the end of the article! Well, since you are still here, let me tell you about our job openings. We love Philadelphia and are committed to making it a great place to be a developer – we hope you'll consider working with us.

Career and Interview Tips

How The​ ‘Tell Me About Yourself' Question Can Set You Apart

By Carroll Welch - Originally posted on iRelaunch

No matter how it's worded or where you hear it, if you're relaunching, you'll be asked by someone to tell about yourself. It may be at a barbecue, an informational interview, a college reunion, a screening interview or a conference. Depending on the context, this question could be asked as:

  • What should I know about you?
  • What's your background?
  • How can I help you today?
  • Do you work outside the home?
  • Tell me in your own words, who is [your name]?
  • Tell me about yourself.

Whether formally or casually asked, 'Tell me about yourself' is an opportunity. When you have an articulate, confidently delivered response that takes into account what the listener wants to know, you can distinguish yourself and make a positive impression.

Here are three points to help you prepare. (For convenience sake, all forms of Tell Me About Yourself will be referred to as TMAY.)


Virtual talks for women by women to give you the edge you need to elevate your career. Includes discounts to our bootcamp partners, invites to events and more.


1. Prepare. Don't wing this. Your response to TMAY is an important part of how you market yourself, just as your resume and Linked In profile are. It's hard to come up with a good response to this deceptively difficult question on the fly. By preparing bullet points in advance that you've committed to memory and can tweak and integrate into conversations as appropriate, you'll be ready.

2. Consider Your Audience. What a prospective employer wants to know about you is not the same as what your best friend's spouse wants to know at the neighborhood holiday party. Don't reflexively tell the person what you want to tell them. Instead, think about what they might want to know and make it part of your response.

  • Strengths. For job interviews, make sure that the beginning of your response includes 2-3 key features about you that would be compelling to that employer. Here's an example:

Q. Tell me about yourself.

A. I'm a career relauncher and project manager with 10 years of experience in pharmaceutical marketing. I've always loved project management work because I can use my excellent organizational and technological skills to make sure that all the moving parts of a project sync. During my 7 year career break, I became a trustee for my local public library and chaired our technology committee so I've been able to continue to use and hone those skills. Also, I was a four year DI college athlete, and when I worked at Rose & Whitney as a project manager, I was consistently recognized for my strong team orientation, and how I coordinated and communicated well with all team members, regardless of seniority.

  • Relauncher Status. It may be okay in some circumstances to explain that you're exploring, researching or considering more than one relaunch career path. Usually, this will likely be in a social or casual situation or in informational interviews, but not in job interviews. An example of how to explain your 'undecided' status as part of a TMAY response to a networking or social contact who might be able to help you is:

I'm a relauncher and before my 10 year career break, I practiced as a health law attorney at a large law firm for 5 years. I'm planning to return to work as a practicing attorney. I'm currently exploring either a path to a hospital legal department position or practicing elder law at a small firm. I've always been interested in health care and was pre-med in college. I became interested in elder law when I helped my parents navigate some challenging long term care, Medicare and estate planning issues.

  • No Chronologies. Your response to TMAY should never be a chronological story that starts with where you were born or what you did after grad school. Instead, it should highlight who you are now and what your strengths, 'value adds' and/or career relaunch plans are.
  • Mind the Time. Your TMAY response should be between 30 seconds and 90 seconds long -- at the most. You'll lose your listener's interest and attention after that.
  • Fluid Not Static. Your TMAY response will change over time, as your goals and targets do. Check in on your TMAY response periodically to be sure that it's still doing the job of conveying an accurate picture of you.

3. Practice Delivering with Confidence. Your listener in some cases may remember how you delivered your TMAY response more than what you've actually said! Practice with a friend, in front of a mirror and/or with the recording feature on your phone. If you're not feeling particularly confident about your TMAY response at first, pretend! With repeated delivery, you'll get better.

Many job searchers and relaunchers flounder when asked to tell about themselves. By nailing this question and making it a positive part of how you market yourself, you'll become more memorable and compelling as a relaunch candidate.

This article originally appeared on the iRelaunch blog. iRelaunch is the pioneering company in the career re-entry space with a global community of over 65,000 individuals who are in all stages of returning to work after a career break. We also work directly with more than 55 blue chip companies to create career re-entry programs. Sign up to learn more about how we can help you return to a rewarding career.

The Checkr Team

An Engineer’s Guide To Interviewing at Checkr

Below is an article originally written by Vannaro Lim, Technical Recruiting Manager at PowerToFly Partner Checkr, and published on February 13, 2017. Go to Checkr's page on PowerToFly to see their open positions and learn more.

Interviews are tough! Most companies follow an archaic process that does not properly assess an engineer's talent. From CS fundamentals to data structures that are no longer in use, interviewers tend to fall in the trap of testing things that are neither applicable or relevant to the job. Why on Earth would anyone want to subject themselves to that? A good interview should allow you to show off your skill set and determine whether you want to work there.

We've all spent endless nights cramming for an interview with no clue as to what will or will not be asked. At Checkr, we wanted to make the process better from an engineering perspective and remove all the things that make us cringe while interviewing. That is why we put a lot of thought and empathy into designing our interview process. Our goal is to make it to be indicative of who you are as a software engineer. The hardest thing isn't finding talented engineers, it's finding engineers that people want to work with. Our ideal candidate needs to embody Checkr's core values:

drive and grit, humility, smart and resourceful, connection, learning, excellence with purpose, transparency, positivity, and appreciation.

What we look for in a candidate

An ideal candidate to us is someone who likes to explore and learn things that are outside their scope and comfort. It is someone who can demonstrate a high degree of drive and grit tempered with authenticity. Someone who values forming real and meaningful connections in order to create an inclusive community which helps bring the entire team up rather than just themselves. We value those who exhibit honesty and appreciation from the simplest solution to the most complicated one. People who appreciate diverse backgrounds and understand that diversity is not just an initiative but a mentality tend to thrive at Checkr.

Our Web Application Team working hard =)

"Who you are at home is who you should be at work. We want the best version of you and want you to be comfortable here."

— Khoi Ho (People Ops)

Key To Success

Communication, communication, communication! This is the key to success at Checkr. We are looking for engineers who are able to convey their thoughts, help us understand their process, and most importantly, ask for guidance when they hit a roadblock. We are here to help! We want our interviews to be the best representation of who you are as an engineer. Don't be afraid to ask questions, this will allow your interviewer to better understand your problem and provide the right guidance for you to succeed. We want you to be part of the Checkr team.

Environment Setup

In order to avoid any hiccups or unseen problems, here is what you will need during the onsite interview:

  • a working datastore
  • a working dev environment with a web programming language of your choice
  • a testing framework

We don't mind what languages and tools you're using, just use the ones you're most comfortable with!

Here's what our interview process looks like:

1. Resume Screen

We're evaluating whether you're a good fit for the position you applied for. We receive many amazing candidates but not everyone will be a good fit for Checkr or vice versa. We're not interested in what school you went to, what your GPA was, or even what clubs you were a part of. What matters most to us is that we fit well together and that you're passionate in what you're doing.

2. A Call with Our Technical Recruiter

This process takes about 30 minutes and the main focus is talking about your interests and what it is you're looking for. It helps us determine whether we may be a potential fit for each other.

3. Live Coding Session Done Through Coderpad (We're fans of Python, Ruby or node.js but any language is fine)

As a background check company, it's crucial that we match the identity of the applicant with any data we have, pull or find. The accuracy of determining and matching names is our business. Our live coding session consists of a name matching exercise that is the foundation of your success at Checkr. We found out quickly this is a great indicator for future performance and success on the job. The challenge will consist of verifying names in a given list. You will have a few test cases to test your solution against and one bonus transposition question.

We give our candidates an hour to complete this exercise. We're looking for code that is clean, DRY, readable, and expressive. We want you to talk us through your process, help us understand your decisions — your interviewer is your best advocate. They will help guide you through potential roadblocks and help discover things that you may not have seen.

4. Onsite interview (4–5 hours — 5 interviews)

Our onsite interview is meant to simulate what your day to day would be like at Checkr. These interviews will consist of design, implementation, debugging and refactoring. You can use whatever programming language, environment or editor that you are most comfortable with. We want our interview to be indicative of who you are as an engineer, so please feel free to use any online resources you would normally (Wikipedia, Google, Stack Overflow, etc.) during work. Remember, your interviewer is a collaborator, share what you're thinking and ask for help when needed.

A. Whiteboarding Architecture

This portion is to demonstrate your understanding of microservices and explain an API request life cycle.

B. API Design

We will provide you with a dataset that needs to be imported into your selected datastore. You will be tasked in building out a light JSON API that can read, delete and update. The objective of this interview is for us to gauge your understanding of your datastore, web framework and approach to testing.

C. Object design

This exercise focuses on designing an existing feature at Checkr. More specifically, we'll collaborate on exploring a rule-based system to assist in automating background check processing. Areas to cover will include building a data model and its respective application interface for rule evaluation. Be ready to discuss your schema and thoughts on how to optimize for performance.

D. Refactoring

The slot is used to understand how you communicate, collaborate with your interviewer, and familiarity with your selected language. We want you to show us how you work in your natural dev environment from utilizing known and unknown resources to asking follow up questions, we are curious to see your workflow.

5M background checks reached — 2016

After the interview, we tend to move fairly quickly! You can expect to hear from us within 48 hours with a decision. We strongly believe in transparency so providing feedback is crucial. We want to thank you for taking the time to interview and expressing interest in a career at Checkr! We hope your experience at Checkr is delightful and as pleasant as humanly possible. If you have any questions at all, please let your recruiter know so we can help ensure your success. On behalf of the Checkr team, good luck!

JOOR New York office
Joor Inc

Interviewing for the Tech Team at JOOR

Below is an article originally written by Katie McKew, a DevOps Engineer at PowerToFly Partner JOOR, and published on September 24, 2018. Go to JOOR's page on PowerToFly to see their open positions and learn more.

Interviewing is a two-way street: a good interview process should be designed to ensure that both the candidate and the hiring committee have all the information they need to make the right decision. As someone who has (literally) been on both sides of the table in the interview process at JOOR, I can say confidently that our interview process is as much about getting to know you as it is about showing you us. When you interview at JOOR, we try to show you as much of us as possible!

If you're curious about how the interview process works at JOOR, I hope this post answers your burning questions — and if not, reach out to us!

Who are the interviewers?

We want you to meet the people you would be working with on a day-to-day basis! For that reason, technical interviews for engineering positions are conducted by our engineers. The non-technical interviews are conducted by people from other teams you'd be working closely with as an engineer at JOOR, like Product and QA. You'll also get a chance to meet managers, team leads, and potentially some C-level team members (depending on availability) who can tell you all about higher-level company initiatives.

What are the stages of the interview process?

1. Initial contact

Whether you reach out to us first or we reach out to you, you will be in contact via email with someone from our Talent Team throughout your interview process. They will work with your schedule and those of JOOR interviewers to coordinate the best times to meet. If you have any questions during the process, your Talent contact is the one to ask!

2. Phone screen — 30 minutes

Our hiring team will schedule a quick 30-minute phone call to chat with you about your background, your current team structure, your tech stack, what you're looking for in your next opportunity, as well as logistical things like when you would be able to start and any other special considerations. We spread this responsibility across the team so all engineers are trained to conduct phone interviews and are expected to eventually help with this step.

3. Video technical screen — 1 hour

The next step is a video call over Google Meet with an engineer on our team who will spend time diving into your technical experience and do a short coding exercise. The coding portion is done on an online tool called Coderpad, so there is no local setup or preparation required on your end. The goal here is to double check that you're comfortable coding, not to quiz you or trick you. You can pick whatever language you want to solve the problem, so no need to study up something in particular.

4. Onsite interview — about 3–4 hours

The onsite interview (which we've lovingly termed the "Power Day") is the best stage of all because you get to visit our office and meet more lovely people working throughout JOOR! The onsite visit involves a series of interviews, each with 1–2 people from various teams. After each interview you'll have an opportunity to ask questions (and to take a quick break!).

  • Problem solving — 1 hour: You will meet with an engineer and talk about nerd stuff! Your interviewer might ask you to describe the technical details of a challenging project you've been involved in along with theoretical problems to work through. This gives us an idea of what it would be like to work with you on a problem, and see how you approach problems and talk through your thought processes and questions. This might be an architectural design question that you sketch out on our whiteboard-covered walls, or a function that you pseudocode. We haven't gotten around to installing a linter and compiler in our walls, so stylistically and syntactically correct code is not a requirement. We also won't waste your time by asking you to implement binary search, so don't worry about digging up your college algorithms class notes.
  • Pair programming — 1 hour: You'll meet with another engineer and do some hands-on coding in a sort of informal "pairing" session. Again, the goal for is for us to experience what it's like to work with you and to let you show off your coding chops. We have a couple different coding challenges and we try to pick the one you'll be most comfortable in based on what we gathered about your experience from the previous interviews. We provide a laptop that's all set up and ready for you to code away!
  • Tech culture — 30–45 minutes: In this interview you will meet with people from other teams at JOOR, like Product and QA, who will be able to tell you about the product, the project management workflow, and how our cross-functional teams collaborate on a day-to-day basis. They might ask you to describe your team structure and workflows at your current company.
  • Management — 30 minutes: Finally, you'll meet with a manager or lead who will be able to answer whatever questions you might have about tech team priorities, higher-level company initiatives, or JOOR in general. This is your time to use to interview us, since we know the best candidates are picking the companies just as much as companies are picking candidates.

Oh geez, an interview that lasts 3–4 hours?!

We know it sounds like a lot — but we promise you'll get plenty of opportunities for breaks and water/coffee/snacks!

What are the technical interviews like?

None of the exercises are designed to trick you or stump you. We just want to make sure you're comfortable working through problems and being hands-on with the code if you're applying for a software engineer position! For all the technical interviews, we like to hear clear explanations of your approach and your thought processes while working through the problems. As mentioned above, the ability to rote memorize and regurgitate algorithms on-demand is not a requirement. We're totally fine with and encourage googling things during the coding exercises, like we all do while doing non-interview coding. What's more important for us to see is your ability to break down problems, deal with new incoming requirements, and collaborate with others.

What should I wear and bring to the onsite interview?

Wear what you're comfortable in; our office dress code is casual. You don't need to bring anything except yourself and your questions!

How long until I hear back after the interview?

After the onsite interviews have wrapped up, everyone involved in your interview process circles up at the end of the day to discuss everyone's feedback. Once the panel has come to a decision, we try our hardest to get back to you with feedback within 1 business day of your interview. Sometimes things pop up that alter this but we try to move at startup speed since we know the interview process is stressful enough already. We're also growing fast so will want to get you onboard as quickly as possible!

I got an offer! What now?! Why should I choose JOOR?

Hopefully you got all your questions answered during your onsite and you have NO DOUBT that you would love to work here! But just in case, here are a few bonus tidbits to help set JOOR apart from other companies you might have offers from.

Get to learn all the things!

When you start out, your manager will work with you to place you on a pod where you'll have the most room to grow and succeed, taking into account what you want to learn and practice. All of our pods within the engineering team are fullstack, so even if you're strictly backend you would get opportunities to be exposed to some React, or learn Django even if you're mainly frontend. Throw some GraphQL, iOS, Docker, Kubernetes, and Postgres in the mix and you'll find a world of learning opportunities all over the stack!

Experiment with a pod rotation

Generally we aim to have a balance where engineers stay on pods for a few months to get to know the same set of co-workers, but folks also move around to get a chance to work on different sides of the product and code base. We also have been experimenting with having new hires start on pods that are totally new to them. For instance, maybe you have never done DevOps before, so start there! On DevOps you can get a high-level perspective on the infrastructure of our platform and get familiar with the tools and dev environment you'll be working with as an engineer. Always wanted to try your hand at building mobile apps? Great, do a rotation on the iOS stack and work there for a bit to try it out. We hire people who can pick things up quickly and love to learn, plus we aim to make sure people don't get pigeonholed.

Culture of communication

In your first 1:1 meeting, your manager will pass on constructive feedback that came out of the interview process we laid out here to let you know what we are excited about and what we had concerns about. This feedback serves as a reference point for your growth (if we ultimately hired you, you can trust nothing will be too shocking!), and helps outline paths towards improving and best contributing your skills to the team. All this is part of our belief in a culture of transparent communication, which you'll find everywhere from our monthly all-hands meetings with our CEO Kristin to our daily open-attendance standups. It's kinda weird when you think about it: when you start at most companies they never tell you their concerns up front, but will still have them in the back of their minds and be evaluating for your improvement on those things. Let's change that and give everyone honest feedback from the start so they can hit the ground running.

That's just a few of many perks of working on the engineering team at JOOR, but if you want to learn even more, come interview with us — we would love to meet you!