muratk

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

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.

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.

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?

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.

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.

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

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.

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?

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