I wish them the best, but I think they would have been best not drawing the comparison to Salesforce. IME people buy Salesforce not for the CRM but for the force.com platform. The ability to seamlessly build business logic over the entire flow of a business is Salesforce's bread and butter. CRM is a small part that definitely gets heavy use, but it's only a small part of the larger picture.
If they had a way to quickly spin of LOB apps like Salesforce does, and had implemented a CRM on top of that... I'd say they would be much more apt drawing the comparison. Particularly if that doesn't require code to do. I know a LOT of companies that would pay dearly for such a hosted platform, GPL or not.
It's probably wise as a startup to not go for Salesforce parity while building out the core roadmap. You can build a decent business catching new companies and paying attention to their needs unencumbered by the expectations of "switchers".
I agree with your points about what people want / expect from Salesforce. Would kind of be cool to see a CRM have AppExchange + SF data model interoperability.
I'm not a fan of Elon-style "pitch FSD or promise things that you don't have" either. But we had to find the right balance between expressing our vision and expressing where we are which you can see through screenshots/product demos.
The vision is definitely to have something extensible and more powerful than force.com ; we aren't there yet because we need to build strong foundations before that. We already try to separate our business apps from the core engine in the code base to learn what will be the right api and get ready for that next step when it's time.
If that's the case I'd encourage you to take away a few lessons from Salesforce:
1. IT is not your customer. The business is, and they don't know how to write code. Based on what I saw thus far; this is your biggest weakness. The only way to extend the platform at the moment is to self-host and write code.
2. Avoid baking crazy logic into the system now that you'll be unable to fix later *cough* SF 'standard' objects *cough* that will behave in very weird ways.
2(a). Person Accounts look like a good idea. But, they aren't; and never will be. They just create a lot of complications later when someone gets married or starts a business.
If they had a way to quickly spin of LOB apps like Salesforce does, and had implemented a CRM on top of that... I'd say they would be much more apt drawing the comparison. Particularly if that doesn't require code to do. I know a LOT of companies that would pay dearly for such a hosted platform, GPL or not.
I'm curious. What would you use for that today? MS Dynamics? Airtable? Budibase? Appsmith?
After trying out a bunch of tools, I found Appsmith worked best for me but for some cases I had to move on to Windmill (which is not exactly low-code but can be)
I absolutely love Windmill. The ability to stitch scripts together into workflows is great.
100%. You also buy Salesforce because your salespeople demand you too. It's something users are familiar with and excel in. Dislodging an incumbent is a lot more than just the technical product itself.
Twenty would be better served not marketing itself as an alternative as it isn't really an alternative. Instead, focus on their strengths and hone it on a niche audience. Useful guide by April Dunford, who's a guru at positioning (and coincidentally had repositioned a CRM tool previously!): https://www.aprildunford.com/post/a-quickstart-guide-to-posi....
What's ironic about ecosystems is that (as an integration developer), getting devs to build on your platform is so easy if companies would just help them connect to users to better understand their needs, and then give them the necessary endpoints.
I, and many others, would jump to build on basically any tool that facilitated those relationships.
Yeah IMO its a red flag to compare yourself to Salesforce unless you:
* Offer a managed database system that can support common ETL workloads, custom fields, event hooks like post-save, etc
* A embeded-DSL for scripting custom actions, no an API does not replace this functionality
* Consultants/Support-engineering/and other escape valves when a really important business process needs to get fixed or built NOW
* A lot more
And frankly many startups don't have the muscle for this. Its not easy to do database work and its not easy to create functional (not necessarily good, just functional) DSLs and programming languages. These are harder computer science problems that take real talent to solve well. There are valid reasons Salesforce has the market cap it does.
It's because companies don't want capable, experienced or well-equipped. They want genius and it is really hard to test for genius. Granted, almost nobody that gets through any process is an actual genius....
I'd say it's the exact opposite. There are hordes of unqualified people applying to every software dev role imaginable regardless of what you put in the job description or requirements. The tests are there because people are good at lying but bad at faking skills.
Seriously, if you've never hired before, you have no idea how bad this can get.
Here's [1] our practice coding problem. It's quite similar to the one we use on our interview, and not too far from the one Triplebyte used in the past (ours is tuned to be slightly harder at the beginning and slightly easier at the end). The vast majority of candidates, even with some reasonable pre-filtering, do not get past the first step. A very non-trivial number would not even get that far.
that's actually pretty great, but it brings up another issue I have with the state of tech interviewing - it focuses on being able to write code fast. the more senior you get, the more you tend to focus on depth, taking your time to think over the problem and write a good robust solution rather than banging out code fast, so coding up a solution in 25 minutes versus an hour is not really a good test of what the company presumably wants to hire you for.
This is true, and it's part of why this is one section of three.
If you were slow but high-quality on the coding section but crushed the knowledge and system design, we'd probably recommend you - or at least, recommend you to clients that aren't specifically looking for fast coders. Someone we recommended to a client recently had the equivalent of like 1.75 steps on the task linked here, but got consistently high scores everywhere else.
I do wish we could do a more complex, longer coding problem, and one of the things I've been considering is cutting some other stuff to get it up to 45 minutes or something. The current length isn't a principled decision, it's a resource constraint - keeping interviewing costs manageable is essential when you're trying to bootstrap a company in a rough market. Speed matters, but speed over such a short timescale is absolutely artificial (I'd much rather measure speed over a day instead, it's just not practical to conduct a top-of-funnel interview for so long.)
I was one of triplebyte’s interviewers years ago and I can speak to this. In short, you’re right. But two notes:
First, you massively underestimate the range of coding speed you see in an interview. The slowest programmers weren’t senior people who were out of practice. (I interviewed plenty of them). It was people who just seem bad at programming. Like, so bad it takes them 25 minutes to make a hello world program run. (In their favorite language, on their computer and with full access to the internet during the test).
A 2x programming speed difference would have rarely changed the outcome of our overall assessment.
Second, there was an aspect of triplebyte’s interviewing process that I’d love to see replicated elsewhere in the industry that resolves this. And that is, we should be assessing debugging ability. At triplebyte we gave candidates a smallish program (few hundred lines) with 4 bugs and a failing test case for each one. The candidates had half an hour to fix as many of the bugs as they could.
Watching people debug was fascinating.
One clear pattern that emerges is exactly what you are predicting. Smart kids right out of school were great at the programming section. But it was always the more senior engineers who smashed the debugging section. Junior engineers would get lost in the weeds and struggle to get very far in the time we gave them. Some of the senior people I interviewed dived straight in, and even found some bugs we didn’t even know about in our own test.
It seems to me that being able to read unfamiliar code and fix bugs in it is a hard to learn skill that matters on the ground. And frankly I suspect it’s more useful skill than a lot of leetcode problems. I’d rather hire someone who’s amazing at debugging than someone who’s amazing at data structures. Well, I suppose I want one of each on my team.
If I was ever making a programming test, this is something I’d include for sure.
Fair. A good debugging challenge is pretty hard to write well. I remember one of the triplebyte ones I worked on passed through several hands trying to get the calibration right.
That actually looks pretty good aside from the time limit..
It takes me a while to 'get in the zone' - and especially with you base datastructures you wanna think about it a bit as it has
real ramifications on how hard/easy everything else can be.
Still, seems better then most of the 'leet code' type stuff I see :-)
Oh, that brings back memories. When I interviewed with Triplebyte in 2018 and was rejected, my first item in the 'positive feedback' part of the email was "We saw some real strength on the tic tac toe section.", and my first item in the immediately following "the areas we think you can improve" paragraph was "We didn't see the coding proficiency we were looking for in the tic tac toe section--you didn't make very much progress."
...it might have been me, I was writing those emails in the year 2018. That was my first job there.
Jokes aside, we generated those emails largely from a template. If I remember right, "saw some real strength" was "got at least an OK score for code quality", while the negative feedback below was about number of steps. The number of mishaps with that system is part of why we do the feedback a bit differently [1] at Otherbranch, at least for now. I think we did revamp it very late in that team's lifetime, just before Triplebyte pivoted and laid off most of the team that did those (two of us, me + one of my colleagues, moved over to a different team, which is why I'm in a position to tell the whole story).
That is the sort of coding problem I would love to work on as an exercise however the 25 minute time limit would put me off and I wouldn't even start. I enjoy programming and I don't like to feel rushed, and if you're placing that sort of time constraint then you probably aren't a great company to work for.
So, having completed the practice problem with about 45 seconds to spare, what sort of openings are there for the aging-but-not-aged Canadian who can probably only manage part-time remote work?
I don't anticipate us getting a lot of clients with budget for a part-time employee anytime soon, unfortunately. I imagine a lot will be remote, but probably not part time. Still happy to have you in our pool in case we do (I think I see you in the signups list - something about oddball proprietary languages, yeah?) but it's not a wildly high-probability bet in the short term.
I really, really, really wish I had a better solution for this sort of thing.
I do wonder how my “part time” output would compare the expectations from full-time output. During the periods I've worked more conventional jobs, the vast majority of the value I brought was during the oddball times/contributions. Surely there must be some way I can be exploited (in a good way) without implicitly bundling ancillary seat warming into the contract. :D
It got submitted properly and looks like the correct email. Airflow - at least the plan we're on - caps the number of emails to different addresses that it'll send a day, so we hadn't set up confirmations, but I guess normal volume probably isn't a problem for that. (Woulda been fun today, though.)
I have and you are right, it's terrible. However, I'm coming from Ops side of the house so my knowledge on Dev Hiring is talking to them and making sure they are not going to launch LedgerStore without talking to us first. Ops I'm more experienced with.
However, looking at Other Branch example test, it's another data structure question which I would totally bomb. Is this really the end all be all to dev hiring? If they can't do Data Structures, are they worthless to Silicon Valley companies? I'm honestly stumped because we get dev candidates that crash and burn with Fizzbuzz or our REST API test.
> If they can't do Data Structures, are they worthless to Silicon Valley companies?
I think you might be overthinking this - understanding how to model a problem with a data structure is a core competency of any developer. This isn't a "gotcha" question where you need to know union find sets or how to invert a linked list in place.
If the question was rephrased, "design a JSON schema for the state of the board" would you know how to approach it? Because that's essentially what step 1 is asking.
You consider that a "data structure question"? Honest question - I would (do) characterize it as a sort of "fizzbuzz+" that is deliberately NOT data-structure-y, and I'm surprised by this response. Can you give an example of short coding tasks you would consider not data-structure-y?
(For the record, we do ask about DBs and system design in other sections of the interview. The coding is one portion of three for the interview as a whole.)
Minesweeper is all about storing data about the board and displaying the numbers is all about running through data. Seems very data structurey to me but maybe that's non heavy dev side coming through.
Maybe I'm just thinking too much problem, overloaded my small attention brain and misread it. I wouldn't call Fizzbuzz data structure-y however.
I'm also mostly outsider looking in. Never worked at FAANG and working with YC companies, I come on much later and tends to be more keeping the lights on and stopping the duct tape rocket from exploding.
I disagree. Minesweeper doesn’t require anything more exotic than a 2d array of enums. This is bread and butter stuff that you’ll run into in 99% of programs. If someone doesn't know how to use their language’s lists, enums and structs, I don’t think they know the language yet.
A “data structure problem” would involve more exotic data structures, usually of the kind the candidate has to implement themselves. For example, b-trees, heaps, skip lists, and so on.
The reason a lot of people don’t like custom data structure questions is that they come up rarely in most people’s jobs. Lists, structs and enums on the other hand are used everywhere. Your programming job will almost certainly require you to understand them.
I'm a competition programmer so my perspective is generally miscalibrated, but part 5 is usually solved with a BFS. You can say BFS is basic, and it's maybe the part of competition programming that comes up more often than any other in real life (tied with sentinels, which you usually use in your BFS?), but I think it's a "data structures" problem.
If this test is calibrated like the triplebyte programming challenges, less than 1% of people will finish part 5 in the time given. I think when I was interviewing, only about 3% of people reached step 5 at all. Finishing was super rare, and it really only existed to separate the top couple percent. (And yes, we told the candidates that we didn’t expect them to finish in the time allocated). It doesn’t matter if step 5 is harder. Most people will never attempt it anyway.
But even then, while BFS would definitely work here, so would DFS and that’s simpler. A simple, unoptimised recursive DFS flood fill would be like 8 lines or something given by that stage you already have a function to reveal a cell. You just have to call it on all the adjacent cells. I don't see that as a data structure problem. You could argue it’s an algorithm problem, but it’s about as easy as those come.
I think its because the person is thinking you are looking for something especially smart when in fact something like a list of lists would be fine enough, if you can explain the tradeoffs for using them.
I think you are selling yourself short - the problem is just some minor education to realize you probably know most of what you need to know. And I still cant figure out how to get a kube cluster working.
You don’t need to embed game rules into the matrix to solve this problem. (What does that mean anyway?) Just store the board in a 2d array of some sort and write some functions to interact with it.
That’s just not what a “data structure problem” commonly means. If it was, all programs would be data structure problems because all programs interact with data in some form.
A data structure problem is a problem where designing and implementing an appropriate data structure is in some way hard. A 2d array doesn’t fit the bill. It’s not exotic enough.
I was fairly impressed with one during a recent rental. As a car, it seemed quite decent. If the brand wasn't Chevrolet, I'd consider buying one. (Branding is psychology, just a personal tic. I grew up with a Chevy that was fine.) Sedans have the practical aspect of a lockable trunk, and I'm surprised by how many people prefer a smash-and-grabbable real window hatch.
The renting experience absolutely sucked. You were expected to pay a premium, there is meaningful variance in the quality of the different cars and they needed you to bring it back charged (as if everyone has an extra 30-90 minutes on their way to the airport).
They should have treated these like any other car in the same class and done a market price fee for the battery.
My advice: Get the value before the event. Reach out to everyone that you want to meet with before the event and schedule in-person meetings at the event, that will give you license to schedule remote meetings before the event for introductions.
Only go to the event if you have enough meetings with a clear line to enough value for it to make sense. Folks that do events for sales/customers, are working those events well before the actual event and have clear lines to value. If you just 'show up', odds are that you will waste your time and not get value.
> Only go to the event if you have enough meetings with a clear line to enough value for it to make sense.
I agree with this, unless you've never been to one of these events. If you've never been, try to make some connections beforehand, but pick one and go just to see what it's like in person. You'll almost certainly make some connections, and will have a much better sense of how to approach the next one.
That's a good idea. The events we're thinking of attending are massive, so hard to do that pre-work ahead. But maybe we should target smaller ones with the right people.
Events are just one of many signals that you can use to start a conversation. Reach out to every interest that is going, or that may want to go and just use the event as a reason to talk. I've landed A LOT of great leads by just reaching out about events that ultimately neither I nor the contact was going to. It was a good enough reason to start a conversation and assess fit/interest.
When you reach out you can position yourself as a thought leader, someone saving them time, etc.
