Comments URL: https://news.ycombinator.com/item?id=42335518

Points: 2

# Comments: 1

* Don't add process just for the sake of it. Only add it if seriously needed.

* Require ownership all the way to prod and beyond, no matter the role. (Turns out people tend to really like that.)

* Stop making reactive decisions. If something bad happened on a total, extremely unlikely lark, don't act like it's going to happen again next week.

* Resist the urge to build walls between people/teams/departments. Instead, build a culture of collaboration (Hard and squishy and difficult to scale? Yup. Worth it? Absolutely.)

* Never forget your team is full of actual humans.

Comments URL: https://news.ycombinator.com/item?id=42232749

Points: 3

# Comments: 0

"Are you testing the candidate on what the job will actually require, and ONLY that?"

With an onsite whiteboarding challenge, you're most likely testing if they're really good at thinking and talking in front of a crowd when extremely nervous, not writing code.

Same with a live coding challenge over zoom (CoderPad style) - this tends to be a test of nerves more than coding ability. But, if you're planning on a lot of pair programming, and want them to be able to dive into that on day one, maybe it's the right way to interview.

I find take-homes often the most accurate way to interview, as it most closely reflects the reality of most coding jobs. You're on your own, you don't have to deal with the extremely odd (and for some of us terrifying) feeling of someone watching you type. Hopefully, the take home questions are carefully designed to reflect what the job requirements will be. As almost every other comment has pointed out, debugging an ancient code base without documentation may be a perfect question, or it may be completely irrelevant and unnecessarily eliminate candidates.

But please, make the interview match the requirements you're actually hiring for, otherwise, everyone's time is being wasted.

If I had a massive new app to build, it would indeed feel overwhelming if I felt like I just had to sit down and build it. I think we get extra stuck on that with writing, as it often feels like we just need to go from an empty page to a well-reasoned and edited blog post, with a lot of ambiguous struggle in between.

With programming, I start breaking it down into pieces of functionality, and smaller ones, until I have a list of concrete things I can actually get my head around and write the code for. I keep on doing those small things, build the structure around them, and eventually I have my app.

I do the same with writing now. Not an outline really, but a list of concepts I want to get across, then smaller ideas. I write out a few of those, often a paragraph at a time. The structure starts to reveal itself, and soon enough I have a new blog post.

I think the key here is arriving at something small enough that it doesn't feel overwhelming. New app or blog post feels like way too much in the moment, and my body and mind to everything possible to avoid it (procrastination). Writing out a paragraph, coding a function - very doable.

Comments URL: https://news.ycombinator.com/item?id=42084098

Points: 3

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=41954375

Points: 212

# Comments: 58

Comments URL: https://news.ycombinator.com/item?id=41823634

Points: 4

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=41680274

Points: 2

# Comments: 0