Ask HN: Ridiculous job interview. What do I do? | Hacker News Reader

Ask HN: Ridiculous job interview. What do I do?

30 pointsbusyuser105 comments

Who: Series B startup with ~$100 million in funding, me open-source developer

What: engineering manager writes me e-mail that goes like: “we found your open-source project and want to offer you a job”

In a meeting they explain how they were interested in using my open-source project and want to hire me so i could carry out a similar work for them

Then they go on and explain i’d have to do 4 more meetings 1-2 hours each, including a leetcode-style tech interview

In my head i’m thinking: “If their leetcode-engineers are that good why do they have rely on my open-source?”

What would you do in this situation? Would you jump through the hoops in hope of getting relevant work?

View on HN

Do you need or really want the job? If so, this may be their standard interview practice (although a bit drawn out) and have to accept it.

If the gig is more of a "nice to have" you could respond to them that your portfolio is the repository, and that given their interest in you, meetings to establish personality fit for a cohesive team are great, but a coding interview seems unnecessary - in professional wording. Make the process work in both directions.

I believe excessive interview practices are a red flag. It can show a lack of understanding by the company of what they need, or worse a desire to "see how candidates do under pressure" (i.e. hazing) which can be indicative of a toxic environment.

> I believe excessive interview practices are a red flag

I agree that excessive interviews are a warning sign, but that needs to be kept in perspective. 3-4 one hour interviews is almost standard practice in many locations and tech sectors. Even 4x2 hour interviews is still only the equivalent of a single workday.

Interviews go both ways and you want to use this time to get a feel for the company and your potential teammates. Treat it as a bidirectional exercise.

Having too short of an interview process can also be a red flag. Skipping the interview process is a common trick at “meat grinder” companies that hire a lot of people at once, crush them with unrealistic demands, and then only keep the few people who are willing to put up with it. When they’re hiring en masse and only care about code quantity and not quality, skipping the tech interview is a way to streamline the process.

> I agree that excessive interviews are a warning sign, but that needs to be kept in perspective. 3-4 one hour interviews is almost standard practice in many locations and tech sectors.

For someone who comes to the company cold or in response to an advertised opening, sure.

If the firm is reaching out to a prospect, its not a random unknown applicant, and the filtering should be substantially less. If its not, its a sign of managerial dysfunction at the firm, which should be a negative signal to the prospect.

Hard disagree. Outside of famous FAANG companies, modern hiring is largely recruitment-driven. Either recruitment by the hiring managers, or by dedicated recruiters tasked with identifying potential candidates.

Asking everyone to go through the same interview process isn't a sign of dysfunction, it's a sign that the company has their act together and is making an effort to compare potential hires using the same framework.

Congratulations! You did a great job identifying what's wrong with hiring at tech. Everyone keeps saying hiring in tech is broken. Now you know why.

These days, FANG/MULA have dedicated recruitment teams actively reaching out to people too. Depending on the candidate's qualifications, the first round is sometimes dropped (this is sometimes called a "red carpet experience" and it's specifically designed for poaching) but the lengthier second round (of 4-5 sessions) is generally non-negotiable.

Really depends on the qualifications of the candidate. Cold calling on linkedin is very prevalent these days. Even FANG does skip to the second phase of an interview loop, but only in cases where the candidate has an outstanding resume and is worth going the extra mile to poach. But for run-off-the-mill jobs, no, standard funnel is standard practice because the recruitment team at the top of the funnel doesn't have the skills to evaluate candidates in depth and the tech interviewers at the end of the funnel usually have no idea where the candidate was sourced from.

> Even 4x2 hour interviews is still only the equivalent of a single workday.

It is crazy to me to casually drop that it's standard for a company to get a free day from someone they're interviewing and may just never contact again.

It's not a free day, by any means. The company is dedicating 2-3 times the hours of the interview, minimum. Determining a good fit is expensive.

On the other side, I've never heard of an interview where the candidate is given real work. Sure, they might ask about a problem the company has faced in the past, or is facing, but it's unlikely the response is used in any meaningful way, other than determining the candidates expertise and methodology for approach that type of problem.

> It's not a free day, by any means. The company is dedicating 2-3 times the hours of the interview, minimum.

How many hours of research, experience and interview prep is the candidate bringing to the table? When you can answer that, you can make a determination on whether the company is dedicating more or less than the potential hire.

imho, these interviews where you have to do weeks or months of prep, are focused on a candidates ability to learn familiar concepts and allow for easier comparison among candidates and consistency over time.

That being said, for non FAANG style interviews, prep shouldn't significant. That being said, I'm agreeable to accepting both parties have a sunk cost and no interest in wasting their own, or the other party's time.

The relative cost to the interviewee and the employer aren't really comparable.

The company isn't going to drag someone through 4 separate interviews if they're not serious about hiring.

One of the reasons it's staggered is so the company or the candidate can end it early if it's not a good fit. Less time wasted this way.

Frankly, I'm kind of shocked by the resistance HN has to spending a couple hours interviewing with a company. You're going to spend several years of your life working with this company. Is it really a dealbreaker if they ask their candidates (included your future coworkers) to participate in a few extra hours of discussion and confirmation?

In the real world, I offer to schedule interviews on lunch breaks, before or after work, or on weekends if that works better for people. Practically speaking, most developers (especially WFH/remote) have zero problems finding time during the day for a 1-2 interview session. That's equivalent a long lunch break or a quick errand.

In practice, I've never had anyone decline an interview for lack of time and very few people ever take me up on my offer for flexible interview hours of their choosing. Most people are eager to get to talk to the company, hear about the job, and show the company what they can do.

> Even 4x2 hour interviews is still only the equivalent of a single workday.

How many software engineers are working "hard" or to the level of 4 long whiteboarding-style problems for all eight hours of their day?

In my experience, not many.

Likewise, those 1-2 hour interview sessions aren’t going to be hardcore coding from the second the timer starts until it ends. Some or even much of it will be two-way conversation and a chance for the candidate to get to know the team.

I'm beginning to wonder:

* how crazy some other company's interview loops are, if they really are coding every single one of those hours.

* if people on HN are actually on interview loops, assessing candidates.

That's a very subjective claim. For me personally I tend to get stressed out even on simpler problems.

The best two-way conversation at least for SDE interviews IMO is the systems design one because ideally it really is just a back-and-forth conversation.

"Even 4x2 hour interviews is still only the equivalent of a single workday."

So about $400 of labor?

Neither the prospective employee or employer get a good 'feel' of each other because both are giving 'performances' in a completely different context than actual work.

No one has any real, statistically valid and logically sound, data on hiring practices. It's all dogma & "intuition".

It's also worth keeping in mind that you will be working with other people who went through this same process. Maybe you're an awesome engineer who works well with teams. If the interview process isn't effective at proving that, though, then your co-workers might be bad engineers, have bad attitudes, or otherwise be poor team players. You might resent a little bit having to prove that you're a good hire, but understand what else would happen if they didn't.

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?"

> 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.

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.

> 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.

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.

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

Don’t listen to all the middle managers on here telling you you should jump through hoops. This interaction now will set the precedence for the rest of your working relationship. I’d bring it up for a discussion with them.

As a middle manager I can confirm, I have a certain set of standard interview processes I apply but if the candidate is warranted to ask for an alternative approach to assess their skills in condensed time I can accommodate those situations too. Simply asking directly is most likely the best approach, suggesting a route is likely fastest to get an answer e.g. instead of 4x1hr can we do 1x1.5-2hr and reference your code for them to measure your skills overall.

Cool, thanks mate!

Do you have an idea how i can bring it up in a polite manner?

I personally always favor directness. That said, your post is pretty inconclusive: there's a big difference between 4x1 hour interviews and 4x2 hour interviews.

You do realize that working there would probably give them broad rights over your open source project, right? Standard employee contracts assign work that you do on their hardware, during their time, or that are directly related to their business. You certainly tick box 3.

You also aren't clear if you want the job. If you want it, you're probably going to have to do some hoop jumping. If you don't, then no hoop jumping required.

