Hacker News new | past | comments | ask | show | jobs | submit | muratk's comments login

engageSPARK | React JS UI | REMOTE ONLY (UTC-1 to +10) | 4dww full time | engagespark.com

We're a small team building a communication app for NGOs and universities. These organizations use us to reach out to or survey people in low- and middle-income countries. Because those people usually don't have internet access we use SMS, automated calls, WhatsApp, Airtime Topups.

And because our platform is DIY for those organizations we need YOU (a React dev) to keep improving it, making it easier to use. :)

Please only people who are pleasant to work with and who focus on shipping. Life's too short for ego——even if only on 4 days per week ;) —don't you think? Also, please see the salary range in the JD, saves time.

More info: https://www.engagespark.com/careers/react-javascript-fronten...


Four Day Work Week - 4DWW is amazing! Thank you so much for being the pioneers of the future <3


> choose and implement and couple enhancements to a toy app

I think this is a key piece why this kind of project is useful, because that's exactly what they'd do when they start in their coding role: jump into an unfamiliar code base and fix a bug, implement something tiny, make things better along the way.

When hiring for a React role, I went to find an open-source React app and simply asked the candidate to mod it a bit. We then discussed the why and how, but also how they liked the app and why.

We only gave this task to the final candidates, and the ones that had React experience were done in very little time, because typing wasn't the issue here, but reading unfamiliar code and understanding the mechanics of the app.

Writing a hello world app from scratch or coding fizz buzz doesn't tell me enough.



That is very useful. Thanks!


Would love to have a manager-mentor like that. :)


Looking at the responses here … it's not about

“1:1s are basics, if you don't do them you are a failed manager.”

Nor do I believe the truth is best described as:

“a 1:1 is a creepy corporate checkbox to be checked and best avoided”.

Isn't the answer always …

it depends?

On the person, on the company and team? On you, as a manager?

I have had colleagues who probably would have sent me a resignation letter within days after doing a 1:1 with canned questions like that.

I've also had colleagues who thought that a regular 1:1, going through the motions, was a sign that I cared and did something formal for them. (Despite normal chats and checkins.)

Even if you have a 1:1, it doesn't mean that you need to go through an ever same set of stale questions. But structure can help you both to make sure the basics of the work relationship are covered.

With that in mind, I see sets of questions such as this as a toolbox. Sometimes it's a good thing you can just look at the toolbox, try a few tools out, see how they fit and choose the right one for the job at hand (situation, person). I think it's great those exist.

If you're doing a 1:1 to check a box, then it doesn't matter. If you care and want to use a 1:1 as a tool, then it doesn't hurt to try out different approaches.


Curious, with GH notifs and Q&A in Slack, with demos at sprent end and probably an online scrum board…do you really still need a stand up to know what the others are up to? Or is it more to … talk?


The human element is really important, but it does help us coordinate. There's a lot we haven't completely captured in the scrum tool (the non-development efforts and recent events) that is useful to talk about.


Curious, how do you know that lack of trust is the reason? I mean, they wouldn't tell you, right? Maybe it's something simpler like, salaries, timezone, ...?


Curious—didn't that go fairly well? You noticed that the one thing that matters—outcomes—wasn't there, and you ended it.

If that person had been co-located, they'd have pretended to work and otherwise browsed facebook when no one is watching. You might have liked them, because such a nice guy to talk to and so on, and had given them a second chance and eventually decided that … outcomes are not there.

I did bad hires, remote and otherwise. I don't think there is a way to avoid that. Our insight from interviewing is just so limited. You give your best when screening, and then you gotta make a leap. And deal with crap when it happens, as it always will.


Did they prefer the huge company because of perks/salaries/tech, or actually because of being office-based? If remote, what was their #1 issue?


As someone who did 7 years remote-only, I have gathered some insights.

1: Synchronisation of effort for a team is absolutely crucial.

2: The top priority is for the teams to communicate amongst themselves fluently, and feel comfortable to communicate with practically anyone at the company at large.

3: If you don't live in a tech hub or a large city (which, to be honest, are mostly the same things), the life as a remote-only can get really lonely.

4: In a profession with a pretty big fraction of existentialists, learning to keep office hours and being able to turn off from work mode is essential for long-term stability.

5: You need a separate workspace for an office. I learned this the hard way. The ability to walk away from work after the day is important. And you really should have a separate computer for work, so you don't even accidentally look up the work stuff outside of office hours.

6: Everyone needs hobbies. If a person lives their life through their screen, it is very unlikely that they are suitable for long-term remote-only work. If you're a manager at an office, you usually want to know what makes your team members tick. If you're a non-junior at a remote-only company, it is absolutely essential that you learn what makes your team mates tick.

7: Teams need to meet up in person frequently. A day or two every 3-4 weeks is good. Several days at least twice a year is essential. Because there are no watercooler or office corridor moments, the company needs to provide an environment where something like this can take root spontaneously.

8: Meta-review for code review can be surprisingly helpful, even after the onboarding.

