Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Things we've learned about building products

newsletter.posthog.com

Post reply on HN
Print view View original

111–120 of 121 posts

Re: Things we've learned about building products

#111

Post by coolThingsFirst »

fdlaks wrote: post #52

Wow. 900 applications down to 10 "SuperDay" participants down to 4 hires. All to work at.... posthog. What a depressing statistic. This felt like a humble brag to help make their point about hiring good talent and how many people want to be a hogger (or whatever they call people that work there) but this just really highlights how brutal the job market is. Yes the market is also flooded with unqualified applicants an…

If i was that good why would i work for posthog instead of hft shop lol

Delusional web slop companies strike again

After some googling turns out it’s an analytics company but they behave ad they do fission.

Re: Things we've learned about building products

#112

Post by samstave »

samstave wrote: post #105
light_triad wrote: post #36

Earlier quoted context omitted.

Some teams think they can A/B test their way to a great product. It can become a socially acceptable mechanism to avoid having opinions and reduce friction. Steve Blank's quote about validating assumptions: "Lean was designed to inform the founders’ vision while they operated frugally at speed. It was not built as a focus group for consensus for those without deep convictions" Is the Lean Startup Dead? (2018) https:/…

[flagged]

(Sorry, forgot to mention: trillions in tons of plastic E_waste.exe __ obsolete phone cases ==

F IVE

Re: Things we've learned about building products

#113

Post by re-thc »

mannyv wrote: post #99
re-thc wrote: post #62

Earlier quoted context omitted.

> There's only one company that I know of that's been successful at that level without sales: Atlassian. It's not precisely so. They do and have had partners that did sales / consulting work.

Yeah, but I doubt third party partners can get you to an IPO-level scale. In my limited experience partners are usually small integrators that do maybe a small urban area. Did they get a big consulting partner/implementor or something?

> In my limited experience partners are usually small integrators that do maybe a small urban area. Did they get a big consulting partner/implementor or something?

Those do exists. Partner was a gray area for them. Some services like certain support was also outsourced to partners. In a way the partners grew with the company so at some point (when it peaked) there were a lot of "large" partners.

That's why I said it is confusing. There was a time when you contact them on the website looking for a solution someone would redirect you to a partner. It was essentially outsourced sales / solution team(s).

Re: Things we've learned about building products

#114

Post by lelanthran »

yCombLinks wrote: post #95
fdlaks wrote: post #58

Earlier quoted context omitted.

I personally think there are more efficient ways to get a high signal to noise ratio on if you are going to be a good hire or not without having the candidate invest almost 9 hours into an interview process, but that’s just me

A 9 hour investment to make a decision that will strongly affect 50% of your waking life for years or decades doesn't seem like a big ask.

> A 9 hour investment to make a decision that will strongly affect 50% of your waking life for years or decades doesn't seem like a big ask.

You only apply for one job a year? Twice a year?

There are very many good candidates a company will miss out on by asking for a full unpaid day from the candidates.

Re: Things we've learned about building products

#115

Post by tmarice »

Posthog's newsletter is one of the few I re-subscribed to after a general newsletter purge, top content.

Regarding the superday controversy: my best interviewing experience was a conversational technical interview followed by a paid-either-way-the-decision-went 2 week project. I did quite a bit of competitive programming so leetcode interviews are not a dealbreaker for me, but I feel there's just too much at stake for 1-2h coding exercise, and projects allow you to showcase all of your skills, not just speedcoding.

Re: Things we've learned about building products

#116

Post by hiAndrewQuinn »

fdlaks wrote: post #96
hiAndrewQuinn wrote: post #87

Earlier quoted context omitted.

>There must be a better way to do interviews. Interviews are a game of asymmetric information. The job seeker has much more knowledge of what they can and cannot effectively do than the job offerer. And the job offerer has much more knowledge of what is and is not required for true success than the job seeker. Given that, no, there really doesn't have to be a better way than just "interview a lot of people and take y…

Sure but the burden is on the company to understand what skills they need to hire for well enough to hire for the role, not on the candidate to just prepare for everything and roll the dice in a 9 hour interview This is where interviews can and should be done differently. In my career some questions I’ve been asked in interviews are: serialize and deserialize a binary tree, create an in memory cache from scratch, des…

>[T]he burden is on the company to understand what skills they need to hire for well enough to hire for the role

It's best not framed as a burden, but a tradeoff. Companies who understand better what skills they need to hire for quite reliably higher higher quality candidates, or are able to get away with paying them less, or both.

Take McDonald's as an extreme example. I am certain McDonald's has paid good money to figure out exactly what someone needs to be able to do in order to be an able burger flipper. That's a big part of why they're able to hire such folk quickly, at scale, at $10 an hour.

Most software companies face economic conditions which incentivize them to take the other end of the tradeoff. The work often is percieved to span such a vast possibility space it's nearly impossible to precisely specify the requirements a software engineering job has, in a way anything like the McDonald's position can be.

One of the mechanisms they choose to employ to minimize false positives despite this huge uncertainty in their own requirements is "Offer a lot of money and let the cream rise to the crop via pre-hiring competition". Hiring someone at $100/hr who is obviously and clearly very smart and hardworking is a much safer bet than hiring someone at $85/hr who you think could probably handle the job with a lot of effort, assuming nothing in their personal life derails them over the next 6 months or anything.

Final aside:

>This is surely how you find the best plumber because only the best will take the time to really understand what they are doing when they fix a sink right?

Nobody's ever looking for the best. They're looking for good enough, within tolerances.

I do have an uncle who did become a plumber after a long career as a chemical engineer. He is extremely sought after, and charges to match. He doesn't usually take "change my sink" jobs.

Re: Things we've learned about building products

#117

Post by sibeliuss »

niteshpant wrote: post #110
sibeliuss wrote: post #56

Earlier quoted context omitted.

Having attended a SuperDay, I can hands down state that their interview process is the best I've ever had (didn't get the job tho, which was probably for the best at this phase of life). Designed to perfectly lift signal and minimize noise, for what they're trying to achieve. Don't change a thing PostHog.

