gregrata

Odd - when I'm at a cafe, I'm almost always asked if "whole milk" is ok. It work, we have fat free, 2%, and creamer...

"hired an architect 18 months ago who used AI to architect everything"

Huh? 18 months ago? I've been using it that long - it wasn't able to do that back then....

Awesome post - really insightful!

Wow. Yeah. That's unreadable - my frustration and annoyance levels got high fast, had to close the page before I went for the power button on my machine :)

(and yeah, I don't love the term "Vibe" - but it's kinda established at this point, so I'm just going with it...)

Been working to write books for a while now using LLMs. Wasn't very good until recently- the newer models with the larger context windows are pretty good at it, and Cline is amazing (and not just for coding!)

As many have said, don't treat them as side projects. They were apps or products you were working on - if they were at all "real" (e.g., had users or customers) than it was a startup you were trying to get off the ground (a lot of startups are bootstrapped that way).

I've done a lot of this in the past - I built a platform and apps for consumer-focused location aware in the early 2000's, and another app that ended up with around 12 million users.

When I interviewed at Microsoft Research, we barely talked about my "day job" (fairly straightforward C#/.NET enterprise stuff). They ended up focusing on the side stuff - because it was just me doing the design/architecture/coding/company, it was innovative, it was interesting - and I was super passionate about it.

Uhhhh.... holy crap, sorry... but what is the author smoking? I started out with PC's in the early 80's. They were HARD to use (granted, as a pre-teen, I fell in love right away - but I was already a nerd). They were not intuitive. They didn't do very much. They generally sucked for most people, unless they were using a word processor (and even those were tough for some people)

Today, everyone can use one. They are very powerful, do a lot of things, and are comparatively simple to use - I mean, my MOM can use the damn things, which she never could have done in the 80's and 90's. And with very little support for me!

I'm sorry - but - HUH?

re-enter the stream of commerce for potential future criminal use.

Because of course if CASH re-enters the steam of commerce is somehow different?

Great over all story. Not sure what the McDonalds part has to do with it - a huge number of kids start there. I did - and in the next 40 years I've been Chief Architect of a startup, found my own startup (with a install base over 12 million), and am currently a Principal Architect at Microsoft (and was a lead in Microsoft Research a few years ago)

All good - and I look back at my McDonald days (somewhat) fondly, and it was good experience at doing fairly unpleasant work - but my nights hack and phone freaking and coding had 100x more to do with my success then that first job :)

shrug before I used my phone for music, I used my iPod. Before that, my Walkman.

Personal music at the gym is not new or anything specific to phones

On another side of this - I've seen places where employees were essentially locked in - unable to leave, because they couldn't sell any stock, and exercising cost too much, or, more likely, would be a taxable event (and again, they couldn't cover taxes by selling so it's a huge cash hit to buy the paper)

I get at one level a company might like this - it's a "good" way to keep people from leaving. In reality, this means you have people that really want to leave and can't - which does not make for a happy, good employee.

Let them sell at least a portion of the stock back to the company. Or sell some during a funding round, at least enough to cover their taxes so they can take their stock and go.

I wrote a book on this last year, out of my frustration with dev interviews

https://www.amazon.com/Whiteboard-better-hire-best-developer...

I've interviewed and hired a lot of people over the years, and have been interviewed a fair amount. The way a lot of companies do it didn't make sense to me, so 5+ years ago I decided to figure out a better way to do it.

My basic premise in the book is that in an interview when asking someone to show skill, it should be as close as possible to what the job is. Most interviews are just not anything like a whiteboard interview or algorithm question. I get that can show how someone thinks, how they ask questions, etc. - but to be honest I rather have them actually DO something as they would do if I hire them.

I've had a lot of luck with this way of interviewing. The reality is it can still be a crapshoot - you really don't know what someone is going to be like until you work with them for a while - but this at least gets closer to making a more informed decision ('cause you basically work with someone, in a small way!)

This is what I created over the years, and what I found gave the company the best results (great, happy teams that worked together very well, creating great software)

Is this something that you'd do? Have you tried something like this for hiring? If so, what was your results?

I wrote a book on this:

https://www.amazon.com/dp/B07FJ6N8P1 (the book will be free tomorrow - would love for you to give me some feedback...)

Lighter-weight then this paper - just my experience in using different kinds of tech interviews, and what I found that worked the best for my team and company.

Some key points:

- Interviews should be as close to what the candidate will do in the job - if they'll be writing a lot of code, that's just basic algorithms - on a whiteboard - then whiteboard interviews are perfect. If they will be doing a full project and interact with others as part of that project, then do something more like that (For me, that's a take-home - with an emphasis on the interaction part, and how they go about creating software... not coding). Treat it like a project, not an interview quiz question.

- If doing the takehome, respect peoples time - it needs to enough be close to something they'd do in the job, but something that can be done in a handful of hours (and NEVER treat it like getting free work. I personally would love to be able to do a paid take-home, but haven't had the budget for it) The total expected time of the take-home + onsite should be able what they do for just a full on-site

- Understand that not everyone will have time to do this. Have a backup (my backup is "Project Day", which is on-site, but still about creating software)

- Try to do the same one for all candidates. At my last company, 80+ people ran though the same take-home. The team really started to get a sense of a good result and bad result.. and not JUST on code. What questions did they ask? How did they go about driving the project? What tools did they use?

- I did catch a few people cheating (after 80+, the code was out there, so not hard to cheat). LOOKING at someone else's project for this was ok (if you read the book, you'll see why). Outright copying was not. Part of the process is a friendly code review after the project is done - if the candidate wrote the code, they'll be able to talk to it, and have ideas of how to improve it. If they can't do that and don't see to know the code, they probably didn't write it... which was painfully obvious for those that tried to cheat.

Do what works best for your team and company. This worked best for me; I have yet to see whiteboard interviews be a strong indicator of someone being a great fit for a team, but I was able to build a great, happy, very productive team using this method.

Cliff notes: https://en.wikipedia.org/wiki/MSX

The key words you probably need to look at are "multi-petabyte". Not saying they shouldn't be doing something but it all costs - and at multi-petabytes, it cooooosts

1 Petabyte (and they have multiple) S3 - $30,000 a month, $360,000 a year

S3 - reduced redundancy - $24,000 a month, $288,000 a year

S3 - infrequent access - $13,100 a month, $157,000 a year

Glacier - $7340 a month - $88,000 a year

WORKING with someone (for a long time) 100% tells you what it's like working with someone

Not sure how that's not clear...

Correct. Best way to know what someone is going to be like to work with, and how good they are, is to work with them. Interview is that helpful

And yeah, I have strong opinions on this - I've been on both sides of the table for a long time, and don't think the average interview is a good indicator of how they'll do in the job.

I wrote a book about this :) https://www.amazon.com/dp/B07FJ6N8P1

