fatnoah

I can't wait for the shift back to in-person interviews to combat the use of AI assistants in virtual interviews. ;)

It is a very tenacious plant. I had exactly one stalk grow to 3 feet in a mulched area of my yard. I didn't think too much about it because I didn't know what it was and hadn't heard of it. While testing a trial of a plant identification application, I successfully identified it.

As someone loathe to use chemicals, I thought perhaps that the tenacity of the plant was overhyped, so I simply pulled the stalk out of the ground. Over the next several months, I'd notice 3-4 new stalks popping up each week over a roughly 15 foot radius area. That continued through the next spring when I finally decided enough was enough and got the glysophate.

From June through winter (I'm in the northeast US), I'd let a plant grow for a week or two and then spray it with the glysophate and leave the plant in place. I did this for the entirety of the following year as well. Now, in year 3, I finally have no more shoots popping up, and can't begin to imagine what managing a true infestation looks like.

Somewhat ironically, I'm pretty sure I failed a system design interview at a big tech last year for not drastically over building to solve a problem that probably had far less data (movie showtimes, and IIRC there are less than 50k screens in the US).

That's a great breakdown. To my ears, one of the big differences in Canadian vs. Metropolitan French is that the former is very much in the throat, while the latter is in the nose.

Standing in line for currency exchange in Montreal behind a French couple almost broke my brain as I tried to listen into their conversation with the worker.

As the resident of a northeastern US state, relatives on one side of my family grew up speaking French, so naturally I took French in high school. I was embarrassed when I still couldn't speak French with the family and had to resort to English when visiting Montreal.

I was, however, vindicated later in life when I visited France and was able to get by without English.

> "smart and gets things done"

This is what I optimize for as well, and it's amazing how much pushback I get from others on this. I've been hiring software engineers and other roles for over 10 years, and not once did I ever lament that someone "just didn't have enough Python experience."

That doesn't mean that there aren't cases where zero domain knowledge would be a huge detriment, or that having such knowledge wouldn't be a positive. However, there is a tendency to overindex on "requirements" that are really "nice to haves"

I've probably said this in other posts, but the best "don't do drugs" education my child got was living in a city. It's one thing to hear about drugs, it's another to watch your dad call 911 for a man collapsed with a needle still in his arm in a subway headhouse doorway.

> Why wouldn't the "script" be all of the necedssary commands to create the entire database?

That pre-dated me, so I have no idea. It's also why I simply jettisoned the schema migration script altogether, since the dacpac covered both migrations and creating new databases.

Some other "fun" things in the database were "expansion columns" just in case new columns were needed. Many tables had "int_1", "int_2", "int_3" etc that were not used, but ready to be used should the need arise.

>I wish there would be some tool w/ DDL that you can use to define schemas, functions and views which would automatically sync changes to staging environment and then properly these changes on production.

A long time ago, I joined a company where the "DB Migration Script" was an ever-growing set of migrations that took close to an hour to run. There were the same issues of lack of context, history, etc.

Since we were a Microsoft shop, I took the following approach to use Visual Studio DB projects and the SQL Server sqlpackage tool. Every table, stored procedure, schema, user, index, etc. was represented by a single file in the project, so it would have full git history and DB changes and the code that relied on them would be in the same commmit. (Data migrations still had to be stored separately in up/down migration files)

The "build" was to create the SQLPackage dacpac file from the DB project, and deploy was to apply the dacpac to the target database and then run data migrations (which were rare). Since the dacpac represented the desired end state of the database, it didn't require a DB to be in a specific state first, and it allowed the same deploy to run as part of CI, manual testing, staging deploy, and production deploys. It also generally took less than 5 seconds.

There's a meta-question which is "if you did should you have been doing what you were doing?"

Also a great question. As a manager, my first question would be to ask why a library wasn't used for algorithm X.

In grad school, I wrote a complete implementation of Rijndael encryption for a crypto class, but I would never expect (or want) anyone to try to build that themselves for production software.

Agree. It's frustrating that my demonstrated experience scaling a system 100x while achieving > 99.995% uptime is somehow less meaningful than my ability to code random problems outside of an IDE for 45 minutes.

- Whens the last time you used an algorithm (eg b-tree) and for what?

I'd be curious to hear how many people like me would answer "for a coding interview" for this question.

I haven't coded such an "algorithm" since 2002 or so. The closest I've come is calling some framework library's binary sort method.

As the parent of a 16 year old, I find this discussion fascinating. My son used to love reading books, from when we started with the "Bob Books" in Kindergarten, through somewhere around 5th or 6th grade.

He still loves reading, but mostly for items of topical interest. He does it for fun, to entertain himself, and to learn new things...but it's not books! He scarfs up online content like it's going out of style.

TBH, I had no idea just how much he was reading until I paid attention to how much mispronounced advanced vocabulary he was using, which was a sign of seeing and not hearing the words. The other evidence is just how well he does on crosswords, Wordle, etc. The vocabulary is definitely there.

All of this is to say that the article seems to focus on "books" rather than "content." Are kids not reading for fun, or are they not reading _books_ for fun?

It's definitely healthier for me because I just throw it out after.

I'm not sure which is worse; the fact that this is plausible, or the fact that I opened this thread to say almost exactly the same thing.

I'm a bit of a tap water connoisseur, and tap water in the US varies greatly. I grew up in the northeast US, in a town where the water comes from a mostly spring-fed lake. The water has zero chlorine taste or smell. I currently live in another town in the US where the water mostly comes from a local reservoir, and also has no taste or smell. In both cases, water pipes are buried to avoid frost, resulting in cold water from the tap all year.

San Francisco area also has surprisingly good tap water, likely due to the clay/soil in the areas the water is sourced from. In other places, like Florida, minerals and sulphur give the water a distinctly unpleasant taste, and shallow pipe depth keeps the water from getting cool.

I wish the "free year" stuff was cumulative. I'm still in the 10 year free period as a result of the OPM breach. During that time, I've received several additional free years from the other various data breaches I've been the victim of, but they're useless because I'm already covered.

This is why my wife and I started our son in swimming lessons somewhere around 1 year old. Yes, it was fun, but it's an important life and survival skill.

Being a strong swimmer doesn't mean you're invincible, but being comfortable in the water helps in so many of the situations where one might freeze, panic, or otheriwse waste energy. Comfort allows a second or two of rational thought to assess the situation and plan for an exit.

This is very different than my experience at another FAANG. One of my reports was able to take a multi-week mental health leave and return without any negative impact on performance rating or career. Of course, mileage probably varies from manager to manager and org to org.

And, as happened to me recently, the customer states in the demo that it's useless to them and let's just all move on to the next release.

It was actually my second gig working on that as well. The first was a college internship writing management software for a 14 slot switch w/75Gb backplane. The best feature of the software was the "suit" command, which restarted the boards in all 14 slots in sequence, which created a nice light show. We used it whenever someone in a suit showed up in the lab.

My very first full-time job was to adapt a COTS ATM protocol stack to run on embedded devices to power a truck & satellite network. The deadline was 1 year to get the stack running on the hardware, and would be the first of 4 annual milestones related to the project. After about 6 months, I was mostly done the work when I found out that the project was moving to a single release at the 4 year mark.

Ok, not so bad, except that the scope of my task remained the same. The project and my role was funded by the customer for the 4 years, but my deliverable remained the same. My job was to literally do nothing while being available to debug things if needed.

I have a very large garden area near my patio with plants that flower from Spring through Fall. I bump into the full assortment of bees going for the flowers and wasps for my food, but the main harassers in my yard are male carpenter bees that dive bomb me and the occasional female coming out of nowhere to sting me.

I rolled into my sophomore year of college with a P90, 16MB RAM, and a 19" CRT.

All of that was great, but it was Windows 3.11 that made the difference, as that was the the version that made networking work reasonably well.

> When Larry and Sergey started Google, they began by just hiring all the smartest people they knew out of Stanford...

I worked for a large tech company as an intern in the late 90's, which is where I learned smartest doesn't always equal best. There were two of us interns in the org, one on the east coast and one on the west coast. I was in grad school at a regionally known engineering school, whereas my west coast counterpart was a grad at Stanford.

They were one of the smartest people I've ever met and worked with, and were basically a walking encyclopedia of CS knowledge, all the way down to level 1 of the OSI model. They were also entirely unable to execute on anything. There was no ability to plan and schedule work or to stay focused on the job itself.

One of us got a raise and asked to come back next summer and the other got walked from the building by security (a first, apparently) before the summer ended.

Yes, it's anecdata, and over my career I've worked with many other people from "top" institutions. As a whole, I haven't been any more or less impressed with them than any other Engineers I've worked with or hired.

> These posts come up so frequently, people keep falling for buzzwords they don't understand and then start blaming the tech. Distributed systems are all cool and fun but use them as a last option when you have exhausted all other choices.

I've been in the SaaS application business since the early 2000's. When I first started, the big infra question was running on in-house infra or data-center infra. If it was the latter, then the follow-up question was which hosting provider. Regardless, as an Engineer, you were likely touching something that looked and felt like a variation of the box sitting under your desk.

Eventually we got cloud providers, serverless, containers, etc. Growing through the progression of technologies, they all seemed like a natural evolutiion of things to solve certain problems with other approaches.

For newer engineers starting out, they may only have seen these latter things, and at the scales and circumstances that make them a good choice. As such, it may not be that they're the new and shiny thing, but that they're the _only_ thing people have seen.

I was working off 128 in Waltham and the time I worked overlapped perfectly with a city-sponsored local bus route that took people from the train station to the business areas. There were about 15-20 regulars doing the train-to-bus the morning Since the bus basically existed for commuters, the driver would always wait when the train was late.

The most amazing part of that commute was that most of the commuters actually did a cross-platform transfer at North Station from the Newburyport/Rockport line to the Fitchburg line. Again, one reason it worked is that the conductors on the outbound train would hold a few minutes of the Newburyport train was late.

> You can get by without a car in Boston as I do as well, if you work and live in the city.

FWIW, I lived in the city and worked in a suburb, and also was able to live car-free without issue. This was in the days before ride-hailing apps, so I imagine it'd be even easier now. (Not technically car-free, I know)

> Killer one that has shafted us is tying everything into popular deployment and CI tooling. Your product should be buildable, deployable and tested on a standalone workstation at any time

I've currently a VP Eng at a "growth stage" startup, and the state of things when I joined was that about 75% of a dev's time was spent fighting with the external services and data. Someone would spend an entire sprint on a feature, but most of the time was actually fighting with our IdP.

A huge effort and focus (that I had to beat into everyone's head) was that being able to a) run everything locally and/or b) have reasonable fakes for external dependencies means that we can spend far more time building actual product stuff and far less time debugging infra issues.

A long time ago, an F100 company acquired my messaging startup. We hosted client APIs and a web application for 2M monthly users sending 1B messages/month on a single AWS medium CPU server and a SQL Server DB. The rest of our infra was entirely for redundancy and monitoring to enable our 99.995% uptime.

Post-acquisition, the AWS budget I was given to maintain our infra was almost 20x the actual cost, and based on infra that company used to host similar traffic.