This part was written by Amitai, Gizra’s CTO:
I found myself in interviews going over and over the same topics: who Gizra is, what we expect from candidates, and what they should expect from us.
So this is an attempt to provide this info, so you - the candidate - can read it without the stress of the interview.
Do We Fit Each Other?
Here’s what we expect to get from you:
Some intro to who you are. Being able to see how you present yourself, gives us some hint to your written communication skills. Don’t make it too long, or too short. Try to make it interesting and reflect best on your skills, and what you are looking for.
To save each other’s time, I’ll mention right off the bat that our salaries range between around $4,000 to $6,000 per month (for full time), depending on experience and role. It’s probably not as high as one might get if one worked in a well-funded startup, though they are competitive, and - depending on the startup - more stable. An important factor is that by that salary we don’t have a sense of ownership on your time. We don’t assume you should work weekends or late nights. We don’t like wasting your time (and ours) with boring meetings. Instead, we are really focused on being productive, making a profit, and enjoying our work. Not necessarily in this order.
This position would be part-time, 80 hours per month. The hours are distributed over an entire work week instead of specific days in a week. It’s likely going to end up as a full-time position, depending on the workload.
Your contract will be for “Independent Contractor” as opposed to “Employee.” Having to deal with each country’s bureaucracy is something we gladly decided to avoid. There’s too much overhead for a company of our size, where employees are scattered all over the world. That means, the hassle of taxes, retirement and medical plans are to be your responsibility.
This also means we don’t mention sick days or holidays in the contract. So when telling us your hourly rate, you should take into account those days. We consider a month as 160 hours, so you can calculate your hourly rate accordingly.
Here’s the default contract we’ll use to draft your contract, so you can already go over it, and see if it’s something to your liking. Have you got a point in the contract that seems problematic for you for whatever reason? Speak up, maybe we can find a solution for it. Past experiences showed that many times we were able to find a common ground.
Common Difficulties for Newcomers
Over the years, we’ve noticed that new hires usually face the same difficulties. I’ll name them in order.
The way we work in Gizra isn’t unique, but also isn’t that common - every issue on GitHub gets a timebox (TB), normally between an hour to six. It is the Project Manager’s responsibility to assign a TB to an issue. The timebox is not a contractual “Do it in 4 hours or else…", instead it’s “We think it’s 4 hours, so now it should be clear to all stakeholders how much effort should be invested”. But what if the issue turns out to be more complicated; or the developer didn’t understand it properly; or you, the PM, made a mistake? We all know that these things happen with some frequency.
With the timebox in place, developers have a very clear understanding on when to escalate to the PM.
The second thing is the case of which hours you need to register. Sometimes the wheels are turning in the background and staring into thin air is, most likely, part of work. We’re humans, and not machines. We’re not expecting anyone to keep typing for eight hours straight, and be at their maximum capacity of productivity.
The rule of thumb is quite simple. For every hour that you want to be paid, Gizra also wants to charge the client. By having the timebox in place, we make sure everybody is compensated for their efforts, while the client isn’t surprised at the end of the month when they are billed.
Keeping Track of Time
That is, the actual procedure of looking at the clock when you start a task, and looking again when you finish it. When jumping between issues, or when concentrating on other stuff it’s easy to forget it. I’m personally using this Time tracker, but there is also this one. It’s something that needs getting used to. Just be sure to track the time you work.
Working remotely is challenging. As we’re looking for an experienced Project Manager, it’s likely not your first time doing it. Nowadays, after the Covid-19 outbreak there are tons of resources out there. I believe it mostly boils down to maintaining a healthy balance between work and non-work, and being able to stay focused.
Not only are we not on the same continents, but also our working days slightly differ. In Israel, the working days are Sunday to Thursday, so the ones working from Israel are usually following those days. Others work Monday to Friday.
As we are a distributed team, we do see the importance of having some overlap, so developers have a chance to video call with the PMs, and each other if there’s a need. That is, we don’t have “stand up meetings,” but that five minutes of synchronous conversation can save up many hours.
For this position, we are looking for a Project Manager that can work within US (EST) time zone (at normal business hours 9:00 - 18:00). We don’t want to exclude anyone by location, but if you are from a “remote” area , do reflect if that’s in line with your way of living.
Working with Drupal
Even though you’re applying for the Project Manager role, some technical background of Drupal is expected. You’ll need to have a high-level understanding of what needs to be implemented and be able to clarify issues and questions with and for developers.
We aim to be professional and nice. Professional for all the right reasons, and nice for the same ones. When I’m leaving a (virtual) room after a meeting, I’d like them to remember that Gizra has those down to earth folks that immediately understood the deal, and gave good, although somewhat radical, advice.
Being nice for us is part of being professional. I heard about managers yelling at employees. Or just some good old passive aggressive stuff. We don’t do this - or at least try very hard not to. Be nice; expect and accept mistakes; tell a person in a direct manner if they did something wrong, but also tell them if they did something right.
I think we’re a pleasant, not too stressful place to work. There are always deadlines, sure, but there’s also the time to spend with your friends and family.
I hope up until now you’ve got the sense that we’re not beating around the bush. We’re pragmatic, and quite dislike an over-engineered solution. “Let’s solve it in the simplest way”, has gotten us to work with some of the largest organizations in the world - so we must be doing something right. But we also understand that “there must be a better way” - always. Innovating ways we work, and trying to improve processes (sometimes by completely removing them), is always in the back of our heads.
Oh, and we’ll never say silly stuff like “Gizra Family”. You don’t pay salaries to family, you don’t fire them, and you don’t give them code review. Jeez, when did that become the norm?!
So you’ve decided it might be right for you. That’s exciting! Send us that first email with the info we’ve asked, and if it seems right for us, we’ll schedule a video call.
Usually we have two interviews, so we’d have two people on our team not only evaluate your skills, but also answer your questions.
We’re looking to hear about your mindset, your experience and how project management can optimize results. Or the things you are interested in.
We’d like to give you a short assignment to help us see how you approach managing projects and prepare issues for developers. We estimate it should take no more than an hour.
Describe Your Project Management Philosophy
We’ve given quite a bit of insight into how we work and are curious to learn about your project management style and philosophy. What is important to you, how do you work? A paragraph or two will suffice, we’re not asking for an essay.
Write Issues to Hand Over to a Developer
Part of the job is to prepare and write tickets that developers can pick up and work on. It is not uncommon to receive designs and translate them into tickets. Assume that you received this design from the designer and now need to create tickets, so development can start. It’s a design for a Drupal site aiming to collect data out of surveys sent to employers and employees. When writing the tickets, try to recognize the different entities on the page, along with different design elements. So one ticket could be, for example, describing some data structure(s); The other might be more of design and interaction.
Give yourself a timebox of 20min and track the time you really spent on it.