The truth is, not everyone is cut out for remote work. Because long-term mental health depends on being able to turn off and walk away, you are automatically selecting for wealthier individuals. I know this sounds really harsh, but it's true. A person who can afford the space for a dedicated office for their working hours is several times more likely to stay around and grow into a bigger role in the company. A person whose hobbies involve physical activity and getting out of their house is far more likely to be a good remote-only employee than someone who at the end of the day switches from emails and code to computer games and Netflix.

Loneliness and detachment are the biggest problems, at least in my experience.


Hm, some of those points I've experienced, too, or make sense to me.

3: You mean “professionally lonely” as not physically meeting enough other, say, devs? Why can't you get your tech interactions online and satisfy your need to meet people with non-tech people? That would remove the requirement for a tech hub.

8: That isn't specific to remote?

I very much agree that remote work isn't for everyone. But then, nothing is. Not even mango float, and that's a _fantastic_ dessert.

I don't agree with your reasoning, though. Many people are in horrible office-type jobs and their sanity would depend on them walking away. They don't, often for the same reason. Wealth helps because it gives freedom, but this isn't specific to remote.

Also, depending on what you define as remote work. In a not-so-rich country, remote work helps people in more remote and hence usually poorer regions get jobs. Yes, those aren't always great jobs—but they're in line with qualifications, and they do enable people to live better lives.


For number 3, I mean lonely in general. I've experienced it myself and witnessed a number of good people get burned.

As engineers, makers, tinkerers and creators, we tend to find our social networks among like-minded folk. When I was remote, I was living in a smaller town, where not much happened. There were a number of IT employers, but nothing particularly interesting. So I didn't have much "professionally aligned" groups to hang out with.

Working from home also allowed to skip trivial outdoorsy stuff, and the weather being inhospitable for >6 months a year didn't help. At the office we meet like-minded people all the time. Those at the company who lived in large cities (3 in the entire country that qualify) could meet in person outside of company activities, and they had groups of other makers to socialise with. Where you have a tech scene, you tend to have lots of nicely aligned activities. Living in a more distant location, you're alone.

As for number 8, you're of course right. It's not specific to remote, but I've found that at an office environment talking about some tricky problem that has surfaced during code review happens automatically, and discussing wider aspects of the code review in general tends to be part of workflow/tooling.

Yes, I do review code review at the office but it's not essential. (Important, sure.) But when your communication channels are not in-person, going over code review as matter of course becomes critical. Not being able to walk over and chat about engineering practices is something you will only miss once you've seen both sides for long enough.

The selection for wealth? Here I'm talking about jobs that require deep concentration. Tech is notorious for our constant search for the flow state. Interruptions and bad ergonomics can be devastating. But more than that, in order to remain mentally stable at a remote-only job for a long time, you need to be able to respect office hours and have a clear way to cut yourself off of the work environment.

If your work machine is the same as your personal use machine, those lines can get awfully hazy. Not good for mental wellbeing in the long run.


> If your work machine is the same as your personal use machine, those lines can get awfully hazy. Not good for mental wellbeing in the long run.

I find this to be true even with my phone! I have decided to get a cheap used Motorola smartphone to put slack + email + PagerDuty on and leave it in the desk unless I am oncall.


We had a colocated team in Cebu, Philippines. Turns out, not too many Go devs in Cebu, so went remote. Now UTC+1 to UTC+8. Bigger challenges:

- the utter unfairness that some people are really effective (possibly because experienced) remotely and can just do it while others are not. The latter we gradually “released” into remote work, with a lot of feedback.

- Biggest skill to be learnt, of course: communication. so much patching up is possible by just noticing someone is in a bad mood, or switching to a live discussion. Doesn't work with remote.

- hard to support juniors: they need to learn both work skills and communication—and often even don't realize it.

- learning to take responsibility. You're Internet at home doesn't work today? Too bad—I'm not fixing it for you. You're remote, you figure it out.

- currently: the realization that most things are _not_ urgent. Going more and more async.

edit: late-night formatting


Have contact info? Exploring opportunities in Cebu.


Well, we're a remote team. ;) Incidentally, I'm still in Cebu, but it wouldn't matter where you are.


I’m just a Cebuano finding excuses to visit home bai :). How’s the tech scene over there?


Not too sure. You'll likely find stuff for PHP, but a bunch of meetups have gone dormant AFAIK. High paying jobs here are scarce if they exist at all, probably same as when you left.


Your last two points contradict each other. If it's not urgent, they can be gone for a few hours or days. If it's a consistent problem, that's a different discussion.


Ah, my point with the internet example wasn't the missing internet itself.

In an office, someone will fix it if the internet is down. That's why you have an office: to outsource infra to people so you can focus on your own job: writing, coding, whatever it is.

If you're remote, your internet being down is _your_ problem and you're expected to figure it out. You have more responsibility—and that was an unexpected part of working remotely for some people.


Having done a lot of remote work myself, when the internet goes down I text the relevant people and then I'm done until it's back up. There is no responsibility there.

If the company REALLY wants that to be my responsibility, they can pay for me to run a 2nd ISP line, or any other myriad potential solutions.

Even in-office, most places don't run backup ISP connections, the internet goes it, it goes out.


Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: