But are there practices used at these large companies that small and medium sized companies should not emulate?
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.
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.
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.
Basically, everyone wins. You get a good signal and you don't impose something unreasonable on the candidate
I for one would gladly take that deal. I interview horribly but I’ve been extremely valued anywhere I ended up working.
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.
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.
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.
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.
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.
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".
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.
(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.
K8s isn’t for all problems, but makes sure it isn’t for yours before you rewrite it in a much worse way.
Make sure you use it when you need it. Not because others do it.
https://www.nagarro.com/en/blog/post/76/microservices-revisi...
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.
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.