If you watch the video above, you can catch a glimpse of what it's like working at JOOR.
Are you interested in joining their amazing team?
Then click here to see all available opportunities at JOOR and don't forget to press 'Follow' to receive custom job matches, event invitations and more!
Below is an article originally written by Katie McKew, a DevOps Engineer at PowerToFly Partner JOOR, and published on May 14, 2018. Go to JOOR's page on PowerToFly to see their open positions and learn more.
I'm Katie, a Software Engineer currently doing DevOps (and loving it!) at JOOR, the world's largest digital wholesale marketplace. As a developer and a member of the DevOps team, I've experienced first-hand the importance of knowledge sharing and collaboration between pods (backend, frontend, iOS, or DevOps) within the JOOR engineering team. In this post, I will discuss how we are are creating a healthy DevOps culture at JOOR, including the lessons and changes we have made along the way.
Pinning down the pain points
During one of our tech-team retrospectives, we uncovered that many developers were facing pervasive issues with their development environments, particularly related to the Docker containers we run locally for testing. Heads turned immediately to the DevOps engineers in the room: they architected the environment and, in many cases, devs were counting on their Docker expertise to get unblocked.
This sparked an important conversation — is the DevOps team really the only team responsible for fixing our dev environments? Our DevOps engineers made the architectural decisions (like using Docker) that went into creating the dev environment that developers use every day. To developers who aren't very familiar with Docker, errors can seem esoteric, and only solvable by those who set it up. From a practical perspective, though, there just aren't enough DevOps resources to help each individual developer on a daily basis.
By surfacing this knowledge silo, we were given the opportunity to brainstorm solutions! (Aren't retros great?!)
Communication & Documentation
As anyone who has used Stack Overflow knows, the ability to search for your error message proves extremely effective in resolving issues — as long as the resolutions are documented, too. Our first idea was to crowdsource a "troubleshooting" Confluence page that documents common errors and resolutions. This resource still proves useful today, especially for new devs trying to set up their environments.
For more day-to-day issues, we created a dedicated Slack channel for people to share errors and issues as they encounter them in their dev environment. In addition to providing searchability, Slack allows our team to quickly discover if: A) other people are experiencing the same problem, and it could be a broken master build; or B) the issue is isolated to the reporter's machine, but maybe someone else has seen this issue in the past and can point to a known solution.
Both Confluence and Slack also provide great opportunities for engineers to step up and contribute to the team outside of just coding: they can grow their expertise by researching an issue, and they can demonstrate leadership by sharing knowledge with others.
Breaking Down Knowledge Silos
In recent weeks, our tech team has made strides in our effort to level up the users of the dev environment on the tools and infrastructure used to set the environment up. Our DevOps engineers have held lunch-and-learns — open to the whole company, not just developers — on various concepts like Docker and Kubernetes. These sessions have been helpful not only for seeing how these tools are being used at JOOR, but also for filling in devs' knowledge gaps and providing an open environment to ask questions. Using feedback from developers, the DevOps pod also improved the automated tools that developers can use to diagnose common issues in the dev environment. Both developers and DevOps engineers contribute to the crowdsourced troubleshooting documentation on our shared knowledge-base, and continue to resolve issues in public Slack channels.
Here are some mutually beneficial strategies you can bring to your team to minimize throwing things over the wall, surface issues faster, and resolve blockers more effectively!
- Developers — Pair with a DevOps engineer on solving your problem instead of throwing it over the wall. DevOps can learn from your frustrations and you can document this resolution for other devs.
- Walk a mile in each other's shoes! At JOOR we have the awesome opportunity to do rotations on other teams, so developers can gain DevOps experience and vice versa.
- Read and contribute to each other's documentation. While the DevOps engineers may initially need to lay out the README for setting up the dev environment, they can't possibly know what issues users will encounter while following the instructions. Ask new team members to point out ways to improve the setup documentation after they use it.
- Hold lunch-and-learns and record them! These sessions can serve as valuable resources for new and existing employees.
- Create a tight feedback loop between developers and DevOps to ensure Ops are working on fixing the most pressing pain points. This can take place in a public Slack channel, a full team retro (including ops and devs), asking developers to write and prioritize dev env bug tickets on the ops board, or even sending out a survey to developers to gauge sentiment on their dev env experience.
By implementing these strategies with our engineering team, we have drastically improved communication between pods, which in turn, has improved collaboration and productivity. We've placed greater emphasis on documentation, which has long-term value for both existing engineers and new team members during onboarding. Most importantly, developers feel more informed and empowered to unblock themselves, without feeling like DevOps are the gatekeepers to the solutions. The team shares mutual ownership and responsibility over the dev environment, so issues get surfaced and resolved more efficiently. DevOps culture for the win!
Interested in learning more about working at JOOR? We're hiring! Check out our PowerToFly page.
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!