Anyway:

Hey, thanks for reaching out and it was a pleasure meeting you over zoom. It certainly sounds like [X] has some interesting work, and I'd obviously love to see my project deployed. Given my experience in the area, I can definitely provide [YY].

However, to be direct: while I'd love to check culture fit, your proposed use of my project has validated my ability to write software. I'm not interested in a full interview cycle including code tests.

If you're interested in proceeding, I'm happy to spend up to two hours meeting with your team. Alternatively, perhaps you would rather engage in a consulting relationship where I retain ownership over my project?

Cheers.

If you NEED the job and the leetcode quiz/exam/hoop-jumping is a HARD REQUIREMENT, then you may not have a choice. Tell them it seems a bit weird to run you through the gauntlet after specifically calling out your open sourced code, and maybe suggest an interview that will be more telling on how well you’ll be working together versus deciding “if you can code” (your project should already indicate that?) If they’re bothered seemingly or obviously and cannot take the feedback lightly or seriously then maybe that’s a good indication to consider other opportunities.

reminds me of the homebrew situation

> Google: 90% of our engineers use the software you wrote (Homebrew), but you can’t invert a binary tree on a whiteboard so fuck off.

https://twitter.com/mxcl/status/608682016205344768

More info: https://qr.ae/pGmK8A

My personal favorite quote from it:

> I am often a dick, I am often difficult, I often don’t know computer science, but. BUT. I make really good things, maybe they aren't perfect, but people really like them. Surely, surely Google could have used that.

I get his frustration, but why would I want to work with someone who openly admit that he's a dick and proud of it? Linus is an example, as great as he is, why would I work with/for him unless I'm desperately need him?

Because you can exploit them to write great things without really giving them a platform for being a dick.

A good manager will isolate an asshole from the rest of the team, but still capture the value they produce.

I agree. If I'm honest his writing style makes him seem like he has a somewhat abrasive personality and I do wonder if that might be a factor as well.

I don't recall him saying he's proud that he's a dick. I read that quote as that he's introspective enough to recognize it.

Everyone else is a dick and just can't accept it.

We've been having a larger internal debate about the type of leetcode interview and architecture questions we ask, and how valuable the signal is for testing something completely unrelated to our real work.

My two cents, the interviews here are going to help them assess how you work your way through problems, how you think and process, and how you communicate. That is a very valuable signal to get out of someone you're potentially going to be in the trenches collaborating with. That is the true value behind these route sets of challenges, much more son than "can this person code?"

We've hired engineers that have been absolutely amazing teammates in our department that on paper have had wonky technical interview questions, but it was because of the attitude and their approach in the moment that won us over.

They know you can code, they can see the OSS. The "hoops" here are for the intangibles.

I have hired quite a few interview candidates that did AMAZING on the interviews and code tests, but turned out to be terrible programmers when it came to real world problems and/or team dynamics.

I've also had candidates that utterly bombed their interviews, but we gave them a chance and they turned out to be some of the best employees we ever had.

Unless someone's daily job is going to actually be writing leet puzzle code all day, leet puzzle code tests don't tell you all that much about how someone can actually perform their job, especially when under the pressure of a stressful interview environment.

I'm at a point now where I firmly believe that what all these leet code tests are actually about is GATEKEEPING. It's about making devs feel smug about themselves as they administer the test to the candidate, and it's about inflating their own egos. It's basically just a form of hazing. After all, anyone can ace those puzzles if they study them beforehand. You might as well be hiring them based off of whether or not they can solve a Rubik's cube.

So I stopped doing those types of interviews. I have a "gut check" conversation with the dev to get a rough sense of their skill level, and then I might hire them on a contract basis to do REAL work on my projects. If I like their work, I might hire them full time. It's the ONLY REAL way to find out how someone actually works, and whether or not you get along with them.

In addition to that post:

1) They said they only "hire the best" (i'm certainly great, but not the best)

2) They bragged about how they have "more money they could ever spend"

3) They expect me to compromise my side projects and consulting activities, because "Series B startups are a whole different type of experience"

Run away!

