1. It is impossible to be, at the same time, a "good engineer" and "difficult to work with". FAANG can hire 30 people to work next to one toxic person so their impact can be 1/30th the pain.

2. Interviewing. FAANG can waste 30+ engineering hours on each candidate because of how much money they can burn. Don't do leetcode interviews. Find someone who you think is good, hire them, if they're not good let them go. Don't make a soul crushing interview process.

3. Open office / an office. It's a complete waste for most startups (unless you're a hardware company and can't send the hardware units to each dev). It's a sunk cost and "back in my day"-ism in FAANG.

Hiring someone just to fire them later because you didn't bother to interview properly is extremely cruel!! Seriously, don't do that.

That's a mischaracterisation. You don't hire someone (which is an expensive and time consuming process that's meant to add value to the business) just to fire them. You hire someone to integrate them into the team so that the overall value that you can deliver increases. And it's not that I didn't "bother" to "interview them properly". It's that my (and all) filtering processes are imperfect and sometimes bad candidates slip through.

Given that interviews are an imperfect process both ways, it makes sense to keep a period of time where both parties can shake hands and leave if it's not working out. If the new employee doesn't like some aspect of the company that he or she didn't know about after working, they should have an option to leave. Same with the employer. I've had several experiences with candidates who've gotten in using fabricated credentials and other dishonest means and sometimes plainly in bad faith. Given the small size of my company and my limited resources to conduct interviews, these kinds of false positives are things I have to live with.

Now, I have two options. Keep this person (who's not going to leave and not going to accept feedback on things they need to improve on) thereby hampering the functioning of the team as a whole or let them go. I want the second option open and I'm upfront about it. I tell them openly that there will be a probation period after which we'll make the job permanent and during this period, I try to conduct regular one on ones and communicate with the new hires to see if anything is wrong on my end.

It's not a perfect system and I'd love to improve on it but it works for me, for my company, employees, and clients and there it is. And while it sounds "cruel" in theory, in practice, it has reduced false positives quite a bit. I've had to do this just once in the past few years (and that too in an area that I'm not very familiar with - marketing). Usually, being upfront about this gives candidates the message and people who are acting in bad faith make excuses and leave.

Nit: When you're interviewing it's worth trying to avoid being exclusive by saying things like "he or she". Even if you don't believe in trans rights, it's easier to say "they".

It’s more about finding a balance than being fire-happy.

Consider: 3 days of all hands interviews and super stressful with a 5% chance of being fired.

Vs

One two hour, non adversarial interview with an 8% chance of being fired.

I made up the numbers but it’s an example of where the approach would make sense. Just as an example.

I personally want to find a company that has some OSS software and do a paid contract to improve the software. Some reasonable contracting rate for 1 to 3 PRs.

Basically, everyone wins. You get a good signal and you don't impose something unreasonable on the candidate

You could always state it up front that it’s your process.

I for one would gladly take that deal. I interview horribly but I’ve been extremely valued anywhere I ended up working.

>2. Interviewing. FAANG can waste 30+ engineering hours on each candidate because of how much money they can burn. Don't do leetcode interviews. Find someone who you think is good, hire them, if they're not good let them go. Don't make a soul crushing interview process.

The only "algo" I have people do is a simple Fibonacci algo. Other then that, we chat about development. It's fairly easy to determine if someone knows how to develop software, and I'm just trying to find people with the right attitude that I know I can work with. Then I give them a few months, if they don't cut it, then we part ways. That's happened once.

Not sure why I got downvoted for this. I assume because of the other comment saying that doing this is "cruel" which it isn't. At all. If someone lies and says they know how to develop, can talk about development in depth, but can't actually develop any software that's on them. I've had to fire people who did stupid algorithims and harder interviews after a few months just like the one time that I've done so with my current technique. In all cases, it's been because the person I interviewed lied. In the cases with stupid algo tests they studied how to leetcode, and not how to actually develop software.

In my company actually developing the product features is a low status activity. Everyone strives to be someone who influences how the features are developed - by making platforms, by writing standards, by leading meetings - but it’s understood that you’ll never be promoted or paid well if you’re the one actually coding end-user functionality.

Don’t do that. Center and value the actual software construction; make sure you treat the “meta” as an unfortunately necessary cost rather than the goal.

I would say the biggest practice that smaller companies should not emulate is "rolling your own" otherwise known as "not invented here". For a large FAANG company creating your own versions of things can potentially pay off and if they don't those companies can eat the investment cost with out too much trouble.

Smaller companies should focus on the business problems though instead of rolling their own database, orchestration, or programming language. At a large enough size doing any of those things may pay off but when you are smaller they are just a distraction from your core business.

I'd recommend the opposite. Learning tons of 3rd party tools and relying on multitude of external dependencies is dangerous, especially when company can't afford sudden downtime or security breaches. For simple enough tasks, like many those tools on the market are solving, it's arguably better to create a tailored version in-house than to learn the approximation from the market, then spend resources associated with long-term costs - upgrades, learning, payments...

Focusing on business problems is good and all, but if you're ruthlessly outsource everything else, you'll find yourself in the middle of patchy solution with little control and no end of gotchas - technical and otherwise. If you plan to use 10% of a tool and going to pay for 100%, for startups it should be a no-brainer decision.

If you can’t afford downtime and security breaches, you can’t afford to be shipping an amateur and half baked version of something that externally is backed by a bigger and more skilled team than your entire engineering org. You can potentially simplify your approach so you don’t need anything in the category.

There is always going to be some nuance. But there is a big difference between implementing your own database and implementing your own deployment script. Starting out small and adding tools to your toolbox is going to be a judgement call. But too much NIH and you spend all your time reimplementing Bigtable or Cockroachdb instead of building your product.

True. It's just my observation that today's approach is mostly "let's focus on our value proposition and outsource everything else" to the degree it becomes detrimental for the product and company.

Surely if you're trying to re-implement PostgreSQL, it's, to put it mildly, interesting (though even here there could be discussions - perhaps you just need a specific slice of functionality?). But for many, many other things, which are at worst a few man-weeks works - and sometimes man-hours, if you're sober with requirements - you could win with the other approach. If you're adding something external, just make sure you're serious about that - documentation, technology background vetting, training, all those things. Otherwise the opinion that "external solution produced by team bigger than ours" is better could be based on an illusion.

There is a snarky saying at one of the large tech companies that goes something like "I don't know how to count that low."

When you're facing off against large companies as a smaller player this is one of the tricks you can use for leverage. You can serve the markets that larger companies feel safe ignoring because they are currently small.

They should however be markets that you expect to grow over time.

Paul Graham talks about this in some detail in his essay "do things that don't scale".

http://paulgraham.com/ds.html

Don't try to be a large company.

Large companies suck. They obsess over processes and demand formality.

The best thing about working at a startup is that it's a startup!

At a startup, you can be informal. You can do work that wasn't assigned to you. You can communicate with everyone on the team directly. You can change your planned design and get right to working on those changes.

People think that companies are big because of the convoluted processes they use. It's the other way around.

If you have 100 people to do 95 things, then it makes sense to give every person a specific structured role. Else, why have 100 people at all?

When you only have 30 people to do those 95 things, then your structure not only has to be, but can be much more organic and fluid.

Microservices should be avoided in my humble opinion. The maintenance cost is just too high for small and medium companies.

I think I agree. At least the way our company does microservices and staffing, this makes sense. We have a team if about 6 devs owning about 12 apps, many of them microservices. The overhead for technical upgrades and prod support is high. They always want us working on new stuff too. If a product owning team is around long enough, eventually you have to stop adding new apps to that team unless you retire some of the old ones.

Two takes I have on micro services.

(1) I had a system which was mostly affordable to run except for one part that had very different needs. Breaking that into a separate system implemented differently kept the whole thing alive for another two years in a tough environment.

(2) Decoupling dependencies and patterns is not a strength of microservices it is death itself. If you have JDK 6 here, JDK 7, and JDK 8 in different places because you can’t afford to update you will find you can’t afford the differences. If you do everything the same way in every microservice then the microservice architecture is not any more expensive than the macroservice architecture. If you think you get freedom by doing it any random way you are really in slavery.

Don't interview like FAANG unless you're offering the same compensation - otherwise you're going to get a lot of people dropping out of your funnel because the BS isn't worth it for what you're offering.

Kubernetes isn't the be-all and end-all of how to run your applications.

I would venture to state that Kubernetes is not a good, cost effective solution for >90% of the applications it's used for.

Just got to a startup, they took this point of view and now they have a terribly hacky ECS setup where they have basically rewritten most of kube’s functionality.

K8s isn’t for all problems, but makes sure it isn’t for yours before you rewrite it in a much worse way.

Microservices is an solution to an organisational problem.

Make sure you use it when you need it. Not because others do it.

I think large companies often abuse it as a method for problem dissection. Reminds me of my university group that used git as a sync service.

Large organisations largely think about Conway's law when doing Microservices and that information is left behind when sharing how they did Microservices. Since the why is mostly a management reason.

https://www.nagarro.com/en/blog/post/76/microservices-revisi...

Developer chapter leads as managers. I believe this is a model from Netflix. It's absolute garbage at my company. I want to say it's because we have IT as a cost center, but it might run deeper than that. Who honesty thinks that making a senuor developer split their time between managing people who aren't on their team and coding for their own team is a good idea?

Off the top of my head:

CI/CD is two processes, not one.

You cannot put code in prod and say you regressed it unless you drop everything in an instrumented environment, and ran everything against it.

Just because you hired a bunch of software engineers, you are not obviated from keeping around someone who knows what they are doing.

There are two faces to Quality: 1-I will negate this suffering 2-I will replace one form of suffering with another, to buy time, and exploit the human tolerance/blindspot for churn and novelty to keep my revenue coming in.

1 is incredibly difficult, expensive, and full of work you just cannot avoid or get around. 2 is easy, modus operandi, and actually synergizes with multiple other business cycles, and is thus considered the "No one ever got fired for buying IBM" route.

If you are not doing 1 you are doing 2 by default.

corporate process - more of a problem in mid size companies, but: installing execs / VPs from large tech companies. they replace all the managers down the chain and stir a bunch of crap up, and usually only the poor performing ICs are left at the end.

using java spring framework

Could you elaborate why the java spring framework is a bad choice? I wanted to get into backend development and i thought spring is a good and battle tested framework? I also thought of using rust, elixir or go. I chose java spring because i already know java and compared to rust and elixir the support for third party libraries is much bigger.

The Java ecosystem is culturally heavyweight and verbose with the needs of very large, bureaucratic organizations and Spring is one of the biggest examples of it (although Spring Boot has done a fair bit to modernize workflows). The struggle I can point to with a previous company was that our Java based stack made hiring extremely hard for our small company because large companies with deep pockets could hire for largely the same job at double our budgets, and for people wanting to work on sexier languages and platforms such as Rust, Go, or even Python other small companies offered that freedom. The hiring pipeline was so problematic it’s led to several years of delays rolling out features that the rest of the market has had and whatever intrinsic advantages the business had is possibly irrelevant as even the larger players have been able to do 99% of the same things.

So being able to quickly move is a large advantage of being a smaller organization and anything that demonstrably hurts that advantage should be stricken from the company’s investments ASAP as long as it stays small and has no other material market advantage.

It really all depends upon what makes sense for one’s situation but I was very frustrated with our hiring pipeline and the outdated stack made things much more complicated to do basic things than it should have.