lukey_q

Exactly, his weirdo vibe works because he pairs it with an incredible love for music and respect for the artists he speaks to. I think Drake said it best in the hourlong interview they have together, along the lines of "I don't do interviews because most people want to catch me slipping up and find some dramatic quote to drag me with, but with Nardwuar it's 100% about the music, that's why we're here"

Best example of this is probably the first Pharrell interview. This was before Nardwuar was famous at all, outside of Canada anyway, so Pharrell wouldn't have heard of him, and Pharrell spends the first part of the interview obviously a little weirded out at the goofy-looking guy in front of him and probably wondering why his manager booked this for him in the first place. About five minutes later Pharrell says "This is one of the most impressive interviews I've ever been a part of" and as mentioned in the OP article immediately calls Jay-Z and says hey you gotta talk to this Nardwuar guy.

A red message saying "Please enter a valid e-mail address" when I've only typed the first three letters

I agree with all of this advice, and would just add that if you find yourself turning in PRs that then need some changes before they can be merged, a strategy that worked for me early in my career was reviewing my own code as if I was reviewing another person's pull request. If you have turned in a few PRs that needed work then you already have a few examples of the kind of thing that your colleagues are looking for, and you can look at your own code with those things in mind. If you can, I would try to put a little time between writing the code and reviewing it so your mind can reset a bit. For me that meant wrapping up the code in the evening and then reviewing it first thing in the morning.

I don't think there are stupid questions or even poorly worded questions. Even "bad" questions like "It's not working, help!" are a learning and a teaching opportunity, which I think is mostly up to how the more senior developer responds and works with the more junior one. It's true that "it's not working, help" is not all that actionable by itself, but I assume we all had moments like that when we were learning to write code. I certainly did. (and still do sometimes lol).

I think the tweet thread's thesis is "allow messing up," which I'd couple with the senior developer's responsibility to be nice and friendly and supportive. Anyone's first dev job is going to be a formative experience and if they ask "stupid" questions and are met with kindness it's going to echo through their entire career, the same way being met with rudeness would also have a lasting effect. I don't really have any hard or fast rules about how juniors should ask questions, I don't think they're really necessary as long as you make them feel supported and comfortable in a general sense.

I created a similar task at my company as the parent commenter, building a small frontend to an existing API that can be completed in a couple of hours. There's no time limit for turning it in (we suggest two weeks but don't enforce it) and we specifically tell people that a good, concise solution to the problem at hand is perfectly fine, and even might be better than a sloppier solution that tries to add bells and whistles.

When I set it up the goal was to avoid a lot of the issues I've personally had or heard about with coding challenges: they take way too long, they're too abstract, or you feel like the company might just be using you to get a couple of days of free work on their actual codebase. For this reason I feel fine about not paying people, as it's just a small part of the application process and not free work for us.

I think it's worked pretty well so far. It happens after the initial phone screen and before the first technical interview. We send people the challenge, they return it whenever they want, and if we like it we set up a technical interview. Since the challenge uses our tech stack and is similar to the work we actually do, a large part of the first technical interview is discussing their solution. Why they chose certain patterns, why they added a certain library, how they'd consider testing it, why a certain function might be slow with 10k entities, and so on.

Totally unacceptable ask in my opinion, for reasons many people have touched on. I would also add that even from the company's point of view, it's a bad deal to ask you to work. The peace of mind you get from taking an unplugged vacation, and also from knowing that your company wants you to fully enjoy that vacation, is going to make you happier and more productive when you return to work. It's going to make you trust your company and think that they have your back as a human being. In the end this is going to be worth infinitely more than the two or three emails you would be expected to answer that week.

You've got it exactly right. It's something you need someone else's help with, and ideally you can just go ask them for help.

I totally agree with the idea that teams should remove blockers as they come up. If someone on my team runs into a blocker 10 minutes after the standup, I hope for everyone's sake that they don't wait until tomorrow's standup to say something, if only because being blocked for a whole day is not really what you'd call "morale boosting".

I'm not a huge fan of in-person standups, but if you're going to do them really make sure they're useful and efficient. I worked at a small startup once where the entire company (~12 people) did a daily standup, which meant listening to what the salespeople were doing every day, and then telling them which bugs I was fixing. Overall pretty useless.

I'm a team lead and every single person on my team has told me they feel much more productive and able to focus since lockdown and 100% remote work started. One of the people on my team would normally work in our office's "chill room" because he found it slightly easier to focus in there compared to his actual desk.

In my opinion an open plan office for developers (or anyone, really) would ideally be an option, but you would have to opt-in. There are situations where being able to shout over your laptop at your coworkers is going to be beneficial, but there are also situations where people should be able to zone out and concentrate (zone in?) for several hours at a time without having to blast white noise in their headphones.

I'm curious what you think makes this particular account a bot? To me it looks like someone who might not be particularly tech savvy who signed up for Twitter to find out about and discuss the ongoing global pandemic, which I guess you could call a "semi-political topic". To me it looks like Twitter's attempts to reach out to people who aren't already constantly online might occasionally work, which could result in a screen name or behavior that seems "strange" to people who are already very familiar with the platform

It is kind of funny to compare that early example of a notification, which was likely novel and rare enough to actually be exciting, to today's onslaught of notifications where at least for me it's extremely unlikely that any single notification is anything actually exciting or meaningful