what was the process like? What made it so good? Asking because I'm trying to build out a process as well

This was one of the reasons why I applied. I wasn't entirely sure it was the right fit (my current job is flexible, which is good, vs a grind, and I'm happy there) but I wanted to study their ways a bit and see what I could bring back, because my company has made some remarkably terrible hires over the past few years.

In short, it's a very well designed "build an app" take home test. There isn't a solution so to speak, but its designed to test your product-engineer aptitude as well as your execution speed, as there are things to get done and requires some thoughtfulness. One can go in a lot of different directions with it. Code can look great, but did you build the right thing, something actually relevant? That's what's important.

Its the sort of test that would instantly filter out 99% of applicants, because of the product emphasis vs the code emphasis, and good product engineers are rare. One could be the best coder around but not have a clue what to build. They want people who know what to build.

I had a lot of fun working on it and loved the challenge, but ultimately didn't know what to build and was fishing a bit, being more of a platform engineer vs product engineer.

Re: Things we've learned about building products

#118

Post by specialist »

simonw wrote: post #32
kevmo314 wrote: post #4

This list mentions A/B testing a few times and it's worth noting that A/B testing is great but it's not free. I've seen a nontrivial number of smart engineers get bogged down in wanting to A/B test everything that they spend more time building and maintaining the experiment framework than actually shipping more product and then realizing the A/B testing was useless because they only had a few hundred data points. Dat…

I think A/B testing is one of the most expensive ways of getting feedback on a product feature. - You have to make good decisions about what you're going to test - You have to build the feature twice - You have to establish a statistically robust tracking mechanism. Using a vendor helps here, but you still need to correctly integrate with them. - You have to test both versions of the feature AND the tracking and test…

Terrific criticism. Rings true. I've never done it (directly). Only watched teams and teammates get sucked into that void. Sadly, they eschewed most of your list.

I do know that Google strategically used A/B testing to determine the precise shade of corn flower blue for some UI widgets.

> Run usability tests.

Maybe the point of A/B testing is to avoid all that battle tested and validated '90s era process and methodological nonsense.

(As though a design could stumble thru a solution space to some local maximum. Like an optimization problem.)

I also kept thinking of that SQA cliché "You can't test your way to quality."

Post reply on HN