But you also deter the strongest candidates because you are not considerate of their time which also gives the wrong impression of the culture at Ramp. Requiring a challenge that could take x amount of hours to complete on a very slim chance that person would get hired is very inconsiderate. There is no incentive. Not everyone who is looking for a job is straight out of college, unmarried and/or don't have other responsibilities. Just because a candidate chooses not to do this challenge doesn’t mean that person wouldn’t be “strongly motivated” or a “strong candidate” to work for you. That’s why proper interview processes exist to sort out those individuals. If you want to limit the amount of “volume”, I would suggest considering other methods or not hire at all. I would assume that the fact I see job postings everywhere for Ramp, including here, and the fact that you require this challenge, must mean you are getting little “volume” of applicants.
plenty of us are married with kids, weird extrapolation. you spent more time debating this on hn than you could've spent on our challenge. i'll chalk it up as bad prioritization :)
I did the Android take home last year and built it with full MVI, Compose, and unit tests and was rejected because the reviewer didn’t like the default animation between screens.
Please tell us more about how Ramp respected my time!
How condescending. Whether you love this job or not, there seems to be valid criticism about your hiring process. Instead of responding with empathy and concern, the glib responses are a turn off on their own. Are you setting a good corporate example in treating candidates this way? Is this representative of your work culture?
So is it safe to say that this tool is mostly trying to solve the developer experience side of front-end development, instead of trying to create a "new" technology such as SSR?
I've just mostly seen "fast" and "HMR" as the features of Vite, but I can't see a team switching over an entire project just to solve something that was probably decently "solved" to begin with.
I don't think anyone is expecting an existing production project to switch over. Vite offers amazing DX for new projects though. Just because something is solved doesn't mean it can't get better.
I'd really like to know what mess people make when they don't rebase.
I've found that using merge gives a readable trail of when something was merged, whether that be from a branch's original branch, or if you're merging into another branch.
Rebasing just seems to cause a lot more headache when something doesn't go perfectly correct in between commits.
Some people are good at making changes relevant only to one task, making commits at appropriate points to that task, and ensuring that none of the intermediate commits are regressions. Sometimes people prefer to deal with future pain of complicating a bisection with broken, unrelated issues.
Personally, I make a lot of mistakes. I commit too early when I missed some bugs or broken builds (eg build on release but not debug, rhel X but not rhel Y). My working area has unrelated changes. I forget to change branches...
So, I figure out what the destination looks like, do my best to keep things clean and small, and rewrite history before the PR as if I was one of those careful people.
My recent advancement has been to realize that reordering commits for an efficient fixup is much easier than splitting commits, so I'm better off doing things out of order. I also use worktrees to be able to ensure each commit is correct as checked out without stale state.
> I'd really like to know what mess people make when they don't rebase.
I think this part is really telling:
> And worth mentioning, the question’s partially moot for people using Github or other hosting services where some GUI tools are built-in. Using the CLI for all interactions with Github, and using the site for the visualizing diffs & branches is totally reasonable.
GitHub's branch view is uniquely awful, and doesn't try to call out branch history at all. Commit lists should either include a railroad diagram or only include the left-facing history. Anything else is just inexcusably broken.
No disagreement from me, so I don’t know what that snippet is telling you. I wasn’t saying GitHub or any other service is the greatest, I was only saying that using the GitHub site mixes GUI and CLI workflows, since using GitHub is so common.
In some sense that goes to the point that CLI can be better than some GUI tools. The ascii railroad diagram you get with git log might be preferable to what GitHub can do.
> Rebasing just seems to cause a lot more headache when something doesn't go perfectly correct in between commits.
You mean merge conflicts? Rebase gives you an opportunity to deal with small merge conflicts arising from single commits. I much prefer that to a big merge commit dealing with all the conflicts simultaneously.
Also, rebase makes the merge conflicts disappear for future readers, making the included commits nicer to read.
Is this about rebasing vs merging or is it about whether to use `git rebase -i` to polish my own commits?
Sometimes I think maybe we should have two different names for these commands.
I think an interactive rebase requires a good mental model of the changes to split or merge them correctly in addition to knowing the CLI. I find it quite hard at times.
Interesting take. If anyone care to actually learn how git works when rebasing, then it becomes much simpler. I always rebase and in 10 years of professional use, never once had a problem with it. That doesn’t mean other people don’t.
> If anyone care to actually learn how git works when rebasing, then it becomes much simpler.
That's a very arbitrarily vague answer. It's very easy to hand-wave the misuse of a tool just by saying "you don't know it well enough". It's much harder to admit that maybe the tool is just difficult to use in the first place.
I have similar experience as the person you are answering to. Unlike them, I got into rebasing only recently. It isn't really a hand-wave of saying 'you don't know it well enough'. This paradox is caused by a quirk in git's design. Git uses a hybrid model for dealing with versions. It uses snapshots for storing them, as well as for operations like fetch, clone, etc. But that mental model causes a lot of confusion for operations like merges, pulls etc. Git uses the diff-patch model for those operations. Even weirder, much of git is actually designed to use the diff-patch model. The first time I ever got a grip on those operations was when I did rebasing. I found git much easier to understand when I could attribute each operation to the model git uses behind the scenes.
> It's much harder to admit that maybe the tool is just difficult to use in the first place.
That is unfortunately true. Git feels like a tool with several parts that were bolted on to solve problems its users (developers) faced. I didn't have that same difficulty with mercurial. I get this feeling that a pure patch based tool like pijul would match their workflow well and still be easy to learn.
Naw, merge is orthogonal to cleaning up local history. Merging a mess is still a mess. Some people are fairly clean from the start, and some aren’t. And it depends on the task at hand, messes are easier to make when you’re doing more than one thing at a time.
Do you care to explain? How can you have a worst history when the `main` / `develop` branch have a linear history? I rather have a linear history where git bisect is trivial to use then a mess of merges and a hard to follow history.
This is my reaction based on experience too. I find that in most companies I've worked at that there are generally 2 camps; one is the "I want history to track what I've actually done; good, bad and ugly", the other is "I don't want to wade through 1000 "typo" commits - they should be pretty and streamlined".
I fall into the former camp, but others (who I respect) fall into the latter.
FWIW, I was mainly referring to making local branches presentable and/or just organizing things, not to rebase as a merge strategy. Don’t assume that rebase always means moving the local branch to the head of main, and don’t assume that rebase and merge are interchangeable. There are a lot of ways to rebase.
That's what I thought the discussion was about, locally 'clean' commits. In this context Rebase is so much more useful. I recently had to use the 'unto' option of the rebase command. 'unto' may show someone that they didn't really understand rebase though they could use the simple form of it, rebase -i x.
I'm someone who has started enjoying rebasing workflow after using branch-merge workflow for more than a decade. So perhaps, my experience may be useful since you can compare the same person using both of them. The first thing to realize is that branch-merge and rebase workflows try to achieve different goals. Branch-merge tries to preserve history of the code, with every wart and quirk included. Rebase tries to achieve a clean history where every commit is an entire fully functional (without known errors) feature with complete explanation in the commit message. People fight over them, but I find both goals to be meaningful and the choice depends on your priorities. In fact, I do both- publish a clean history in the master and the original messy history as a separate branch.
> I'd really like to know what mess people make when they don't rebase.
As a developer, we have the expectation that git will allow us to experiment with features, make mistakes, correct them, roll them back and improve. That stage is also so messy that you'd leave short commit messages that would make sense only to you. This is fine while developing. But this leaves many commits that are functionally broken, partial or rolled back later. That, along with vague commit messages and illogical commit order make it really hard for someone else to pick up a working commit from your branch and continue. Heck! I find it hard to choose a commit even from my own older repositories. That isn't the case with good projects like the kernel. You can pick any commit on the master and it will compile and work with all the features advertised up to that commit message. It makes a users' life easier.
> I've found that using merge gives a readable trail of when something was merged, whether that be from a branch's original branch, or if you're merging into another branch.
This is true. It's harder to achieve with rebasing. But it's possible with some work. I usually leave the original messy feature branch intact, and mark the rebased HEAD with a similar-worded tag or branch.
> Rebasing just seems to cause a lot more headache when something doesn't go perfectly correct in between commits.
Don't take any offense, but those are beginner blues. It happens in the early stage of learning rebases when you don't have a full grasp of what is going on. People evolve different strategies to overcome this once they are a bit more comfortable. My strategy is to create a temporary branch for rebasing (at the same commit as the feature branch) and do multiple rebases on it. I do only one or maximum two operations during each rebase. The result of each rebase is reviewed before doing the next round of rebase on the same branch. The original feature branch is left intact in case something goes wrong - though I never needed it.
Other people do rebasing occasionally while developing the branch. They do this after every two or three commits. They end up with a clean history to merge (fast-forward) to master, by the time they finish the branch. All of these operations can be simplified using helper tools like git-revise [1].
My absolute favourite method is to not use rebase at all. Craft the perfect commits as you develop. This can be achieved with a patch stack tool like quilt or stacked-git [2]. It allows you to move your changes to a patch (commit) of your choice. This is like having multiple staging indexes available. You can also split, combine or reorder patches. The patch stack evolves as you develop, but you end up with a perfect history to merge (fast-forward) at the end.
