Ask HN: Ridiculous job interview. What do I do?
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?
108 comments
[ 3.1 ms ] story [ 176 ms ] thread> 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
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.
A good manager will isolate an asshole from the rest of the team, but still capture the value they produce.
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...
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!
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.)
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.
document.getElementById('pressureDate').innerHTML = moment().add(1, 'days').format('dddd, MMMM Do');
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.
BUT, i have no idea if they're willing to agree or would just drop me after that altogether
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.
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!
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.
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 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.
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.
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.
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.
* 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.
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.
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.
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.
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.
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.
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.
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".
But i'm certain that i will keep doing open-source, regardless if i get hired or spin it off into a startup myself
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"
Edit: For clarity these to me mark them out as being extremely naive about their own value.
Good thing is, i don't care about money as much as they do!
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.
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.
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.
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
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.
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?"
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
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.
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.
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.
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.
Do you have an idea how i can bring it up in a polite manner?
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.
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.
> 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.
Honestly, what else would you want them to do? Send an impersonal letter?
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.
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.
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.
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.
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.
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.
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.
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'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.
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?
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).
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".
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.
Offering you a job is not making you spend hours doing stupid leetcode shit.
>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?
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.
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.
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.
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.