Edit: For clarity these to me mark them out as being extremely naive about their own value.

I have this feeling that they're spoiled because of all the money they've got

Good thing is, i don't care about money as much as they do!

The other thing to do is switch the script and offer them consultancy that suits you. I doubt from your description they’d take the offer but it sounds way more like it’d fit you.

That reads to me like a nice collection of red flags.

1 - They all say that, it's a meaningless phrase used to cover candidates in the effluence from the southern end of a north facing male bovine, if you get my drift ;). I'm sure they also pay the highest salaries ever to make up for hiring only the best.

2 - Oh my aching sides. If they really have more money than they could ever spend, they need a visit from a clue-by-four about business planning. If they're raising that much money are are serious about their business, each one of those dollars should've already been earmarked (even if the earmark just says "runway").

3 - Translation - you're cordially invited to work 168 hours a week as a baseline and if necessary, work nights on top. Yes, I would expect that they mumble something about having a say in your side projects (that are relevant to their business) and consulting activities that might interfere with their legitimate business interest, but a lot companies seem to mistake that for owning their employees. This tends to be easier to handle if you're consulting with them rather than become an employee. There is a legitimate need for a compromise here though, especially if you are an employee. But tread carefully.

The third point also brings up another interesting point - if they hire you as an employee or consultant and you get paid by them for working on your project, who owns the IP? I'd be very careful with that, because you don't want to be in a situation where you suddenly don't own a potentially major piece of work that's based on some work you created.

1) Funny

2) Agree it's a stupid thing to brag about. Reminds me of Theranos

3) Yes, that's the vibes i'm getting. But they'd like me to spend time on their project, not the open-source project

1) They all say that. You can safely ignore that. Guys like Fabrice Bellard found their own company and aren't for hire.

2) That should give you an idea what to negotiate in terms of compensation.

3) Well, in my experience, start-ups tend to be more intense than enterprise jobs. There are trade-offs. Prioritizing work over hobbies might be one of them. Your call.

This would be a red flag to me. It sounds like they’re building a culture of exclusivity and status rather than accomplishment.

For what it’s worth, I recently joined a startup (after leaving a FAANG) that just raised a Series B, and nobody at work talks like that.

I get reminded of Telegram and especially VK, which used to only hire coding competition winners

