[lhorie]

Been in a very similar situation. They found me (probably by crawling Github/LinkedIn), reached out to me saying they had a role that was similar to the stuff I was doing in open source (which was true), but the interview process was to go through the standardized pipeline (4 1-hour sessions is pretty standard among big tech cos). I went with it because total comp was quite a bit more attractive than what I was making at the time and opened a path for further income growth for not just me but my wife as well.

I've recently entertained an invitation from a FANG recruiter just to see what they had to offer, and they agreed to skip the screener round and told me "I was already approved for an offer, from HR's end" assuming the second interview round yields good results (this was for staff eng level, if it matters).

My perspective on this: a lot of recruiters and tech leads use automation to find prospective candidates and they tell all of them they found their OSS projects interesting etc, but don't actually understand how that project translates in terms of coding ability on an individual basis (i.e. they haven't actually reviewed code to determine whether e.g. you're actually able to think algorithmically or are just gluing libraries together). That's sort of where the leetcode stuff is supposed to come in: by pushing you through the standardized funnel, they can get a better gauge for how you stack against other candidates. N.B: Whether that provides a good indicator of job performance at all in the first place is a can of worms of its own, IMHO.

My advice: weigh in compensation, career growth and job alignment to decide whether this opportunity is for you. If so, treat the leetcode stuff as a formality: if you have the chops, you should be able to pass with flying colors. The most important question to ask yourself is "what's in it for me?"

[pscanf]

> you're actually able to think algorithmically or are just gluing libraries together

Going a bit off-topic, I don't see however why being able to think algorithmically should be more important than knowing how to glue libraries together (not saying you were implying it, just wanted to share a thought).

I feel like 99% of my job as a developer doesn't go beyond the complexity level of "take a list of things, do something with each". On the other hand, a very important part of my job is to figure out how to glue things together so that they fit well and I'll be able to glue even more things in the future. Admittedly I do pretty run-of-the-mill web stuff, but - looking at job boards - it feels like the vast majority of jobs are like mine. So - for those jobs - I'd think that having a good gluer is more important than having a good algorithm-er.

[taylodl]

My team refers to at it as "plumbing" - we are modern data plumbers. We "glue" the pipes together to make the data flow. Ever see spaghetti plumbing? Some application architectures look like that. It's just easier to hide because normal people can't see what a wreck it is. Anyway, there's no shame in being a data plumber.

[lhorie]

> I don't see however why being able to think algorithmically should be more important than knowing how to glue libraries together

There's a pretty wide scale in terms of what exactly that means.

On one end, there's the status quo of what is expected of a candidate for a certain type of position. Recruiters sometimes do just spam people based on the results of some linkedin/github crawler, and having a github presence doesn't necessarily mean the candidate has coding chops (I've seen my share of people w/ portfolios consisting of hack reactor assignments). For most tech interviewers, doing the "due diligence" of evaluating a candidate might mean ensuring that the candidate can deal w/ recursion or async or other relatively mundane aspects of programming which are nonetheless algorithmic in nature. "Algorithms" doesn't necessarily always mean inverting binary trees or geeking out about sorting algorithms.

On the other end, there are roles that are very specifically NOT about writing cookie cutter React+Tailwind apps, and which do require having at least some algorithmic chops (for example, in my current job, I've had to use hashmaps/sets to deal w/ performance of recursive graph traversal routines on various occasions). Despite specializing in Javascript, my involvement w/ React might be limited to explaining to a product engineer why class properties might be throwing syntax errors or explaining WTF are stale closures in the context of useEffect or explaining what's the relationship between peerDependencies and referential equality, rather than directly writing any JSX per se. No doubt you could pick up those troubleshooting skills while building CRUD apps, but those are ostensibly not the sort of thing that you'd be expected to know for a run-off-the-mill React job. But being able to deep dive into these types of things day in and day out may be well within the scope of what's expected of a platform/devexp/productivity engineer role.

[toast0]

Algorithmic thinking and gluing things together well are both important. Algorithmic thinking is easier to test, I think, and also harder to teach.

I don't think you really need to spend 4 interview slots on it though. Two slots should give you enough signal there, IMHO, or you're not giving the right problems; possibly three if you get solid maybes from the first two, but then you're missing out on whatever your other slot was.

[broahmed]

Hey OP, to go off what lhorie said:

1. Does the company actually know what your open source project does and how they want to fit into the company's product?

2. Agree with lhorie that an interview consisting of 4-5 sessions of 1-hour each is typical in big tech companies based on my experience. Keep in mind they're not interviewing you for your technical chops alone which your open source work has already proven; they're looking at whether you'd fit in socially (which is pretty easy in my experience: be polite even when disagreeing with the interviewer and don't come across as an axe murderer and you'll be fine).

An alternative you might consider proposing to them is for the company to hire/sponsor you to continue working on your open source project with the agreement along the lines of:

1. you'll be adding features to better fit their needs

2. you'll help them plug your project into their product as needed