Candidates Information for IHP (Haskell) Developers

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.

Links to code examples. We honestly have no way to know how good you are without getting some outlook on what you’ve written until now. Since we always look for experienced developers, it’s likely you’d have something out in the wild. If you don’t have anything public, try to reach out to existing clients/ employers and ask them to share with us some pieces of code.

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, 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.

It’s not uncommon for us to have people for over four years. We’ve even had a case or two of developers that found another gig, came back, found another gig, and came back again. Sometimes the relationships work really well. But of course, some people weren’t a good match. Not everybody loves us, not everybody believes in our mindset or in the way we work. Honestly, this makes finding a good match even more special.

As this is our first project in IHP (the majority of our projects are in Drupal), and we haven’t secured other IHP projects, this contract will be coupled with a specific project. Our goal, however, would be to have enough IHP work coming in, which would allow us to commit for longer periods.

Contract

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.

Our estimated timeline for the project is four to five months. Although we cannot guarantee it, we aim to secure funding to prolong its operation.

Common Difficulties for Newcomers

Over the years, we’ve noticed that new hires usually face the same difficulties. I’ll name them in order.

Timebox

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. The challenge people face revolves around two main things:

Wanting to satisfy the timebox. If you see an issue is timeboxed at 4 hours, you’d like to finish it by then. Everytime you’d need to ask for a bump (i.e. escalating it to the PM, so they authorize more time), you’d feel like you weren’t good enough.

That assumption is wrong. 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 you didn’t understand it properly; or the PM made a mistake. We all know that these things happen with some frequency.

With the timebox in place you now have a very clear understanding on when you should escalate. If after two hours you have made no progress, it’s clear that now is the time to reach out. It’s not nagging. It’s not being a bad employee. It’s simply following procedure.

The second thing is the case of which hours you need to register. Is staring at code for twenty minutes and twenty minutes more of staring at thin air also part of it? Well, the answer is most probably yes. 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. It something that needs getting used to. There’s no need to go too deep and register every little minute, but if you’d work on an issue for +15min, we’d want you to register it.

Distributed Team

Working remotely is challenging. As we’re looking for experienced developers, 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 differ slightly. In Israel, the working days are Sunday to Thursday, so the ones working from Israel (as myself) are usually following those days. Others work Monday to Friday.

In terms of hours, we don’t have a strict policy on start or finish time, certainly because of having different time zones. However, 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.

At around 12:00 UTC we have a couple of hours of overlap. This means that usually our employees are from the Middle East, Europe and the East coast of the Americas. The West coast and Asia pacific time zone difference is usually so big, it’s too much of a hurdle. I personally wouldn’t have wanted to work late at night, or to ask for someone to do it. So if you are from those “remote” areas, do reflect if that’s in line with your way of living.

Working with IHP

While we’ve got several projects with Elm in production for over six years, we don’t have the same level of confidence when it comes to Haskell and IHP. The person we’re looking for should be proficient in IHP, and one that can solve most problems by themselves. Simply because we don’t have that knowledge internally. Essentially, we need someone who knows more about Haskell than Amitai does and could put this knowledge to use.

We are looking for a skilled developer who values practicality over complex techniques. While familiarity with cutting-edge methods is beneficial, we prioritize someone who opts for the easiest, non-optimized solution first.

Working on both the backend and frontend with Tailwind is all part of everyday’s work. It’s ok if you are not a CSS wizard. We’re using Tailwind along with not too complex layouts. Enough that you feel comfortable with flex and grid and can easily position elements and make them responsive. Don’t worry, we provide the design.

If you have a background in Elm, please let us know and share some code. Although we don’t require a full-time Elm developer, it could be advantageous.

Our Culture

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 reviews. Jeez, when did that become the norm?!

Interview Process

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 hardly ask about technical stuff. It would be quite boring to hear how you’ve configured Views, or set up your localhost. Instead, we’re looking to hear about your mindset, about how development should look. Or how project management can optimize results. Or the things you are interested in. You know - interesting stuff.

Home Assignment

We’d like to give you a short assignment to help us see how you tackle problems. We estimate it should take no more than three to five hours. Please send your work to [email protected]

Backend task

Create a new GitHub repository.
Use this repo as a base repo to work on. Don’t fork it, just create a completely new repo.
Create a Wysiwyg field using TinyMCE or any other Wysiwyg you prefer. It should replace the existing textareaField #body with textareaWysiwygField #body.
Add a sanitizeHtml function, so if a user enters dangerous tags on the #body of ParagraphCta, it should be removed on ShowView.
Add a test to confirm sanitizeHtml works well when creating a new ParagraphCta.
Create a Pull request on your GitHub repository, with some explanation and images/gif showing the new functionality. Make sure we can install your repo locally and see your work in action.

Frontend task

Continue on the same repo as the Backend task, and head over to this shared Figma file.
Convert the design to hsx using Tailwind, and have it shown under a new static /StyleGuide page. Make sure you are getting the paddings, margins, font size and colors correct. Bonus points if you will use the same idea of build and wrapping elements as we’re doing here.
Add another section on the /StyleGuide page showing a grid of 10 Person cards, which is responsive.
Create a new Pull request on your GitHub repository. That is, you should have two different PRs: one for the backend task, and another for the frontend task. Once again, add some explanation and images/gif showing the new functionality. Make sure we can install your repo locally and see your work in action.