> 1) They said they only "hire the best" (i'm certainly great, but not the best)

So really what they're doing is stroking your ego. Does it feel good? Sure. But what matters most is the pay, not your ego.

Also if they're paying in stock options + dollars in order to avoid paying market rate, then you have to treat the options as worthless at least initially -- there's a high risk they won't pay out.

Besides, if you're really the best, you should earn above market rate in dollars plus a generous options package.

>In my head i’m thinking: “If their leetcode-engineers are that good why do they have rely on my open-source?”

>What would you do in this situation?

I would ask out loud “If your leetcode-engineers are that good why do you have rely on my open-source?”. Mind you I did that once when company I was contracting for wanted to hire me full time. They went with someone else with brilliant CV and ace whiteboard skills. They got in touch almost a year later asking for a rescue mission when nothing worked anymore, made more money contracting again than if I would work there full time.

How about you ask them for consulting gig instead?

Why would they accept my consulting gig though if they can hire someone to do it themselves?

It's hard to hire. If it were easy, they wouldn't be reaching out to you with bullshit job interview offers disguised as job offers.

You have (presumably) a pile of expertise in this particular area that they will have to painfully recreate. Including the experience of having built this thing once, and all the lessons from doing so.

As the project maintainer, you get a privileged stream of insights into how other companies are using the library / tool.

Even four more 1-2 hours interviews is asking a lot without the tech hazing.

If I had to guess they have a ridiculous process and someone else who only had the power to bump you through to consideration found your open source work. At the end of the day though it depends on how much you need the work.

You forgot to mention the most important detail: Do you actually want this job?

> Then they go on and explain i’d have to do 4 more meetings 1-2 hours each, including a leetcode-style tech interview

Even 4x2 hour interviews is still only 8 hours. Let’s call it 16 hours, worst case, to account for the disruption and setup time as well as small talk.

Even 16 hours is only equivalent to 2 days of this new job. If you’re going to be spending 200 days per year working side by side with these new people, you want to take advantage of this time to see how they work, how they interact with you, and how compatible you are with them.

Potentially unpopular opinion on HN, but I don’t see this as unreasonable. This job could last for a long time. The interview, even with four sessions, will not.

> In my head i’m thinking: “If their leetcode-engineers are that good why do they have rely on my open-source?”

Because no company should be writing things from scratch when viable open-source alternatives are available?

Honestly, your post suggests that maybe you don’t really respect this company, from their use of your library through the fact that they want you to go through the same interview process as other candidates (important for accurate hiring decisions as well as fairness). If you’re digging deep for excuses to dislike them already, maybe you aren’t a good fit for this job.

I thought the company contacted the developer to offer him a job based on his open source work, not that the developer applied to work at the company. If the company sought out the developer to offer a job and then demands 16 hours of jumping through hoops, then that seems both confused and inconsiderate.

If that actually is the case, I could see myself happily telling the company to not waste my time, but if they really have an offer, let's hear it.

> Even 16 hours is only equivalent to 2 days of this new job.

Except there is no guarantee you will get the job.

Assuming one will interview in 10's of companies, that's a lot of hours to waste.

> Honestly, your post suggests that maybe you don’t really respect this company, from their use of your library through the fact that they want you to go through the same interview process as other candidates (important for accurate hiring decisions as well as fairness). If you’re digging deep for excuses to dislike them already, maybe you aren’t a good fit for this job.

Please don't jump into conclusions about OP.

> Potentially unpopular opinion on HN, but I don’t see this as unreasonable.

It's unreasonable because they, 1) have the OP's open source project to assess his technical abilities, and 2) they approached the OP, not the other way around.

An interview process is (ideally) about team fit as much as technical prowess.

Technical ability is not the only requirement for most jobs.

Fair enough, but why the leetcode-style interview then?

Honestly I've never met anyone who really likes them, but people want to simulate a situation where you're working together to solve a technical challenge, and see how you work with others, how you clarify requirements, how you communicate progress and ideas, how you test your hypotheses.

Sometimes people really do just want to see if you've memorized Cracking the Coding Interview, and that sucks, but often it's more "can you work out a reasonable solution to this problem in a reasonable way, and tell me about it". We don't know the details here, but I'm guessing all this company said was "four interviews, and one of them will be a technical whiteboarding exercise". I believe you can still get a lot of insight out of a whiteboarding session even if you know for a fact the candidate can write good code.

There are other options, like "tell me about a challenge you've faced" or just talking through a particular project on the resume, but the interviewer might want to have actual code to talk about, because that's a particular set of problem solving and communication skills that another conversation might not get at. I think that's legitimate.

> Potentially unpopular opinion on HN, but I don’t see this as unreasonable

16 hours interview loops are very much not standard practice in the industry. And frankly 100M funding isn't nearly as strong bragging point as companies seem to believe. Established companies offering north of 400k in TC don't do 16 hour loops for SWE IC level, so if you're doing those sorts of long loops, you better have an unbelievably good offer ready (like an upgrade to director-of-technology level or something along those lines).

Put it this way: the best candidates are pretty much always employed, so if you're trying to get cute with interviewing practices, they will pass you by because you're not the only employer in town, and they know the market and they know what they're worth.

> Even 16 hours is only equivalent to 2 days of this new job

So, if you are reaching out to me, and want that much of my time to resolve your business question that I didn't cone to you for at all (whether its “should we hire you” or anything else), you should offer me at least ~1/125 of the job's annual compensation for my service.

The problem is finding two spare working days to fit the interviews in and the expectation that is a normal thing to ask to interview for one position. Unless you are some amazingly hot company I suspect this will filter out anyone that already has a job.

> If you’re going to be spending 200 days per year working side by side with these new people, you want to take advantage of this time to see how they work, how they interact with you, and how compatible you are with them.