because someone knows someone and has worked with them for a long time only

And this is the #1 thing that gets a near auto-hire from me. I'm not saying don't interview them, but most interviews don't really tell you what it's going to be like working with someone. On the other hand, WORKING with someone (for a long time) 100% tells you what it's like working with someone.

If someone has worked a long time with someone else and is willing and wanting to do so again, then hire them.

My experience is, most interviews suck trying to figure out how someone is going to do on the job. Working with someone a long time and wanting to work with them should weight heavier than anything else

What in the world are you basin that on?

As stated:

If it takes a lot of money to create what your customers want

I assume that covers what you are talking about...

So it would be nice if they contrasted this again other generations - "About 66% of people between the ages of 21 and 32 have absolutely nothing saved for retirement". So? My impression is other generations at this age also hadn't exactly been saving a lot. Is this just saying the millennial general is just the same as others? Or way out wack?

So I've been frustrated by this type of interview for years (on both sides, but the last 10 years on the hiring side). I don't think it's great finding people that are good at writing software (as it's a LOT more than a single algorithm and more than just coding).

I wrote a book it - along with what I've been using the last few years, that actually seems to work - or work at least a bit better. In the end, I don't think you really know unless you work with someone.

https://www.amazon.com/dp/B07FJ6N8P1

It's my first attempt at a book (small as it may be!) - I'd really appreciate some feedback (and it's free right now)

-Greg

(and yeah, I get this already happens if, for example, I visit the state. Just seems to be different in this case)

Isn't this at some level taxation without representation? If I don't like how some other state is taxing, I can't alter that behaviour by voting. At least in my current state I might have a chance to do so.

wow, that is nicely done!

I would personally like to have groups of things that can be unlocked - that I can define

- Nothing - essential what's on lock (weather, maybe news headlines) - Face - basic stuff - games, calculator, News apps - Fingerprint - mail, calendar, text message, browser - Pass code - banking, settings

A one all seems backward - there are something things I don't want to protect at all (don't care if someone can access) on one extreme, and things that MUST be protected as much as possible on the other extreme.

I get leaking between apps is an issue, and there are other problems around this - but this approach seems more reasonable

And yeah, for some users (my parents) they just want something simple and don't want to deal with this. So face or fingerprint is a lot better than no code, so this is still an improvement

Very cool! Can't remember the last time it's just DOWN (which is saying a lot for how good FB is able to keep things up!)