Likewise, since the company will be spending so much money on you it's worth it for them to pay you $1,0000 for 8 hours or, worst case, $2,000 for 16 hours. After all, it can save them a lot of money in the long run from hiring a bad candidate.

As someone from outside tech, I think these demands are crazy. You only really get to know if someone is capable on the job. Not through some random tasks.

Why send a personal letter then?

That's how recruiting works.

Honestly, what else would you want them to do? Send an impersonal letter?

Make an offer

Yeah. If you start with “we want to offer you a job”, the next thing y better be a job offer.

Seems like a pretty standard interview panel to me - if you want the job do it, otherwise don't?

I, personally, draw lines about what I'm willing to put up with and what I'm not. When the interview process begins to resemble a gauntlet or even a hazing, I walk away. Why? Because they are showing that they don't respect the candidate's time and also they lack humility. They are unmindful of the possibility that the candidate could decide to go elsewhere.

Four more meetings at 1-2 hours each means between 4 and 8 more hours of interviews. That's definitely moving in to gauntlet territory. But maybe it's the result of an immature hiring process. I would give them a chance but if there are any more red flags, I would probably withdraw from the process.

Consider this a nice bit of validation of your work and maybe use it to renew your efforts in doing your own thing. The world needs more independent thinkers, but working for someone else might also be your jam.

Yes, i'm thinking about it right now

But i'm certain that i will keep doing open-source, regardless if i get hired or spin it off into a startup myself

Hiring in 2021 should be flexible. If they're not willing to be, then you have some different options. But since they went out of their way to contact you, you basically have the upper hand here.

See if they're willing to enter into a contract for 60-120 days. This is relatively low risk for the company, since a contract usually skews in favor of the company to terminate early.

Chances are they'll contract you and realize they can't live without you, so you'll be in a better negotiating position when negotiating a full-time salary.

> Then they go on and explain i’d have to do 4 more meetings 1-2 hours each, including a leetcode-style tech interview. In my head i’m thinking: “If their leetcode-engineers are that good why do they have rely on my open-source?”

Honestly leetcode is fraud detection at this point. I've seen "engineers" with good looking resumes who couldn't FizzBuzz. And a way to filter out huge red-flag (can't work with someone else).

I don't think it's very good for that. plenty of people that could trivially pass fizzbuzz would struggle to recognize whether dfs or dp is the best approach to some problem within ten minutes.

as I candidate I actually love leetcode problems. it's a clear evaluation target that I can prepare for as much as I want in my own time. if I can solve most lc mediums in thirty minutes, I can be confident I'll get at least one offer with good compensation.

I'm less clear on the value lc provides to the employer. the hardest problems actual engineers face are nailing down requirements and figuring out who/what to consult to unblock themselves. by the time you sit down to code a solution to a well-defined problem, most of the work is already done.

to put it in joel spolsky terms, lc tests for "smart", but doesn't provide any signal for "gets stuff done".

> would struggle to recognize whether dfs or dp is the best approach to some problem within ten minutes.

But they can write a solution even if it's not the most optimal one? And they know and can tell you multiple ways of solving a problem and discuss the tradeoffs? That's good enough for me.

> the hardest problems actual engineers face are nailing down requirements and figuring out who/what to consult to unblock themselves. by the time you sit down to code a solution to a well-defined problem, most of the work is already done. to put it in joel spolsky terms, lc tests for "smart", but doesn't provide any signal for "gets stuff done".

It's hard to evaluate that in an hour, and I'm not certain there's a correct way of doing it. A college degree from a good school where students are assigned non-trivial capstone projects would probably be a good predictor.

> What: engineering manager writes me e-mail that goes like: “we found your open-source project and want to offer you a job”

If you want to offer a job, offer a job.

They seem to have confused “job” with “hazing ritual after which you might be offered a job”, which is...less attractive.

I get the need to filter an excess of applicants who come to you cold or in response to an advertised opening, but if you are reaching out to someone, whatever motivated you to reach out ought to substitute for several layers of filtering. If you are reaching out for demonstrated, job-relevant coding acheivement, leetcode style exercises are not merely wasteful and insulting, but also a sign to the prospect that your management is mindlessly walking through checklists rather than thinking through their actions.

Do you want to work in an environment where that's how things are run? Especially a startup, which has instability and other issues that people accept to avoid that kind of bigco blind bureaucracy?

    Then they go on and explain i’d have to do 
    4 more meetings 1-2 hours each

Just went through a job search myself and found this exhausting, but extremely valuable.

1. Got to meet my potential teammates, get a feel for if I'd fit in and if I'd want to work with them

2. Got to ask questions of my potential teammates, without management around. Got to ask them about pain points of working at Company XYZ, etc.

That said, "4 interviews @ 1-2 hours each" seems excessive.

I found the typical process was more like "4 interviews @ 1 hour each."

I know 4 hours is a LOT of time, but this is potentially a job at which you'll be spending years. Approximately 2000+ working hours per year. In that context I think it's not crazy.

If you invite me in based on my work, I'm not jumping through hoops to prove myself to you.

All my commercial activities relevant to that open-source project i have done via handshakes, no interviews

You should say this to them. Say you dont think that type of interview is a a good use of time in this case and state your reasons. Then propose what you think would be reasonable, or what you would like.

Most people in business seem to do things just so they look the part, eg. they do whatever everyone else is doing. Cus, in reality they usually dont really know what they are doing.

If they want you, and you want to work there, and ye are both reasonable, then ye should be able to work something out. If one or more of those things are not true then you shouldnt work there anyway.

Skilled engineers are in demand and every possible route is being explored to source them. Given the interview process requirement this sounds like it isn’t as personal as implied and that they are interested in your engineering skills versus your project. You might not care about that and seethes as a way in to paid employment in which case go for it. If not then respond to ask for some time to talk to someone that is capable of discussing their interest in your specific project before committing any time to interviews or prep.

Ask for the comp range they're offering. If the money is fantastic then consider jumping through the silly hoops.

If it's just average then tell them that your open source project is proof of your technical abilities, you're happy to do culture / leadership conversations and answer code-review style questions about the technical design of your projects, but that otherwise you're not interested in passing an arbitrary leetcode bar.

I thought this as well. You probably have some number in mind where you'd walk over coals to get it, right? This is like that, except the barriers are tedious to endure rather than physically painful.

OTOH, if you get an offer and you feel queasy about things, you can have the all-too-rare-in-life privilege of asking impolite questions and maybe getting a real response, e.g., "The way you made me jump through all these hoops makes me think that the company culture might be rigid and dysfunctional. Is it?" And then see what happens!

Nice idea. I'm thinking of offering to complete a take-home project or go through some of my open-source work line-by-line

BUT, i have no idea if they're willing to agree or would just drop me after that altogether

Some company's interview pipelines are aggressively documented and standardized. The goal is that everyone gets at the level they're supposed to, backed with evidence for why that decision is made.

If you're completely breaking the process, it may harm that, leaving you either:

* as a Senior / Principal that isn't actually ready for that kind of work in their specific area and their specific software type

* as a level 1 or 2 that absolutely could be a Senior / Principal and now you're going to have to crawl through their ranks slowly.

If it were a large enterprise who's idea of innovation is to do whatever Facebook does, then yeah, you can't change their processes and will have to jump through the hoops to get the job. It's also a hint of how work at that corporation will be later on.

Otoh, at a start-up, I surely would expect people working there being able to think for themselves and given that they like your code, a leetcode interview does indeed seem absurd.

It's just one negative on the scales, so it depends on what there is to put on the positive side of the scale.

On the other hand, I have to admit that in my own experience, the longer and more convoluted the interview process the worse the job experience. But it's not an iron law.

I like the book Crucial Conversations. It would say to be 100% respectful and understanding of their interview process and 100% honest that you're concerned about the length of the interview process. Done well, this should cause no harm and may help you.

Tell them to fuck off.

Offering you a job is not making you spend hours doing stupid leetcode shit.

If you really want the job you can go through it. I would ask them about the LeetCode interview. They really shouldn't need it - they approached you based on your open source code... that speaks for itself.

Yeah, but I'm weird. I'm almost social phobic in real life but I learned how to destroy job interviews.

Share the secret with me?

I think most people make stupid mistakes in job interviews and thus interview below their level. If you fix that you practically interview way above your level.

I bought the course this guy was selling 15 years ago

https://job-interview-answers.com/

which changed my viewpoint. Also I am good at leetcode questions and highly educated and experienced. Even when I don't know the answer I manage to salvage the situation anyway (They asked me what "regularization" was in a data science interview, I had no idea, they told me, and then I told them all the ways I had done regularization.)

I say "there is no question in a data science interview that can't be answered by (1) look it up in the hashtable or (2) look it up in the literature." I can make that work for me, but I am not sure how to make it work for you.

Now if I could only pick up girls as well as I do job interviews...

    Even when I don't know the answer I manage to 
    salvage the situation anyway (They asked me what
    "regularization" was in a data science interview, 
    I had no idea, they told me, and then I told 
    them all the ways I had done regularization.)

Yeah I've found that interviewers are interested in your thought process, not rattling off canned quiz answers.

I do something similar whenever I'm unfamiliar with a term like that in an interview.

First, I never bullshit. I'm VERY upfront about not knowing a thing - but like you I say, "can you define that term for me -- perhaps I know it by another name" and more often than not, yeah, I can talk about how I've been doing it or something similar to it. And if not I get to have a discussion about the term and learn something, at least.

(Tangentially, being upfront about not knowing a thing gives you more authority when you state that you do know a thing...)

This field changes so quickly, I don't think any interviewer ever expects you to know more than a % of the topics broached, but they do expect you to be able to converse reasonably about all of them IMO.

Great, will check the course out

I don't think competing in answering questions anybody can learn is my skill or is a great skill to have. I'm a creative guy!

Wish you much luck with girls!

Some subjects (medicine) are all about memorization.

Leetcode is more like solving math problems; bad students are bad in a few different ways, a certain kind of bad student thinks it is about memorization -- maybe that is why they are bad.

It is a complex set of skills, aptitudes and knowledge to do that kind of programming. I think it partially relates to real work. Personally I did all the Python problems in HackerRank and I felt like it was a fun challenge where I learned a lot even though I was already experienced in Python.

Doing that kind of problem in a job interview is not the same as doing them online. You could be good at doing them online but choke at the whiteboard because of social pressure. You could also be bad at doing them online but lean on the other people heavily and still make a good impression. (e.g. you can really make people think you are smart by asking great questions.)

Confidence and bluster can get you a long way in those situations and you also can run into situations where the people interviewing you are just totally wrong about the problem and that involves both confidence and tact.

The primary route is "when in Rome do as the Romans do" so I play along rather than fight or fly. Maybe it is my bias because I'm good at that kind of thing (got a Physics PhD.)

Interesting how the pressure dates on that site work heh

document.getElementById('pressureDate').innerHTML = moment().add(1, 'days').format('dddd, MMMM Do');

Personally, I reject all companies that want to do more than one round.

Just tell them no you ain't interested in their interview charade. No is a powerful word.

>Who: Series B startup with ~$100 million in funding, me open-source developer

That $100 million isnt in your pocket. This isn't 100% reliable source of income. It might seem like alot but it's not established yet.

>In a meeting they explain how they were interested in using my open-source project and want to hire me so i could carry out a similar work for them

Sweet, i assume they want to use your code. Might try to be tricky and get you to sign your code away. Then fire you and keep the code base.

>Then they go on and explain i’d have to do 4 more meetings 1-2 hours each, including a leetcode-style tech interview

Kind of a red flag in my books. If they are coming to you, then it's the reverse. Like they should be offering you equity or something. I dunno. They need to win you over and bureaucracy isn't how to do that.

> Might try to be tricky and get you to sign your code away

My code is GPL, lol

>My code is GPL, lol

Like I dont know either way what's going on. There's tons of examples where an employer has you sign your rights away, then removes the GPL license and then starts publishing the code as proprietary.

Reply on news.ycombinator.com