Hacker News new | past | comments | ask | show | jobs | submit login
It doesn't take much public creativity to stand out as a job candidate (simonwillison.net)
386 points by simonw on July 22, 2021 | hide | past | favorite | 374 comments



In my experience, for a pure engineering role, nobody seems to care. I had credits at large companies, posted talks online (interviewers rarely looked at them), but if I forgot how to write binary search in 10 minutes in an interview it didn’t matter.

This actually made me realize being just an IC wasn’t actually my goal though. Once I started interviewing for management and sales, all of those things _really_ mattered. Now that I’m running workshops and talks professionally, posting publicly is _critical_.

Moral of the story: if you enjoy posting in public and teaching in public, but you feel like its getting you nowhere career wise, maybe you are in the wrong career like I was. Once I decided to double down on my strengths and spent nights and weekends at public speaking training instead of grinding leetcode things started to click.


Yep. I've had a portfolio of full video games I've coded and released on my own, as the sole programmer, that could be played on the web, had my name credited on the title screen, and you could even see the code on some of them, and I proudly included the link on my resume.

Never brought up during the interview process, I was still expected to take the coding tests, and if I did a little poorly on one question I almost always got passed, even though the games I made had plenty of things going on, and some were even finalists in game contests (one hosted by Microsoft, even).

I don't bother keeping up a portfolio anymore (I am working on a new personal site again, but not to put on my resume).


I've made lots (thousands? hundreds at least) of commits to the Linux kernel and have been working on it since pre (git) history, have developed a number of novel concurrent data structures / algorithms for it.

I decided to talk with a FANG recruiter a couple of years ago who must have scraped my name from mailing list or commit histories. Despite first making it clear by email I wasn't interested in a job interview at the moment but was just curious about some things, on the call they pretty soon demanded to know what I thought the best Big O notation was for a sort algorithm. They were rather insistent that I answer them this before they would move on and spend much more of their time explaining why they contacted me or answering my questions. Fortunately I hadn't wasted a lot of my time at that point either.

Strange, rude, entitled behavior. Sadly, they probably do hold real power over graduates and new developers, and those without jobs or much experience, or just those who dearly want to work for these companies. So they can get away with treating people like this, putting out these drag nets, paying no real interest or respect to any individual (at least not until they think their canned questions have filtered out most of the useless scum).


A couple of years back I managed to have three job offers at the same time - all of which I turned down. One recruiter got really angry with me, one basically disappeared the moment they heard I wasn't immediately accepting their offer and the third had a sensible and mature conversation about it.

Guess which one gave me a good impression of their company and who I might work with again?


I'm curious why you put in the effort to apply to several places and passed up on all the offers.


They approached me, I had interviews with each one thought about it and and on reflection once I found out more about each company and the roles decided I was better off staying where I was at the time. At the time the company I was working for had some commercial trouble (not related to me) so I thought it was wise to be informed about what opportunities were available but I wasn't desperate.

Since moved somewhere else and am very happy with my new role.


For what it's worth I spent the last few days wfh-ing with a close family friend who happens to be a manager at a FANG company. Those few days convinced me to not wanting to work at a FANG company (or at any big company, for that matter) unless there's no other way to pay the bills and buy food for out two pets, it seemed like almost everything at that company was based on politics and how to sell yourself as a programmer (or IC-er, or whatever the correct term is) or as a manager, almost no talk about the product itself.


To play devil's advocate, having a standardized process for all candidates has some benefits. I've witnessed otherwise stellar candidates with amazing open source contributions absolutely bomb coding interviews. Real "write a function that does X" in whatever language you're comfortable with and whatever tools or resources you want. Simple stuff.

So yeah maybe the Big O stuff is lame, but sometimes it's also a filter for entitlement on the behalf of the candidate. Hiring isn't hard, but it's not easy.


> To play devil's advocate, having a standardized process for all candidates has some benefits. I've witnessed otherwise stellar candidates with amazing open source contributions absolutely bomb coding interviews. Real "write a function that does X" in whatever language you're comfortable with and whatever tools or resources you want. Simple stuff.

I'm not sure if you're playing devil's advocate very well here, because this suggests to me that the interview process did not work well. Do you want to hire someone who can write a binary tree insertion in 30 minutes, or someone who can make amazing contributions to real software projects?

> So yeah maybe the Big O stuff is lame, but sometimes it's also a filter for entitlement on the behalf of the candidate. Hiring isn't hard, but it's not easy.

My point wasn't that hiring is easy or even that programming quizzes do not have a part in interviews. It is the level of contempt that some of these companies and their recruiters and hiring processes show to people.

To be fair I did open myself up to it having responded to an unsolicited message, but I always try to politely decline if I get a message from a real person. They responded with something interesting and hooked me to agree to a call. I made it clear I was not interviewing for any position, and again while on the actual call I declined the Big O question. It just shows they were perfectly happy to send out probably mass spams and waste people's time, but were not willing to even read what I wrote or listen to me, or worse they did and decided they'd just ignore what I said anyway.

My point is treating people like people, not like bycatch in your drag net. Simple stuff.


> I'm not sure if you're playing devil's advocate very well here, because this suggests to me that the interview process did not work well. Do you want to hire someone who can write a binary tree insertion in 30 minutes, or someone who can make amazing contributions to real software projects?

Most companies want malleable, fungible engineers. Most companies are not stable, something is usually in flux -- projects, teams, organizations, business models. Most managers would rather have someone who can write a binary tree insertion in 30 minutes.

But that is not how I personally hire, it's just reality. I'd rather have someone I can work with. In my experience, a lot of big open source contributors are not good colleagues. Are they going to focus on their job or spend their hours in the office working on their passion? Are they going to put their head down and get the work done or write essays debating in a mailing list? If we can't even have a conversation about algorithm complexity then there are better ways I can spend my time.

> It is the level of contempt that some of these companies and their recruiters and hiring processes show to people.

I really don't think this is true contempt, at least not usually. Recruiters, for better or for worse, vary widely. They are rarely good representations of the rest of the business. They're usually just sharks. A good recruiter is worth their weight in gold. But mostly they're ignorant, greedy, and have no care for you or the company you're interviewing for.

> It just shows they were perfectly happy to send out probably mass spams and waste people's time, but were not willing to even read what I wrote or listen to me, or worse they did and decided they'd just ignore what I said anyway.

Look, I'll be honest. I've conducted nearly a thousand interviews. I've hired at FAANGs, unicorns, YC companies. I almost never look at a candidate's resume/CV. If I'm not doing a coding interview and I want you to go into detail about something you worked on, I might take a glance. But otherwise, I actually do not care. I don't have time to peruse your GitHub profile or past projects. I don't even have time. One in a hundred applicants even get interviews, and I'm often interviewing 2-3 times a week. If it's important to you, tell me about it! I'd rather talk to you than read about you! In my experience, the resume/CV/published work is not a strong signal for making a good hire. It sounds like it's already helped you get your foot in the door, I wouldn't recommend expecting it to do anything more.

I'm sorry you had a shitty experience with this company, but I encourage you to be humble and give them the benefit of the doubt. Unless they're a tiny, boutique company with a lifestyle or OSS-focused culture, they are busy people. If they don't ask these questions, then more often than not, by the time we're in a room or on a call together it's a waste of both our time.


> I'd rather have someone I can work with.

> I almost never look at a candidate's resume/CV. > I don't have time to peruse your GitHub profile or past projects. I don't even have time.

So you want someone you can work with, but you don't want to spend a couple of seconds to look at who you're talking to. Which is, you know, sort of the most basic of things necessary to get an actual relationship started.

This goes both ways. If you don't even want to spend a few minutes to assess whether the resume or the projects are interesting to you, then why on earth would the candidate spare you any time or energy?


These engineers are not hired to invert binary trees.

They're hired to change glorified forms. If they need to invert a binary tree, they will google it in 30s.

My friend (40+) prepared for a couple of months and got hired at FB a few months ago after a career spent in smaller companies. Great comp, mindlessly boring job (the usual, change this form button, change this endpoint) but hey, now that FANGs are remote and you don't need to commute to an office, they're worth a shot. He's already thinking of quitting but unfortunately he already forgot the algorithms exercises and he doesn't want to do the same interview dance again at Google with the hope that things will be better over there.

Whenever I've been in the hiring manager roles, I skimmed over people not knowing theory well and I read with interest their CVs and their personal project (and asked them about it!). Your behaviour is exactly why I didn't want to work for a FANG and I pursued starting a business instead of growing my career as a IC.


I apologize for the "one-liner". I am busy, I interview and hire many people, and I read resumes. You can do it too, it is one page and it is often interesting, including the lies here and there that disqualify candidates.


I'd say I'm in a qualitatively similar position as you. If I'm going to interact with a candidate in any capacity, I always spend at least 30 seconds to skim their resume if I have the means to.

When I'm acting as a hiring manager for a role, I read through applicant's materials in detail before deciding whether to advance them in the process. It's at least 50% of my work time, and my technical work suffers. I communicate that to the relevant managers and stake holders, and they can help decide whether it's the best use of my time.

I also regularly receive followup emails from rejected candidates saying that they thought the interview was the most fair and thorough of anywhere they applied, they understood why they didn't get the job, and in the process they learned where they need to focus on to be a better fit for the same type of role in the future.


> When I'm acting as a hiring manager for a role

Yes, I'm not usually in this role. I don't find managers conducting technical interviews a good use of time, they are better spent on soft skills -- discussing previous projects, career goals, assessing team fit, answering questions about company culture/comp/perks/etc.

> I read through applicant's materials in detail before deciding whether to advance them in the process.

I don't usually filter candidates in this way. Recruiters send us candidates that are eligible for a phone/video screen, i.e. do they meet the hiring criteria. This is where the resume/materials are looked at. The resume is also useful to figure out where to funnel inbound candidates -- are they backend engineers, frontend, etc. It depends on the hiring pipeline.

In any case, from a purely technical evaluation perspective, the resume is inconsequential. Where did you go to school? How many jobs have you had? What awards have you won? Literally none of this matters and is utterly meaningless when it comes to your ability to do work with me and my colleagues. Resumes are ripe with bias-footguns that I try very hard to avoid -- cronyism, elite education, privilege, wealth, immigrant status, etc.

In my experience, and the experience of the majority of my employers and colleagues, it's more fair to evaluate without this information. The red flags and strong positive/negative signals are elsewhere. The resume is almost entirely useless.

> It's at least 50% of my work time, and my technical work suffers.

I would suggest closer partnership with your recruiting team and trying to communicate what you are looking for more succinctly to them so that they can deliver you a stack of candidates worth talking to. If you are at a remotely large company (>1000 employees) then unless you are bootstrapping a new team/org/whatever you shouldn't be spending this much time hiring. Your team is going to suffer.

> I also regularly receive followup emails from rejected candidates saying that they thought the interview was the most fair and thorough of anywhere they applied, they understood why they didn't get the job, and in the process they learned where they need to focus on to be a better fit for the same type of role in the future.

To be honest, we get the same feedback. Most candidates tell me that it's the best process they've ever experienced.


Each organization is going to do things differently obviously. To clarify, a hiring manager within my context is the person that's responsible for the process of hiring for a specific role. We almost always have individual technical contributors act as hiring managers. They set the technical bar, design interview plans, and act as a consistent point of contact for the candidate. Team managers are distinct from that, although they may be the ones pushing to hire to fill a role for their team.

In my experience, relying on recruiters to filter out candidates into a "high quality" pile isn't effective. That's where the resume bias tends to slip in.

Individual contributors spending time recruiting is also organization specific. I'm probably considered the highest value software engineer on my team. Part of that is because I actively work to make sure I'm replaceable. Most projects I've worked on are documented and tested enough that other engineers can step in and take over as needed. I also often turn down fun projects in favor of mentoring more junior coworkers to do them. On the hiring side, we maintain a high bar and hire for long term success. As a result, I trust everyone on the team to keep the ship on course.


> To clarify, a hiring manager within my context is the person that's responsible for the process of hiring for a specific role. > ... > Team managers are distinct from that, although they may be the ones pushing to hire to fill a role for their team.

I haven't encountered this before.

> In my experience, relying on recruiters to filter out candidates into a "high quality" pile isn't effective. That's where the resume bias tends to slip in.

I agree but I haven't seen anywhere (large companies) where this doesn't happen. There's always some intermediary filter before the resumes end up in the hands of technical staff.

I can't imagine why having recruiters involved prevents any of the other things you mention. ICs can design interview loops, help write job postings, work with recruiters to define and clarify what they are looking for.

Regarding your last paragraph, that sounds like the basic bar for most senior/staff engineer positions I've encountered. You're a force multiplier for others. That's the job.


> One in a hundred applicants even get interviews

If you don’t bother to read the CV, who do you even pick to interview? Randomly?


Of course. You wouldn’t want an unlucky candidate.


My apologies to the HN Gods for this low quality comment. But that struck me as extremely funny.

On a serious dystopian note, luck really does play the dominant role in everything.


All jokes aside, in my experience it's nearly a FIFO, with obviously unqualified candidates being weeded out. If you have 3-400 people apply for a position, you maybe phone screen somewhere from 4-10 and by the time you're closer to 10 you've already conducted 3-4 onsites and put out at least one offer.


> Most companies want malleable, fungible engineers. Most companies are not stable, something is usually in flux -- projects, teams, organizations, business models. Most managers would rather have someone who can write a binary tree insertion in 30 minutes.

Okay well that's a bit surprising.

> But that is not how I personally hire, it's just reality. I'd rather have someone I can work with. In my experience, a lot of big open source contributors are not good colleagues. Are they going to focus on their job or spend their hours in the office working on their passion? Are they going to put their head down and get the work done or write essays debating in a mailing list?

Interesting point that I hadn't really considered because I get paid to do what I want with Linux. That said, I'm not here to argue that open source developers are wonderful or this recruiter should have known who I was or been kissing my feet.

> If we can't even have a conversation about algorithm complexity then there are better ways I can spend my time.

You can in the right setting. I happen to think some companies probably take these to absurd levels that can't be a particularly good filter. But they have millions of applicants and have to filter somehow, so as long as they're up front about the process and treat applicants respectfully as you would any other human, they can do what they like. That's not what I'm complaining about either.

> I really don't think this is true contempt, at least not usually. Recruiters, for better or for worse, vary widely. They are rarely good representations of the rest of the business. They're usually just sharks. A good recruiter is worth their weight in gold. But mostly they're ignorant, greedy, and have no care for you or the company you're interviewing for.

The recruiter was not overtly rude and I'm sure they weren't intending to be contemptuous. I'm guessing the the practices and behaviors are so normalized that they might not even recognize there is any problem. So it's the industry as a whole which has some serious problems I think.

> Look, I'll be honest. I've conducted nearly a thousand interviews. I've hired at FAANGs, unicorns, YC companies. I almost never look at a candidate's resume/CV. If I'm not doing a coding interview and I want you to go into detail about something you worked on, I might take a glance. But otherwise, I actually do not care. I don't have time to peruse your GitHub profile or past projects. I don't even have time. One in a hundred applicants even get interviews, and I'm often interviewing 2-3 times a week. If it's important to you, tell me about it! I'd rather talk to you than read about you! In my experience, the resume/CV/published work is not a strong signal for making a good hire. It sounds like it's already helped you get your foot in the door, I wouldn't recommend expecting it to do anything more.

You don't even read the resumes of the 2-3 people per week you decide to interview? The resume is what the applicant wants to tell you about themselves. If I apply for a job, I would be sure to read the position description and read up a bit about the company, their work and people.

But so long as you're honest and respectful of people, and don't think that your time is more valuable than theirs, each to their own. If you tell them not to spend any effort updating their resume because you prefer to cover it in the interview for example, I don't have a problem with not reading them if that's not how you like to do things. Honesty and respect is all I ask.

> I'm sorry you had a shitty experience with this company, but I encourage you to be humble and give them the benefit of the doubt. Unless they're a tiny, boutique company with a lifestyle or OSS-focused culture, they are busy people. If they don't ask these questions, then more often than not, by the time we're in a room or on a call together it's a waste of both our time.

It wasn't a huge ordeal for me that I'm bitter about. I was just flabbergasted that they thought nothing of taking an hour or so of my time without spending 2 minutes to read my email. They were willing to say anything to try hook me and get me into some process. It's not the right way to treat people even if it is a buyer's market, not even if they're a new graduate or have poor credentials.


> You don't even read the resumes of the 2-3 people per week you decide to interview? The resume is what the applicant wants to tell you about themselves. If I apply for a job, I would be sure to read the position description and read up a bit about the company, their work and people.

There's more here to unpack than I have time to so I'll be brief. The recruiter should screen your resume/background. If you're already being asked questions on a call or whatever then the resume has already done its job, in my opinion. I haven't used a resume in the last several jobs I've had, since I just connect through a former colleague and get fast tracked to a phone screen.

Consider the power dynamics in applying for a job. Ideally you, as a candidate, want to exit with a mutually beneficial arrangement. Initially, the employer holds all the cards. You are relatively powerless. Consider if a resume holds information that helps a company hire fairly and hire well. (Beyond "do you work in this field" it does not, in my opinion.)

You have to be a fit for them. Unless it's a two person startup, you're not going to change the company to meet your culture. You are the item being filtered for.


I don't like to go here because I know very little about your methods from our discussion, I've easily misunderstood some things you've said, etc. and I'm certainly not talking about you as a person, you've obviously been completely polite and respectful of me and others here. (And the same goes for the recruiter in my story -- I'm sure he was not a horrible person either).

And I don't want to throw out something you can't reasonably defend yourself against. So I'm talking entirely about my (surely incomplete and flawed) impression of what you've told me of your profession here. It comes across as being consistent with what workers dislike about the industry.

Not reading people's resumes before you have them interview, preferring those who don't have obvious hobbies in the hope they will do more work, justifying this by talking about power dynamics and the applicant being powerless, they are "items" being filtered for, the love it or shove it attitude.

So I'm sure outside the profession you don't think of people as numbers, and even in the profession you're having a side bar with me and my summary of impressions is probably uncharitable taken out of context. It could be that you are an unwitting or unwilling participant in the normalization of deviance in the HR industry regarding how to treat people -- this is just how things are done.

And in what you say there are some kernels of difficult truth, for some companies and some applicants / employees. But it's not entirely and always true either.

Firstly, no matter the power dynamics, people should be treated with politeness and respect. And personally I'm sure you do, but professionally I don't know that your industry does or necessarily even understands what that means.

Secondly, that assertion about the power dynamic is not always true. I mean, if a company advertises an open position, then it's a signal that they want to buy (at least where I am I believe it's illegal to advertise for a position you have no intention of filling). So all else being equal, they're starting at a disadvantage right out of the gate if you make an adversarial analysis of it.

It's true that FAANG companies have a power dynamic over 99.9% of their applicants because they have a huge oversupply. But for some fraction of that top 0.1% it is the opposite. They get head-hunted and fought over. Presumably the top talent in recruitment process are those who can find and sway and hire these people when the balance of power is not on their side.

And down from FAANG and the top few companies in other industries, a lot of the time companies actually have much bigger problems attracting people.

So the power dynamic can certainly fall the other way in any given hiring, as it was in my story. And the guy clearly didn't know how to cope with that. And I think that is also a symptom of this industry problem.

I had the upper hand there. I was filtering him. Despite that, I was not rude, I was honest, didn't mislead him, I explained my position. And I read everything he wrote. It cost me very little to be polite and respectful.


So they are stellar candidates with amazing contributions. Yet they can't do your whiteboard questions.

So, are you trying to hire someone who will make stellar contributions to your codebase or are you looking for candidates who are good at answering dumb questions?


I don't typically whiteboard. I'll write the prompt on the whiteboard, but otherwise it's a tool. The candidate has a computer, either their own or we provide one, with whatever tools they requested or want to use.

Yes, plenty of candidates with otherwise amazing track records can't code comically simple functions (not dumb questions) together, with tons of help and hints and direction provided. They can't articulate their thought process, can't describe what they're doing, can't ask for help or get combative or aggressive or entitled.

The question is entirely not the point. It's everything else that is signal. Could I work with this person? Could I give them a task and have confidence?


Think about what your interview process would look like if it was a normal day at work.

You show up out of the blue with a task that isn't connected to anything the org does and with all the decisions made already. I cannot search the internet, but you do not explain why. You sit down across from me and stare.


You're describing something else.

In my interviews you can use the internet. I don't stare, I'm mostly taking notes and answering questions, either listening to the candidate explain things or explaining things. No decisions have been made. I describe a problem, we solve it together. Just like we might on the job.


I can't do something as simple as empty my bladder while someone is watching. I certainly can't code something complex with someone watching me. Luckily, I have never had a coding job where I had to be watched while working.


plenty of candidates with otherwise amazing track records can't code comically simple functions

Sadly, this rings true. In a non-whiteboarding context I’ve sometimes asked JS/TS candidates something that I originally though was a nice easy, practical sort of algorithm question: how would you find the intersection of two string[] arrays? Even with plenty of hints probably the majority don’t get beyond a nested loop (sometimes they progress to [].filter and [].includes, which just hides it).


It filters out those who know how to structure code, but don't know how to write it. Stack overflow copy and paste can still create public projects.


It also filters out people who get anxious in interview situations, since anxiety tends to put people in fight or flight mode and shut down the critical thinking parts of the brain.


Sound like it filters out all types of weaknesses, which makes it a good thing when you have a large pool of candidates to filter through.


Why don't we also add a basketball free throw component so we can filter out those that have bad hand eye coordination?


umm... because manholes are round, and about 500,000 golf balls.


I wouldn't necessarily blame the recruiter for that particular one, since I'd guess the question was on a form that the org or manager required them to fill out.

The recruiter might've been especially metrics-driven, though. And maybe they were playing to metrics in a way that the org/manager didn't intend.

Or maybe the org/manager did intend your experience, and it was behavioral screen, for candidates who'll submit to whatever the emergent behavior of a corporate behemoth ends up doing to them. :)


Getting frustrated by that after graduation I decided to work as contractor instead of "getting a job".


I am similar (putting my WebGL games on my portfolio) and I've found it's actually a pretty good filter of employers for me. If they bring it up and are willing to have a discussion about it, it's always a good sign. There's a wide range of topics to talk about that can relate to the possibly more boring requirements of the job.

If they are dismissive of them, it tends to be an early sign that they are unable to think of things in a broader or alternate context. These are also the interviews that tend to have questions with right or wrong answers, even if the questions have multiple solutions and warrant discussion.


If you are over qualified, like having published several games on your own, it's not like they don't think you can do they job, they might think you will get bored and miserable.


I've personally come across this dilemma when hiring people. My own take is that's none of my goddamn business and if the person is the most qualified for the job then it's theirs for the taking.


Or you could perhaps discuss your concerns with the candidate... They may have a good reason for applying to this specific job.


"I want to work here because I need money to eat and you seemed like a safe choice"


Some day I'm actually going to try this in an interview.

Interviewer: "Why do you want to work for us?"

Me: "Honestly, I don't want to work for anybody because I have too much other stuff I'd much rather be doing with my time. But I need an income to sustain myself so, if I'm going to work, I want to work here because I think it'll be easy, provide decent benefits, and it's a 20 minute bike ride from my house."


If I were in charge of hiring (I'm not), I very well might hire you for that :)


That might very well be why you aren't in charge of hiring.


It might be worth trying when you are already have another solid job in the background :) It could be that you've hit the one company that appreciates honesty, but generally I think most don't love it.


Valid enough reason if you ask me.


I don't think is optimal, either. It's not worth investing in onboarding someone, getting them situated in a team, then having to tell everyone a few months in that the person quit. If that seems like a very likely outcome, it makes sense to avoid it.


My experience is the most impressive people are significantly less likely to quit early. If they where doing a lot of interesting things in their free time they either become engaged with interesting projects at work or put in a solid work week and then go home to have fun with their own projects.

Albert Einstein for example worked for several years as a patent examiner while developing special relativity. Sure his contemporary physicists mostly worked in academia, but teaching is as unrelated to research as everything else yet they still did it.


Sometimes having a light day job gives you more energy for your personal projects you care a lot more about at night :)


Do people really pass on candidates that often because they're too impressive? Overqualification in general seems like the kind of spectre that I just can't see translating to the real world.


Not an automatic rejection, but it certainly requires a conversation. I recently had to go back to a candidate to triple check that she really, really was fine not leading a team anymore, with no timetable on when that might happen again. After a few days, she withdrew. We were bummed, because she was great, but we had suspected it wasn't really what she was looking for.


Sometimes that's the case, though. I've led teams before, and I don't mind going back to just head down focused on code again. Leading people tends to be more lucrative but also dulls the coding blade.


Certainly, people's preferences change, their lives change, etc. Nothing wrong with that, just have to make sure all parties are aligned.

And yes, my blade is quite dull at this point!


Are people really passed on for being over-qualified? Or is it a polite way of declining some applications? Or maybe even a little of both?


I was passed on because I was overqualified for a position. I'm thankful for that because I found a much better fitting position a few months later.


Maybe the candidate just wants a nice quiet easy job so they can reduce their stress and put their focus on other parts of their life?


That's EXACTLY the reason I'm in my current job. I got asked several times whether I want to be a team leader, product owner or even assistant VP of engineering, and if I'm sure I only want to be a programmer.

And I said to the director of engineering who recruited me, more or less this:

"I can do all those and be rather good at them, too. But right now I want to focus on my physical and mental health so I want to work as a senior programmer with minimum supervision who takes ownership of big features or refactorings, and to be knee-deep in the code. All other soft skills that I have I only want to utilize to become the best colleague that you have."

My honesty was highly appreciated and I got an immediate job offer. I like the job. It's relatively chill, the colleagues are nice, the challenges are doable, and there's almost no pressure. I am mostly okay working for the company.

So long story short, I completely agree with you: sometimes you need a chill job so you can focus more on your life.


That would be a perfectly fine reason! Ideally this comes out in the interview process, for example if the candidate is asked why they're leaving their previous role and says that work/life balance was an issue. As long as their needs match what you're offering, great.

The thorniest situation is the overqualified, currently unemployed candidate. That person is often not trying to make a lifestyle change, but instead looking to pick up a paycheck for a few months until something better comes along (for good reason!).


Making games doesn't mean they're financially successful or making bank. Several of those I made were released as free Flash games back in the day, for example. And yet even those were more popular than some games I worked on professionally for companies while in the industry.

So now I do enterprise development for my day job and work on games on nights and weekends. And enterprise development isn't inherently boring either.

Programming is still programming, in both games and enterprise software there are times where you just need to power through easy boilerplate with some music or a podcast on, and other times where it's an intricate puzzle you have to mull over in silence, do some research or experimenting on, ask your colleagues for their opinions or insight, etc.


Being a good engineer goes beyond being good at coding.

Many great coders suck at communication or are just not nice to be around.

I've seen amazing "coders" not being hired because they can't have a good conversation during the interview. I'm sure they're the same ones that complain about interviews being too hard.


>I'm sure they're the same ones that complain about interviews being too hard

It was a fine and relevant comment until that part ._.


Haha I shouldn't have included it, it was petty.


> it's actually a pretty good filter of employers for me

Reminds me of the story of the movie Good Will Hunting - Ben Affleck and Matt Damon added a completely out of place scene (a gay sex scene) in the middle of the screenplay just to see who would call it out, as a way of checking to see who had actually read the entire script.


I've worked in gamedeve since 2007 and interviewed a lot of people. Small games portfolio doesn't matter, because small games, just like beginner tutorials from Unity, don't teach you skills necessary to work on a large-scale project with multiple developers. When you're working on small-scale projects, you can follow bad practices and don't hit their limitations.

However, if I would be interviewing a game designer and not an engineer, this portfolio would have been incredibly relevant.


Sure, but neither do binary searches and balancing trees. If writing a 10000 line game is not like working on a million line project, writing a 100 line algorithm is even less so. And yet, some recruiters value coding tests more.

In fact, practices in competitive coding are almost the opposite of what you need in large projects. You need to get a result as fast as possible, and the code is thrown away in the end. Readability, robustness, reusability, none of these matter, descriptive names are a waste of time, so is freeing up resources. Competitive coders are usually good coders in general, simply because they care, but so are people with side projects.


Does this also apply to junior roles? I would expect a portfolio of small games or some tech demos is the best you could expect there.


No, small side projects will definitely help you stand out when you're applying for a junior position since you don't have a lot of experience yet.


Maybe you should have applied with smaller companies that don’t have bureaucratic hiring processes yet?


Happens at smaller companies too. I just finished a round of job interviews, and interviewed at several smaller companies that didn't give a shit, they had their own pet processes for hiring and didn't care about anything I did beyond the most recent two jobs.

At one of them the guy was the epitome of what I would call "friendly condescending", spending half the interview pontificating on why the vast majority of developers don't understand what they're doing and should spend all their free time having a deep philosophical understanding of their work and suggesting I might be amongst those idiots (I'm really not doing a great job of selling it, he went on and on elaborating all the ways in which all developers but him were lacking and how he couldn't find anyone worthy of working at the company), but with a smile on his face the entire time. To be fair he did call himself "the asshole at the company" during the interview, though.

The two job offers I got were from larger companies, but I talked to some younger guys working there that liked video games and sci-fi novels and going to a summer camp hosted by a popular 80s/90s band and DSLR photography, etc. and being able to talk about those things even a little bit may have helped them get excited about me, actually :) Also helped I did well on their coding tests, though.


Most small companies copy the bureaucratic hiring processes of the larger ones at this point.


I'll never understand why business owners want to fail so badly. The principal advantage of small business is that you can happily ignore bureaucracy when it makes sense to.

Some of our best employees are the ones who came in with the fewest credentials and the most to prove. There is no candidate I would refuse purely on the grounds of credentials.

We are much more interested in side projects and work ethic than formal certifications or other pieces of expensive paper.


>I'll never understand why business owners want to fail so badly. The principal advantage of small business is that you can happily ignore bureaucracy when it makes sense to.

But how are you meant to know "when it makes sense to"? I imagine that lots of small businesses are run by owners who don't necessarily have the confidence to strike a new path in every facet of the business. If you're investing a lot of time and effort innovating on your product/service, it can also make sense to import a tried-and-tested hiring model wholesale from somewhere else.

Of course, in a less generous sense that could be maligned as "cargo-culting", but if at the end of the day the planes show up (you make good-enough hires), you're not going waste time introspecting on the process.


One of the most common modern hiring "bureaucracy" I saw being applied in small companies/startup is the rule that candidates must be selected by their peers. There are many reasons this policy is appealing. One is that there is a growing recognition that managers aren't meant the be too technical and gauging the technical skills is thus delegated to those people who actually know the tech (namely the devs). The other reason is that it's assumed that in order for a team to work well together you need people who like and respect each other, and this often means answering the question "would you like to work with this person?".

This policy backfires in many ways. It entrenches the existing culture and often doesn't easily allow to raise the seniority level of an existing company. I've been in many interview where only junior members where perplexed about some minor shortcomings about the candidate but they were the majority and the general sentiment was that if the devs noticed a red flag, it must be because manager and senior staff focused too much on high level stuff that was easy to fake, but luckily the juniors caught the impostor!...

I was looking in dismay how one good candidate after another got rejected. Fixing this kind of problem took a tremendous amount of effort.


Usually they copy them wrong and dont know why its not working


I’ve interviewed a lot of candidates and I make it a point to review their portfolio. It helps me target my interview to focus on subjects they’re familiar with. Your portfolio should be on your resume. Videos are a great way to show off your game.


For a pure engineering role things like credits at large companies, online talks, side projects, etc. are all really great ways to get an interview.

I can't really remember the last time I was turned down for an interview.

You're totally right about the other part though. I've lost a lot of jobs I think I could have been great at because I'm really bad at whiteboard coding interviews.


Does this mean that the whiteboard coding interviews are flawed, or that guys like us, who has made a ton of more or less great projects are flawed? Why would a company rather have a guy that can solve binary search in five seconds, than one that has showed continuous progress with several finished projects over the years? Do they think accomplished guys somehow are a liability? Or is it that they want a blank sheet imp that they can mould wholly in their own image? Is real creativity and output really of no value to these guys?


The book Disciplined Minds goes into some of this. It helps one understand the answers to questions like why companies prize things like performance on coding tests that don’t correlate very well to the job. Even FANGs are not looking for truly innovative engineers. Most of the innovation comes via acquisitions or when they hire some industry luminaries to lead projects. The rest are only there to fill in the lines and be highly productive coding machines that will learn the “syllabus” just like they learn to leet code.

These deep technical skills don’t matter as much because a lot these highly paying companies don’t have work that is deeply technical. Their challenges are primarily around management and scaling the number of engineers.

This requires reducing people down to something very simple and being able to treat engineers as fungible resources. Hiring and evaluating each person as a special snow flake is not the most profitable thing to do at large scales.

This is exactly the thesis behind Paul Graham’s ideas on startups and innovation. The scaling of a large corporation inevitably jams up the gears of the system and a small team can completely outflank a large company with employees keeping more of the returns and the work being more fulfilling.

Unfortunately the incumbents have sucked in most of the revenue so even though you regularly have small teams of people knocking out work that puts the biggies to shame making money is hard to impossible. So everyone on “Hacker news” is now left reverse engineering every detail of how big co works to get ahead .


> Even FANGs are not looking for truly innovative engineers. Most of the innovation comes via acquisitions or when they hire some industry luminaries to lead projects. The rest are only there to fill in the lines and be highly productive coding machines that will learn the “syllabus” just like they learn to leet code.

FAANMG also has a deluge of resume thrown at it every semester. Ever since mainstream media filmed at the Google Campus/Facebook HQ, every parent wants their kid to work there since "he's really good at this computer stuff" and "he's gaming all the time, he might as well make money at the computer!".

And then you get to interviewing and realize this candidate cannot write 2 lines of code...


There's a big world between "cannot write 2 lines of code" and "studied Leetcode full-time for only two months instead of three." I give a lot of interviews, the majority of candidates who fail are in the latter category.


Thank you for your insight! Hm so perhaps statistics and probability are actually more valuable for companies like that?


Do not think only in terms of technical skills. Large companies operate via easily scaled algorithms for everything including promotions and hiring. The simplicity of these algorithms often means that they can be circumvented. You want to get hired at Google. What do you do ? Spend 3 years doing side projects or spend 3 months befriending and impressing some engineers so you get a referral.

There maybe god level engineers who are stuck at junior levels because they simply don’t know how to fit into the gears of the hierarchy. If you want to get promoted your relationships and trust with the management chain is as important as the quality of your work.

Don’t buy into the official stories about systems and processes work. Learn how they actually do.


I have to do my 6-monthly plug of The Inner Ring [0] by CS Lewis here. Dives into some of this, drawn from War and Peace.

[0] https://www.lewissociety.org/innerring


> Does this mean that the whiteboard coding interviews are flawed

They are optimizing for something. It's just not what you think it is.

A lot of it seems to be about the identities of the employees and the hazing ritual that initiates new members into the group.


> hazing ritual

Got it in one.

Whenever I ask people about these tests, we have some back-and-forth, and it inevitably ends with them declaring (in so many words): “Well, I got hazed, so you will, too.”

I don’t suck at the tests, but I’m not particularly good at them. I never practice them, and didn’t come up through the traditional CS curriculum (I started as an EE), so I’m often seeing the problems for the first time, when I look at them.

They just don’t have any relevance to the type of work I have experience doing, or the value I could bring to a team. Since it seems that most interviewers are looking for particularly formulaic responses, they are a pretty good way of filtering out people like me.

I’m always puzzled as to why interviewers waste valuable time on these seemingly pointless exams. If they don't want me to work for them, there's much easier ways to discourage me.


> Why would a company rather have a guy that can solve binary search in five seconds, than one that has showed continuous progress with several finished projects over the years?

They probably only interview people that have showed continuous progress with several finished projects over the years and hire only those that are good and can code instead of pulling leftpad from npm (a snarky response but so is yours, as if it's either good at whiteboard interviews but uncreative imp or bad at interviews but great and accomplished)


One of the things these discussions rarely bring up is that companies want to have a similar process for evaluating everyone. This is especially important if a rejected candidate accuses the company of illegal discrimination. If you can show that you applied the same criteria to everyone, then you have a better defense. I think side projects are great, and can be useful in evaluating how well a candidate will "fit" a job or work environment, but there's no denying that it's a deviation from a standard evaluation process.

At one place I worked, one of the exercises we used simulated working in a team environment. HR was really worried that we were giving a "test" (this really sets of their alarm bells if they haven't vetted it!) and we had to prove up and down that it was an exercise to see how they performed in a group setting, and the actual code wasn't very important.

The whiteboard coding interviews are beyond stupid IMO, but at least they can prove that they're consistently applied.


I interviewed for a job at the BBC many years ago and there was an HR person in the room with the interviewer making sure that they stuck exactly to the script.

As someone who thrives on talking about side-projects, I did not do well in that interview.


> Or is it that they want a blank sheet imp that they can mould wholly in their own image? Is real creativity and output really of no value to these guys?

That's what I'm starting to suspect, and that suspicion is shared by several of my friends in the industry.


Binary search? I would never hire anyone who couldn’t implement it from scratch. There’s no complex idea or trick to remember, it’s the most basic algorithmic around.


StackOverflow disagrees: https://stackoverflow.com/questions/504335/what-are-the-pitf...

I quote from the thread: "binary search was first published in 1946 but the first published binary search without bugs was in 1962"


I wonder what the expectation of the interviewer is on this. Virtually every single piece of code I'll ever write is going to have a a few off-by-one errors and probably other common bugs. That's why you do some basic validation and QA to find those bugs and fix them. The first pass isn't likely to even compile, but who cares? The compiler will tell you exactly why and you can fix that, too. Perfect code on a first try is a useless skill.

On the other hand, just understanding how the algorithm works is what matters. And binary search may have been "published" as an implementation on programmable electronic computers in the recent past, but it's a timeless and intuitive algorithm that I understood perfectly well when I was 4 years old and first learned to read and started looking up entries in the dictionary, encyclopedia, and phone book.


I agree that it's not particularly challenging. As a counterpoint though, a linear search is more basic. It's also often faster than a binary search for small datasets, and it's easier to prove correct purely by inspection.

Anecdotally, a coworker we hired a couple years ago (and has been doing an awesome job) dusted off her old coding challenge from when she applied, and ran it through a new test suite we've been working on. The suite failed, and it turns out her binary search was buggy...


> As a counterpoint though, a linear search is more basic. It's also often faster than a binary search for small datasets, and it's easier to prove correct purely by inspection.

Also for sorted datasets where the most frequently referenced data is at the top.


I feel like I'm pretty good at these things, but I'd 100% have an off-by-one error in my first attempt at binary search. I can get it right quickly if I'm able to test the code, or very slowly if I have to work through several test cases by hand on the whiteboard.

There's a lot of room in between "couldn't implement it" and "can do it in 5 seconds" and "wrote a buggy version of it".


One of the best things you could do in a whiteboard interview is just start writing effective unit test cases without being prompted into it.

When I joined my current company, it was still tiny and sketchy and I got shanghaied into a surprise full day interview by the promise of an informal two hour tour. A two hour tour... At one point I was given 1.5 hours to write an implementation of a very core library that most software engineers take for granted every day. Trying to have fun with it, I spent about 20 minutes writing a design document, about 30 minutes coding the implementation, and then the last 40 minutes writing a dozen or so unit test cases (as well as a simple standalone unit test framework). When I ran out of time, only maybe 2/3rds of my test cases passed, and I had just narrowed the problem down to a flaw in one of the assumptions I had enumerated in my design document. All the interviewers seemed pretty impressed by the documentation and test coverage, and didn't really care about the implementation, mostly because it was relatively boring by design.


I agree it's very easy to make an off-by-one mistake in binary search. (Related article: [1]) But an interview candidate showing something that is almost right and then has enough self-awareness to say "but I'm sure there's an off by one error in there somewhere" has given a really good overall answer in my books. I think there's still value in asking the question because that sort of answer constrasts against candidates who flounder completely (which is more common than you'd imagine).

A common counter argument is that a bad interviewer wouldn't accept an answer that has minor bugs in it like that. But I don't buy that counter argument, because a bad interviewer could misjudge candidates regardless of the interview format.

[1] https://reprog.wordpress.com/2010/04/19/are-you-one-of-the-1...


Has anyone who's worked for you had to write binary search from scratch on the job? It's pointless to ask candidates to write code that they'd never have to do in the real world.

I've been writing code for 25+ years, 15 years professionally, and the only time I had to write any search algos from scratch was in school. I'm sure I could do a binary search given enough time but I'd probably just refuse and end the interview.


I'll ask algorithmically interesting questions inspired by past problems I've solved within relevant domains. They're often solvable with some element of binary sorting. I don't care if someone uses a standard library or googles something, but I'll notice if they choose to use one and use it wrong. The classic example is assuming a dict in python is a tree rather than an unsorted hash map.

Walking out of an interview like that is certainly a great way to not get hired. That's fine if you didn't want to work there anyway I guess, and nice for the interviewers because they learned enough to end the candidacy confidently knowing they dodged a bullet. Strong engineering teams solving worthwhile problems want to hire people that charge head first into difficult problems and get their hands dirty.

If I were in a similar situation where I was asked to write an algorithm I was unfamiliar with, I would probably just say up front that I have no idea how to do that, and then start asking the interviewer questions about how it might work. I would also quickly try to identify a real world example of a problem they're hoping to solve with that algorithm, and then brainstorm alternative ways to solve that problem in ways I'm more familiar with.


Relax. It was just an example of the often menial 1-2-3 things that often aren't really relevant for the job in question, but are still used to fail even accomplished coders in interviews.


The binary search algorithm listed on Wikipedia has a bug. It's addressed much later in the article.


a guess - you're young and have short industry experience, just enough to make very sure of yourself, so probably the age is between 25-30 with the experience between 5-10 years?


I am older then that and still don't fond that question extraordinary hard?


the point isn't about whether the question is hard. It is about understanding that other people are different and especially when the people stumble for whatever reason. The manifested "holier than thou" and lack of humility probabilistically suggest relative youth and inexperience.


Yes other people are different, but I have yet to meet good developer who struggle to understand binary search.

Yes, people can randomly fail in interview due to stress or whatever. But that can happen on any question. This particular question really should weed out all that many otherwise good people.


I learned the common search algorithms in school. I haven't had to touch them since, if you asked me to write psuedo-code for them on the spot I'd almost definitely fail to implement them properly. There's a huge difference between struggling to understand something and not being able to do it from memory on a whiteboard.

Imo conversational questions are much better indicators in an interview of whether someone will be a good hire, the candidate knowing why you would use a binary tree over another data structure offers much more insight than asking them to write one. The more conversational approach also allows the interviewee to demonstrate their knowledge and gives you a better idea of how they approach a problem or whether they'd be a good fit on your team.


As a teacher I'd say that depends. If it's relevant to the job, then you should obviously know it, and perhaps even be able to expand upon it. Though after reading the posts here I have a sneaking feeling that things like that usually aren't relevant.

With that said, having a conversation with someone solving a problem right in front of you, gives you a very good insight into how the person thinks. To that end I've censored a lot of pupils where they have to "defend" (i.e. talk about or explain) a piece of code that they made, sometimes beforehand as a bigger project, or sometimes on the fly.

I'd often give them extra problems and talk with them about it as they solved it if I was unsure about the grade. I find that this gives me far more insight in where the pupil is coming from, and hence his level of competence, rather than seeing the code on its own, or having him answer a multiple choice or SAT type test. I can see how an interviewer might make use of a similar technique if he's unsure about the candidate.


The reality is that companies just don't know. They have a few interviews to vet a candidate, and can't possibly make a truly informed decision. They move from different vetting tactics and follow trends because they can't really measure the outcome of their vetting strategies directly.


Ok, I interview and hire folks where I work. (Mostly looking for C/C++ folks.) If you list projects or GitHub links, I'll DEFINITELY go through them and probably spend a lot of time asking questions about your design and implementation because it's great seeing what folks can tell you about things they wrote.

In the absence of that, why might I ask you to implement a binary search or maybe a linked list: I want to give you a problem that you (should, for senior folks) understand and will show me that you understand pointers and dealing with memory with something basic. I don't expect perfect on a whiteboard interview, I'm just looking for red flags.


I had a co-worker about ten years ago. His coding question was always: Please implement a linked list for me in any language. He said more than 80% of candidates failed. Incredible. LinkedList! I can understand that people will struggle to write a HashMap, BinaryTree, or BinarySearch (always full of bugs), but LinkedList is just crazy.

To be fair, I always get tripped up by the classic interview question of reverse-a-single-linked-list. It's not something I ever do outside an interview!


I had a good laugh from this one xD Thanks for sharing! Almost makes me wonder what's the most "creative" and convoluted way of solving a linked list. "Any language? Well, how do you like this implementation in Whitespace?"


I am an individual contributor and technical leader with multiple degrees in computer science engineering, and about 15 years of experience working on safety critical real-time embedded systems. I've interviewed many hundreds of people for software engineering roles over the years. The majority of people that apply for software engineering roles are simply not a great fit. Onsite interviews are very expensive in terms of engineering time, so as a company we try to vet coding ability via phone interviews and no-time-limit coding challenges. If we do ask a whiteboard coding question, it's because there were potential red flags earlier on in the process. When someone gets rejected after an on-site interview panel, it's either because they flopped multiple interviews, or were mediocre across all interviews. There's detailed notes individually typed up by each interviewer, and you can typically see common themes emerge across the various sessions.

"This person seems really sharp, and their questions were very insightful!"

"They really focused on testing more than the typical applicant."

"I tried giving them a hint four different ways, but they just wouldn't take it. When I explicitly explained what I was looking for, they agreed with me, but I couldn't tell if they actually understood."

"Their solution seemed a lot more complicated than necessary, and had a bunch of unhandled edge cases as a result. Every time I pointed out an edge case, they added another branch rather than fixing the underlying structural problems."

"Several times when I asked a question, they deflected or answered something else, or assumed I was implying something and continued writing more nonsensical code."

Also, many people people tend to attribute a lot of value to their personal/hobby projects. They're certainly very cool and fun to chat about, but it's very rare for projects to be novel in a way that sets you apart when being considered for serious engineering projects. At work we develop UAVs. Your hobby grade FPV quadcopter is totally sweet, but it isn't going to get you an interview. If you built a hardware-in-the-loop testbed for your quadcopter, then let's talk!

"Output" in particular is a funny thing to gauge in software engineering. I'll sometimes go a month without writing a single line of production code. My favorite PRs delete more lines of code than they add. A more junior coworker will have bloody fingertips from coding around a problem for days, and then I'll ask a relatively dumb question about what they're trying to do, they'll think for a minute, and then delete 1000 lines of code and replace it with 50 because they were making incorrect assumptions. It's not just individual productivity that matters, but also team productivity.

"Creativity" is also a funny thing. Within embedded software, the most elegant solution is the most boring one. Any time someone does something creative, there better be an extensive unit test for it, because otherwise it's definitely going to be buggy. With wisdom, discipline and creativity all together one can build more sophisticated and complex systems than otherwise, and that's highly valuable. Lacking wisdom or discipline, though, creativity does indeed become a liability.


Thank you for taking your time to give this answer! I think it gives great insight into how you work and what you're looking for!


In my experience, for every engineering subordinate that turned out to be good that I didn't bother testing with leetcode, there were 19 who sucked and also failed their coding test, or sucked and we should have tested them. So far, among people who studied programming as their major in college, the best predictor was the prestige of the university they attended.


If you've hired over 20 people, and 19 of them have been bad, it just sounds like there's something wrong with your process. It also sounds like you're hiring a lot of novices, which isn't what's being discussed really.

The uni thing is not exactly a revelation. It's the same for every single field/job. Better uni, usually better worker.

All you're actually saying is that novice programmers straight from uni mildly correlate in ability with SAT scores.

Nothing surprising in that.


>If you've hired over 20 people, and 19 of them have been bad, it just sounds like there's something wrong with your process.

I think this is part of the reason for the widespread usage of take home / coding assignments etc.

If you have a bad process making people do some work improves your result.

I remember the first company I had with a friend in the late 90s and our process sucked. It was embarrassing, although thinking about it we still had a 50% success rate in technical quality of people we hired. If we had given tests to the people we didn't have someone to vouch for it would have meant we did not make the mistakes we did. And by saying we had a bad process we had a bad firing process as well. The bad hires we made really were catastrophic because we couldn't handle any part of the process.


Yes, the thing that is wrong with the process is that they didn't check to see if the person was able to write code.


I like leetcode as a hiring metric and I think it's the best measure to test out an engineer. Unless a company uses it basically to find people that implement the fastest algorithm(read: have memorized it already) in 30 minutes it can be a very very effective way of screening.


It helped me to get offers from companies, so I didn't have to apply for anything anymore.

Sure, when I applied, I had to do dumb tests. But when a C or VP level asked me it was usually not an issue to get a job.


This really depends. Are you talking about FANG+ type companies? Doesnt matter who you are you will probably have to whiteboard.

Outside of FANG? I'm sure you can bypass many technicals with credentials.


I'm not talking about big companies. I'm not that famous.

But I think, if a person above VP level wants you at Facebook, an assesment center isn't an issue.


That's actually not really true. You still have to interview. A referral or being recruited directly isnt a free pass. You'll probably get some additional prep but the person recruiting you cant just say let's make this person an offer.


Really?

I had a professor who got people jobs at big corps and he said, many of them failed the assesment, so he had to talk to higher ups.


Most FAANG companies do actual coding now instead of whiteboarding :(


Why the unhappy face? Is this considered a bad trend? I'm personally way better at online coding sessions than whiteboarding.


Jotting down an algorithm and talking about complexity is probably easier than implementing it?


A coding session usually implies something unrelated to algorithms. Whiteboarding is usually much more than "jotting down an algorithm".


Great to know, an editor is much easier than a whiteboard

I'd much prefer it rather than scribbling in a whiteboard with an eraser that doesn't work and trying to put together the solution

Whiteboard does work for higher level discussions, not for anything resembling code

Lest they ask you to whiteboard FizzBuzz, that makes me want to leave the interview immediately.


I’ve had a couple of interviews where I was asked to either whiteboard FizzBuzz, or answer 00s era Google brain teasers. From a big company that would be a swift exit from the interview process for me, but in both cases it happened to me I was interviewing as the first engineer at startups - I did the tasks, and then had a conversation about how if I were hired I’d remove them from the interview process.

In both cases I got the job, then stuck around for 5+ years, so I’m going to say it worked out ;)


Because their interview questions were silly?


> In my experience, for a pure engineering role, nobody seems to care.

I am interviewing a lot of people. I look very suspicious at these kinds of moves to try to impress me.

I don't necessarily ignore, but I try to figure out if this is some kind of shallow engagement.

It impresses me if you can stick to something meaningful and do it regularly for years but you can just as well hurt your chances if you propose 5 simple commits to random projects on Github to be your greatest accomplishment.

A blog about programming is not going to impress me if you are still junior engineer. Rather, it is worrying. I always remind people to learn something first before you try to teach other people.

I will still want to see you code yourself out of a paper bag.


> I always remind people to learn something first before you try to teach other people.

Teaching is one the greatest ways to learn and develop your relation and vocabulary for what you are currently learning. It’s one of the greatest tricks a good college class will pull, having students continually drag each other a step further as they learn something new and then have to explain it to their peers. Most blogging is this kind of “I’m not writing it down to remember it later, I’m writing it down to remember it now.”, so it’s seems to me you might be dismissing some eager learners if you think the act of blogging is self-important.


> Teaching is one the greatest ways to learn and develop your relation and vocabulary for what you are currently learning

Oh sure it is.

I studied theoretical math and I found teaching other students math was great way to get it organized in my head. But we also had professor and I wasn't teaching anybody original ideas, just the material that was already written and defined.

Now I have decades of development experience I still find explaining things to other people a very useful and efficient way to get my thoughts organized.

I kinda exclude blogs with posts of the form "see, I have found something interesting today!" or "I just spent 5 hours solving this problem, writing down solution here so you don't have to waste time". This is fine.

But if you have 3 years of experience in development and start writing blog posts criticizing OOP, that is definitely not going to help your case.

I mean, it is highly unlikely you got enough experience and thinking done to even understand OOP, let alone start criticizing it.


I find this attitude a bit sad :( I think there's at least one place we agree which is that it's annoying when people do shiny yet perfunctory things as basically a gimmick or trick to convey the impression of depth that just isn't there.

But... I think someone with 3 years of experience deeply engaging with the question of OOP is a great thing to do. You're not wrong that they can't possibly know, but that's not relevant I think. Trying to own the domain and think critically about the sacred cows and reinvent the useful parts is exactly what a good autodidact has to do. And doing it in public view, available for critique and ridicule, I think puts skin in the game and shows character.

There's something to be said for certainty and epistemic humility, but also I think basically everyone who ever invented a truly new thing or learned something nontrivial on their own had to bring enough audacity to the table to get over the line.

Maybe it's a personality difference and you're making the right choice for the type of personality you want your org to have.


Rather than making conclusions based on their level, see the arguments they have in their article and if it's doubtful they didn't come up with those thoughts on their own, but simply copy pasted, then ask them to elaborate on some things and it will be clear.


I don't keep a blog to impress you. Nor to "try to teach other people"; if anything I use it to teach myself (ie to organize my own thoughts and to document my learning).

Blogs are simple media to share one's thoughts, because one likes to write and... to share---that is it. If you don't care for my writing and my sharing then you're free to move on.

The beautiful thing about knowledge is that it's free and open to anyone, implying that junior engineers shouldn't have blogs is next level elitism and conceit. That is what I find worrying.

I feel sorry for the people having to interview with you or working under you, that need to code themselves "out of a paper bag" to impress you.


And that is perfectly fine.

You know what is not fine? Telling people they need blogs or open source projects to get better chance at getting work.

Because then I get candidates that spent a lot of their time and effort doing something they did not really want to do rather than getting better at what they want to.

> I feel sorry for the people having to interview with you or working under you, that need to code themselves "out of a paper bag" to impress you.

I feel sorry for the people that have to work with you if you feel ability to demonstrate you can program is not a prerequisite for working in a development team.


>A blog about programming is not going to impress me if you are still junior engineer.

I don't quite agree here. Junior engineer doesn't always say much about skill. People can have deep knowledge in a field like reverse engineering but still work as a junior because they got out of college 1-2 years ago.

When it comes to junior/senior titles I get the feeling age is more important than "skill".

I get what you're saying though, you should never act like you're a god amongst men, but blogposts that show deep knowledge aren't something I would dismiss.


> if you are still junior engineer. Rather, it is worrying. I always remind people to learn something first before you try to teach other people.

The curse of knowledge is also a thing: An expert might have a harder time explaining things to a novice. A novice can more easily explains things to a fellow novice.

And if someone gets something wrong on the internet, sooner or later someone else will point it out. #XKCD386


I think it depends a lot on the place. I'm hiring now and we actively appreciate things like mentoring and doing public work.

I agree that people not feeling appreciated should try other things, but I think that includes different kinds of employers as well as different kinds of job.


I agree, I was in the California market for 7ish years so my experience is heavily skewed for that culture.

That being said, I’m NOT bashing those interviews. I’ve been a hiring manager too, if I was able to offer double money and high prestige like a FAANG company I would have had a high filter too. I focused more on sourcing people through friends of friends so the interviews were more of a soft sale on my end than a leetcode grind.


Definitely. I use a link shortener to track visits to my portfolio links. (Almost) Nobody looks at your public work.


Same experience here. Everyone says you should spend your nights and weekends building a portfolio on top of your day job, but no one looks at it when you apply. And then you get put aside because you didn’t know for sure in an instant what is the result of `‘1’ + 1` in JavaScript.


When possible I bypass shorteners so candidates won't know when I've looked, eg add + to the end of bit.ly links.


I mean why would someone want to visit your online portfolio if it looks like you didn't even put in enough effort to get a proper domain?


Yep. I basically made the same remark. For a lot of positions they're just not looking for creative people, just chairs to fill. They want "good enough" and nothing more.


I don't see how having high enough standard means that they want "good enough".Do you want their hiring level to be even higher or what?


>Do you want their hiring level to be even higher or what?

I just described what I see. It's not about what I want or don't want. Personally I'm mostly indifferent, I'd say.


Yeah I need to leave the industry.

Problem is, not much else looks appealing. Most realistic pivots look more miserable and end up just being adjacent roles that remove all the parts of what I like about software development while becoming mostly what I don’t, likely with a much lower salary cap. I thought about doing something radical and going back to school, but I don’t have the time or money. Though this thread makes me want to look again.


I've found careerexplorer.com to be a helpful tool for career planning and exploration.

Knowing where I stand and what my values are also helps when it comes to navigating the professional environment.


What does ‘credits’ mean in this context?


Where are you finding public speaking training? I’m asking because that’s a skill I would myself like to develop.


> if I forgot how to write binary search

The binary search algorithm isn't something you can "forget". For a literate programmer it's like forgetting how to write the letter 'A' or forgetting which pedal is the gas and which is the brakes.


I think you’re overestimating most people’s ability to withstand the stress that quiz show style Leetcode interviews can put on people. I’ve literally blanked on an interview before when I was tasked with writing a simple parser and I’ve written entire compilers. The interview processes are broken in most companies. Pair programming sessions with debugging and incremental graduation of the problem scope are way better at assessing programming competency, because you also get a sense for how well the candidate can collaborate and communicate.


Yeah, folks can definitely freeze up and I'm pretty sympathetic to that in interviews. I'll often spot folks most or all of the algorithm if it looks like they locked up. "Hey, you could dry implementing it like this..." and see where they go from there. I mean, we really want to see people succeed with these things.


Stressful situations happen at work. If you're not able to handle it in the interview you might not be able to during crunch time.


Well, but he said "forgot how to write binary search in 10 minutes". This came up here three months ago: "school was years ago...I've forgotten how to implement a hash table in C within 30 minutes. Is that really the gatekeeper we want?"

Well, I thought, yes, I think it is, actually? So I tried implementing a hash table in C—without testing it, as if I were writing it in an interview without programming tools. It took me 15 minutes and had a significant bug: https://news.ycombinator.com/item?id=26593250

I concluded that implementing a hash table in C in 30 minutes is a reasonable thing to ask someone to try during an interview, and how people work on it will probably tell you a lot about their programming abilities. I wouldn't hire them for a C programming job if they said "school was years ago, I've forgotten", but you shouldn't necessarily expect them to succeed flawlessly.

Binary search in particular is notoriously tricky. It's easy to explain the idea in a lot less than 10 minutes, and it's easy to write a version of the code that sometimes works in less than 10 minutes, something like

   bs(k, a, i, j)
   {
     int m = (i+j)/2;
     return a[m] == k ? m :
            a[m]  < k ? bs(k, a, m, j) :
            bs(k, a, i, m);
   }
But it's easy for the algorithm to hide subtle bugs. That version has at least one type error (in modern C, anyway), one obvious correctness bug, at least one obvious performance bug, and probably some subtle correctness bugs as well. Many years passed between the first publication of a binary search algorithm and the first publication of a correct one.

Also, though, there are lots of kinds of programmers. You can spend a lot of time writing screen-scrapers or CRUD or machine learning models in Python without ever needing to implement binary search. In Python you should probably just use the bisect module in practice, most of the time, rather than reimplementing it.


> But it's easy for the algorithm to hide subtle bugs.

For sure, but I guarantee you the interviewer from the grandparent comment wasn't looking for correctness and safety when they asked to implement a binary search.

They ask the binary search question to check if the applicant knows what an algorithm is and if they ever had to implement one. (Any algorithm.)

Sadly, 90% of programmers these days don't and haven't.

> In Python you should probably just use the bisect module in practice, most of the time, rather than reimplementing it.

Well, yes, most developers ship software without ever having to actually program.


> I guarantee you the interviewer from the grandparent comment wasn't looking for

What, the company that interviewed James Hush about binary search was your company? Have you thought about the possibility that maybe he also interviewed at at least one other company which used different evaluation criteria? Maybe you should put a little bit more effort into correctness yourself!

> They ask the binary search question to check if the applicant knows what an algorithm is and if they ever had to implement one. (Any algorithm.)

> Sadly, 90% of programmers these days don't and haven't.

That makes no sense. Every program or subroutine implements an algorithm. If you haven't written any programs or subroutines you aren't a programmer.

> Well, yes, most developers ship software without ever having to actually program.

This reminds me of when I was a kid and we thought it wasn't "actually programming" when we programmed in BASIC or Pascal because actual programs were written in assembly. We were wrong about that.


Your analogies are things that you use a large % of the time, almost any second. Whereas I've been programming for years, and never wrote a binary search (I think?), but perhaps I don't qualify as literate?

I think writing an if-statement would be closer to your analogies.


Yeah, the parent commment is what I consider a reason for why many fear the imposter syndrome. They read about other developers saying "If you dont know how to do X, you suck and cant get a job".


> ...but perhaps I don't qualify as literate?

Probably.

Point is, you don't really need to know how to program to ship software.


This comment is nonsense. Nobody is writing binary searches in their day-to-day jobs, and if they do it's once in a blue moon, not every day. You're using pedals every time you drive.


Yeah, I need to implement a binary search maybe once a year. I had a legit use of a priority queue a couple years ago and I'm still excited about it!

I've still never had a professional use for a Trei structure. I tried really hard to make a case for it on a project at Google, but it just didn't make sense vs. slapping down std::map and then drinking a beer.


In which case would you actually implement a binary search instead of using an existing library method for that?


Code running on a microcontroller with very limited RAM, operating on data structures that don't naturally plug into generic algorithm implementations. For example, finding the end of a several GB long append-only log file stored on the raw blocks of an SD card.


In these cases did you write it from scratch or were you able to copy paste a working solution?

Because most pragmatic to me would be to google for a solution on Stack overflow, see what is upvoted and seems reasonably vetted, then potentially go over the code yourself to see if there's any issues and maybe write few tests to be extra sure.

Maybe your use case is too niche though to be able to copy paste though, I'm not sure.


Sure, I'll find some example code on Wikipedia or whatever as a reference. It's faster than deriving it all again from scratch. I don't really copy paste algorithms like that, though. Instead, I review the reference material until I understand the algorithm and any potential edge cases and optimizations that may apply, and then code it up and unit test it.


> Nobody is writing binary searches in their day-to-day jobs

But in an interview situation, they cannot give you a three week task. Like FizzBuzz, a binary search is a simple task that can be done during an interview. They are not testing your ability to write a binary search. They are testing you on your ability to implement a function, given specific requirements.


The last time I actually wrote a binary search was in college in 1992. I still remember exactly how to do it... because it's really basic.


Binary searches should be internalized as part of your life's vocabulary if you're a programmer.

You don't use all 10000 words of your native language every day. You don't ride a bike every day. Nevertheless, that's part of you and you don't need to make a conscious effort to remember which way the pedals spin when you ride a bike after a long hiatus.


I don't think those examples are really applicable here. You don't use all 10000 words, but our brains are evolved to process language and you interact with language everyday. Riding a bike has you engaging in a physical activity which is also something that we're geared to remember.

Programming is already pretty unnatural and implementing binary searches and other basic algorithms is really only something you do constantly in the beginning. Over time that "muscle memory" will fade. It's also something that's easy enough to look up and understand in a couple minutes.


How often are you writing binary search algorithms hahah, is it like your variant of a doodle?


For me it is! It's one of my standard exercises when I'm sketching out a new programming language: what does binary search look like in this language? How general is it? http://canonical.org/~kragen/sw/dev3/paperalgo#addtoc_23


I think the overall point is the risk of forgetting something judged as "fundamental."


Can you clarify what you mean here? I would argue that any decent programmer could hack out a sorting routine, without having the code memorized.

If you cannot write a binary search routine from scratch, how can you be expected to solve much bigger problems?


Sure, but there are a lot of subtle issues in both sorting and binary search. The simplest sorting routine is probably dumbsort:

    void
    dumbsort(int *p, int n)
    {
      for (int tmp, i = 1; i < n; i++) {
        if (p[i] < p[i-1]) tmp = p[i], p[i] = p[i-1], p[i-1] = tmp, i = 0;
      }
    }
But it lives up to its name; I can't imagine any reason you should ever use this algorithm. It compiles to 16 instructions but it's O(N³). Insertion sort is more complicated—it compiles to 17 instructions—and is actually a reasonable thing to use in some circumstances:

    void
    isort(int *a, size_t n)
    {
      for (size_t i = 1; i < n; i++) {
        for (size_t j = i; j > 0; j--) {
          if (a[j-1] <= a[j]) break;
          int tmp = a[j];
          a[j] = a[j-1];
          a[j-1] = tmp;
        }
      }
    }
That's because it has the lowest constant factor of all the O(N²) comparison sorts on common machines, so it's the absolute fastest way to sort small arrays. (On my laptop it sorts N items in 0.34 ns × N² ± 2%.) And it's also very fast for large arrays of nearly-sorted data, so it's a reasonable way to finish up after a rough quicksort.

It took me about five minutes to write that, and it worked the first time I tested it. But that's in part because I find sort routines fascinating and I've been studying them, and programming in C, for almost 30 years. Even if it took you an hour or four hours and required a lot of debugging, you still might be a decent programmer. Especially for jobs where things are less well defined and you have to do a lot of debugging anyway!

(By contrast, I've actually spent most of the last hour trying to write a properly working quicksort, the variant that finishes up with a single call to insertion sort, using both notes and a compiler. Of course it produces correct results because of the final insertion sort but it's not as efficient as it should be and I can't figure out why. Apparently I can't brain today... good thing I'm not in a job interview!)


There are two modes of hiring:

1. General purpose: Typical FANG like where hire first and then do team matching later

2. Targeted hiring: Companies want specific people and they try to recruit them

A sizable number of top open-source contributors get recruited are in #2. Eg. 1) Top contributors in Rust lang hired by AWS. 2) FANG companies targeting top AI researchers from academia.

One's open-source presence needs to be really prolific and the project has to make an large impact to be in #2 category.

For #1 category folks, your public profile does not matter that much (atleast for FANG companies)

Other way to think is #1 are treated as cattle, #2 are treated as pets.

The famous incident where author of homebrew was rejected by a top company because he could not invert a binary tree got in the wrong channel (#1) to begin with where he was treated as a cattle.

Note: Recruiter from FANG calling you still goes in #1 category for most people


> The famous incident where author of homebrew was rejected by a top company because he could not invert a binary tree got in the wrong channel (#1) to begin with where he was treated as a cattle.

It's apocryphal at best. The guy was rejected by Google, but was never asked about inverting binary trees, like he claimed.

(I can believe that he was rejected on some other technical trivia, no clue. But the 'invert a binary tree' thing never happened.)


My bad. I based on the tweet from the author himself [1]

May be he meant to use "invert binary tree" as a representative example of questions that typically asked.

[1] https://twitter.com/mxcl/status/608682016205344768?lang=en


No worries.

See https://news.ycombinator.com/item?id=27927159 for some more.

> May be he meant to use "invert binary tree" as a representative example of questions that typically asked.

Yes, that's a charitable and believable interpretation of his tweet.

(Though I don't know where he got that 90% figure from. Probably made up, like 85.12% of statistics.)


It’s a charitable interpretation, but seems super reasonable. Around that time, I think “inverting a binary tree” was a bit of a meme/shorthand about software interviewing.


Was it? I thought that meme began from his post. To be totally blunt if you get asked to invert a binary tree in a FAANG interview, that’s very easy compared to most questions.


Interesting anecdote, where did you hear that? I remember the original source tweet that was something like, “invented homebrew but couldn’t invert binary tree so they rejected me.”



Okay, so you admit he claims it did happen, but you say it didn't without supporting that claim at all. Do you have a source we can verify?


I was working for Google at the time, and saw an internal post by the guy who interviewed the candidate.

I'm not sure if there's anything public (and what I am even allowed to say.)

See https://www.quora.com/Whats-the-logic-behind-Google-rejectin... where he (at least partially) admits that he was bullshitting:

> I want to defend Google, for one I wasn't even inverting a binary tree, I wasn’t very clear what a binary tree was.

See also https://www.reddit.com/r/google/comments/7l5ibp/max_howell_h... for a discussion.


That was interesting.

> But ultimately, should Google have hired me? Yes, absolutely yes. 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.

To me at least, being a dick is a negative that outweighs making good things, especially for a large organization. Maybe google made the right call.


Right, Google actually has a 'no jerks' policy and values being a good team player more than pure technical brilliance. Being a good engineer gets you L4 (mid) or low L5 level at Google. Growing beyond that is mostly about soft skills and influencing other people - that's not compatible with being a dick. It probably wasn't the case for him in 2015 yet, but these days google has a mandatory 'googleyness' behavioral round that the guy would fail hard with that attitude even if he could invert the proverbial binary tree.


I joined in 2014 as L4 (I think), and I remember having some googleyness interviews even back then.

But I could be remembering wrong.


I dont think its unique to google that companies want to filter out people who are "dicks". Every company i have ever had an interview at has done behavioural interviews for that purpose.


I highly recommend interested readers to follow through to the Quora page. It’s more or less a public apology, and helped break me out of the echo chamber that occurs here and on Reddit related to interviewing at Google.


It looks like there are a bunch of programmers who think that having taken the first year uni course on data structures is more important than having experience actually building product and having it used by millions.

It's kind of silly. Most programmers out of school have a lot to learn about building product and actually getting a big project done - which they are supposed to learn on the job. At a place like Google. Somebody who knows this part already could probably spend some time on the job learning about data structures.

It's like these conventionally-taught programmers think they get to look down on somebody who actually built something cuz he's self-taught. (As a conventionally-taught programmer who is very comfortable with data structures I find that attitude aloof at best)


I have a traditional Computer Science background and I'm still intimidated to even apply to Google. I got out of bigCo Software Engineering in part because I wasn't interested in putting myself through the wringer of whiteboarding memorized solutions.

I'm also the guy that found low hanging fruit in a huge codebase to replace things like frequent linear array lookups with hash table lookups for 10x+ speed improvements in the build process. This is IMO precisely the type of capability that "Oh, that's O(n^2), surely we can do better. Is there any way to do this in O(1)?" is designed to tease out in the interview process. I did it! In a build process effecting 1000+ engineers, used to build for millions of shipped units! But talking about this in an interview makes eyes gloss over as we prepare to move on to sort algorithm trivia, how would I design search, or doubly linked list implementations.



But you know, hash tables have O(n) access...


Some implementations have O(n) access in the worst case.

Often people are interested in something like the 99.9999%ile case. And, of course, you can design hash tables with better worst case behaviour.

It's almost trivial to get a hash table with O(log n) worst case access: when you have a collision, just resolve it with a tree instead of a linked list.

With some more fancy math, you can also get O(1) amortized worst case behaviour with arbitrarily high probability that doesn't depend on your input data.


And this is where interviewing gets hard. Are we really going to not hire someone because hash table is O(n) in the worst case but O(1) on average. It seems like half the time there isnt a match, the interviewer is just as wrong as the candidate, and they are looking for someone who knows the same info as them, even if its half baked.


> It looks like there are a bunch of programmers who think that having taken the first year uni course on data structures is more important than having experience actually building product and having it used by millions.

To be honest, drilling down on all the stuff they teach you in first year helps you more in getting a job at Google than having lots of practical experience.

I'm inclined to believe that this is a problem with Google. But I am not sure you should trust my opinion: I am sure Google spent much more time and money and figuring out the right approach here than I ever laid my hands on in my whole life.

See also https://sockpuppet.org/blog/2015/03/06/the-hiring-post/


he wasn't "bullshitting", you didn't get the point of his tweet and quora post and I think you're kinda proving his point.


He wasn't "bullshitting" indeed. He was straight up lying. And his lie poisoned the thinking of millions (myself included) wrt. tech interviews.

My opinion of the guy just dropped hard.


I'm not sure if the extra work is rewarded as much as you might think. For example, I was shocked to see a prominent open-source contributor hired into Google as an L5. Without going into detail, this person built projects used by many people reading this comment. Granted, I don't know what their comp or interview process was like, but 5 is basically an ordinary senior engineer level at Google.


Google hired me in 2006 (then 11 years of experience) as a 3. I didn't know any better at the time, partly because I was coming into the valley from the rest of the world.

I didn't find out just how screwed up this was until becoming part of the hiring process at Facebook... some seven or eight years later.

So... yeah. What you said is totally a thing.


Wow Google tried a lot of mental gymnastics to down level me. Trying to convince me that higher levels at FB or other companies is equivalent.

That’s a whole other level though. Not surprising and it is hard when it’s a coveted company. I would’ve taken the down level if I didn’t have a better offer at another company.


The key question imo is:

Was he still subjected to same interview process where he has to prove his coding skills inspite of being prominent open-source contributor?

As for L5 level based on anecdotal stories anything beyond L6 is hard in Google.

Search for "Crossing that barrier to L6 is getting more and more difficult with time" in [1]

[1] https://debarghyadas.com/writes/why-i-left-google/

The article is from 2019 and its not that old.


Was he still subjected to same interview process where he has to prove his coding skills inspite of being prominent open-source contributor

Google don't want people who are generally great developers though. They want people with specific skills who can solve the complex compsci problems they think they have. Consequently they hire people who can invert binary trees rather than people who can just write good or popular open source code.

Google's failure to capture the public imagination is why so many Google products get killed off, so I reckon they're solving the wrong problems. If Google engineers were less inclined to think 'this is a hard problem that only very clever people can solve' and more 'this is a simple problem that needs a better solution' they'd launch more things people actually want to use.

This actually means Google would be far better off hiring the popular open source dev instead of (or as well as) the PhD in Binary Tree Gravity dev.


Yes, but my point is plenty of fairly ordinary engineers make it to L5 - it's nothing special. I feel uncomfortable going into this person's accomplishments, but other engineers I know were similarly shocked. If that and skipping some interviews is all being a leader in open source buys you, it isn't worth the extra effort from a bigCo career perspective.


You shouldn’t be shocked by that, there are similar stories where the maintainer of a project, used by most engineers at Google, couldnt get hired due to the lesser relevant leet code / design / behavioral interviews


I’m not sure I fully agree.

There are plenty of good positions (at least in Europe) where they ask for an engineer who can work with tool/Lang x, and won’t ask you to invert a binary tree, but will ask you about what kind of projects you’ve worked on.

I thought that was what you meant by #2, until you mentioned that it required “really prolific” engagement with open source.


I don't know if hire first, team match later is a FAANG thing, I've worked for two of FAANG and neither did that, I was interviewed by and hired onto the team I ended up working on.


Actually there both cases happen:

1. Team matching before hiring commitee [1]

2. Hiring committee approved but rejected because no team matched [2]

[1] https://www.reddit.com/r/ProductManagement/comments/o6gs9m/g...

[2] https://www.quora.com/How-many-people-failed-at-the-team-mat...


After interviewing with multiple FAANGs and receiving no offers, my current employer recruited me based on my LinkedIn profile for a role on new team. I have since started telling the FAANG recruiters “thanks for reaching out, but no thanks“. I guess that puts me in group number 2?


No, you're still a cattle. Until you receive an actual offer, you're always a cattle.


I had a few jobs interview recently. Here's what I got out of it:

If you have something you want to promote (or is on your CV in general), be ready to talk about it. I'm very lucky because I can talk about things on the spot very easily. If that's not you, make a list of the few main points that you want to talk about and try to memorize it. If you always get the same questions, it may be a good idea to address them before people even ask them, or to memorize an answer to them too.

I really underestimate the amount of stress that can be felt when you're alone facing 6 people for a job that you want. I don't have a good answer on how to handle it, although I think having my canned answer ready helped. It got better once this started to be a conversation. The good part is that I developed a lot of empathy for people that talk about interview stress.

It's going to be my first "real" job so these are probably obvious, but it might help someone so I'd rather share.


> I really underestimate the amount of stress that can be felt when you're alone facing 6 people for a job that you want.

Practice. Go on interviews even when you don't need a job. Get that practice in and get comfortable with it. I went on 18 - 30 interviews a year for many years when I was a contractor and got very good at interviewing over time. I still get a bit tense when the job is particularly appealing, but with practice it gets to the point where they'll rarely throw a question at you that you don't know how to handle.


> "Practice. Go on interviews even when you don't need a job."

I'm ambivalent about this kind of advice. On the surface it seems right, and I've never been more comfortable in interviews than when I was thinking "I don't need this job", at the same time interviews are incredibly stressful time wasters. For a lot of people, interviewing is one of the most stressful situations they are going to be in, barring life or death situations.

Just the thought of 18 to 30 interviews a year makes me anxious and I don't even need to interview now.

I'm not a young person anymore, and interviewing more is not going to help me either. It's like pulling my teeth: not something I want to practice.


> Just the thought of 18 to 30 interviews a year makes me anxious and I don't even need to interview now.

That was their life as a contractor. I think the advice was just to do more than zero, not necessarily go to such an extreme. You can't really hold a full-time job and do that much interviewing unless it's just tiny screening interviews.


I think it can be good to see what’s out there, and interviews allow you to ask questions to the employer too. I’ve found it can be a good temperature check of how much I like my current job and organization, are my skills competitive, what’s my monetary worth, etc.

I love the feeling of “I don’t need this job” during interviews but I feel a lot of stress when I want the job/need it for some reason. I feel for people who NEED to interview often.


Isn't that the point? Stressful experiences become less stressful as you practice and get used to them.

I used to be stressed out speaking in front of 20 colleagues or landing a small plane. Not anymore.


Ah, yes, purposefully waste people's time. Fuck them, right?

I've seen this kind of attitude before, and it's usually justified with something about how the companies don't respect your time so why should you respect theirs. The thing is... the kind of people at these companies who don't care about your time are the kind of people who would do something like this.


Sorry if I misunderstand you, but are you saying that it's wrong to interview for practice because it's wasting the company's time?

Interesting, never thought about this. I think I disagree though; these are the people who (usually) play games with you and put you through some very stressful situation during the interview. I think candidates should be able to practice in a low stakes environment, i.e. one where they can't lose because they didn't really want the job. It's only fair.

I'm not a great interviewer, but I always ask why the candidate is looking for a job, and more than once they've admitted they weren't actively looking but just testing the waters, and I didn't hold it against them...


> ...these are the people who (usually) play games with you...

I don't think this even matters, to be honest. Not only is interviewing good for you personally (as you said), but also lets the company gauge the talent pool in the job market a bit better.

Furthermore, if you have a positive experience with the company, there is precisely nothing stopping you from recommending it to your friends, should they be looking for work.

However, for the most part i agree with you in response to the previous commenter's post - interviewing is good in general, even when you don't need a job at that exact time. There's also the possibility of just reaching out afterwards, if the situation changes.


Even if you are just practicing, it's still an opportunity for the company to convince you to change your mind.


> Ah, yes, purposefully waste people's time. Fuck them, right?

as an interviewer, i'm far more concerned about the time spent sorting through piles of resumes from people who are just rolling the dice, and didn't read the job posting / aren't qualified.

maybe upper management cares about the time spent, but i'd be happy to talk for 45-60 minutes to somebody who was an even remotely passable candidate who didn't actually want a job.


Yeah, getting a company to schedule a full onsite interview panel is a big time investment, and lame if there's zero chance of it going anywhere. If some random person emails me asking for advice on how to practice relevant skills or prepare for an interview, though, I'll schedule a video chat right away and talk for hours if they want. I'll also hop on a call a few days after rejecting someone and give them detailed feedback if they want.


> maybe upper management cares about the time spent, but i'd be happy to talk for 45-60 minutes to somebody who was an even remotely passable candidate who didn't actually want a job.

Yup. If the job I've got for them is any good, if the company is good, and if I am good, they might turn into a hire anyway. That a qualified person doesn't need the job does not rule them out. It raises the bar and reminds us that interviewing goes both ways.


Whiteboarding will continue until morale improves.


I fail to understand how you equate "Go on interviews even when you don't need a job." with "waste people's time." The idea is to interview when you don't need a job so that you can easily negotiate for the best possible offer. If they won't beat your current compensation or benefits you can say "thanks but no thanks" and if they can you can say "I'd be delighted!" Nobody's time is wasted - the hiring company just has a higher bar to meet to entice you to join their team. If anyone's time is wasted it's yours when they can neither make a competitive offer nor help you to improve your skills in the interview.

If you've only ever interviewed when you were desperate to take the first job that comes along then you're almost certainly under-compensated. Anyone who's not taking a better job when they get the chance is leaving money on the table.


Yup, I've always believed anything on my resume is fair game for someone to ask about, so I should be able to talk about each thing to some extent. As you accumulate more things it can be a useful filtering tool too as you just leave stuff off you don't want to talk about or where your recollection is too hazy.

Getting into a conversation can be stress reducing for both parties (interviewers can get stressed too) though if the interviewee comes off as trying to control the discussion, interviewers pick up on that (even if they're new and bad at driving things themselves like they're supposed to) and will consider it a red flag...

I hope after a while you get to experience the other side being one of the ~6 people interviewing someone for joining your team/the company, it's pretty eye opening too. Judging someone in such a short time period given at these bigger companies is tough, and when you actually want the candidate to join you don't want them to turn down an offer because of a bad interview experience with you. If you ever get involved I'd only encourage you try to improve things -- some ideas include trying to lower stress levels of candidates, or having more reasonable/useful and typing-instead-of-whiteboarding tests of "can you even program?", but there's many possible improvements, the goal of improving on what you have is what's important. (And there does sadly need to be some sort of "can you even program?" test in the pipeline, at least at the sort of companies that do the multiple-people-all-day interviews, because the input stages are even more broken than the interviews.) Even if there are many corporate constraints on what you can do, and even if you can't get management or other interviewers on board with your proposals, you can at least make your section the best it can be.


> Build a small personal project and put the code on GitHub. Accompany it with a README with a detailed description of the project and screenshots of it in action—almost no-one does this, it only takes a few hours extra and it massively increases the impact your project will have on hiring managers who are checking you out.

Not to mention the impact your project will have on potential users. Please include a screenshot and a decent description of your project if you want people to use it.

GitHub projects I can forgive though, because you aren't usually trying to sell a project, and you don't owe anyone there anything. But even websites selling software occasionally don't have a single screenshot of it. In those cases I sometimes learn more from a Google image search than from the product website.


^ this, so much this. Please, if your project has a UI, please include a screenshot or two. I can't believe in this day and age, I still come across way to many repos (or software companies) with 0 screenshots.


> Build a small personal project and put the code on GitHub.

This has lost its effect and partially turned it upside down. In school people seem to be instructed "have a github with personal project" to improve hiring chances so now everybody an their mother has an account with a bunch of meaningless crap projects that they have 0 intetest in but put it there to try to boost interview chances.

Don't. Whenever I screen a job candidate and go to their github, if I find that this is just there so you can tick off "projects on github" from your employability checklist, you get huge minus points from me. Then better not have it at all.


How do you distinguish between "made a crappy chat app with Python+Flask because I wanted to play with Flask [and perhaps by making it public my hiring prospects will improve as a bonus, or not, but I don't have a strong reason to just keep it private on my machine]" and "made a crappy chat app with Python+Flask because I want to put Flask on my resume and hopefully my hiring prospects will improve"?

Or is it just that it's crappy enough to turn you off? If that's the case I'm kind of in agreement with the sibling that it seems overly harsh. Github-as-code-archive is a fine use case, I've never expected that someone linking their account should also be actively contributing to some projects used by other people. I'm happy just to see code of any sort, I don't care if the project is dumb or half-completed or finished or abandoned or still being worked on with a bunch of other people.

The only account that rubbed me the wrong way when I interviewed FTEs and interns was the kind that had nothing but a bunch of forks of other repos on it, no commits in them. It's like they were trying to pull a fast one on me, hoping I'd only look at it for a few seconds and think "oh lots of repos, good coder!" I'd have preferred an account be literally empty, because then at least I can believe they only linked to it out of some imagined (I hope) dumb HR filter as shallow as "has github acccount? check!"


> The only account that rubbed me the wrong way when I interviewed FTEs and interns was the kind that had nothing but a bunch of forks of other repos on it, no commits in them.

Maybe they didn't understand how GitHub works exactly? In the first weeks of me using github, I didn't notice the star feature, so I just forked a project, so I have it on my list. Even today, if I see an important repository, I just fork the repo if I'm afraid the original author will delete the repo.


That's a possible charitable interpretation, sure. Still, it's weird, the only reason you should want to link your github account is to showcase some of your work. If there's nothing of your work there, not even any gists, what's going on? I don't care if you have a ton of forks so long as there's also something of your own I can look at.


Why would you give people negative points for trying anything they can do to compete in a fucking ridiculous job market? I mean, suggest alternatives if your genuine intention is to help people find work, rather than just saying that you actively look down on people for trying something.

You get negative points for being a dick. Of course, I'm making assumptions, which you should never do.


If what you do comes across as manipulative, and specifically trying to manipulate me into believing you are more qualified, then it’s entirely rational for me to compensate for that by assigning negative points.

The job market is indeed ridiculous right now. Companies need more qualified SWEs than they can find. That causes wages to rise. Rising wages, buzz, and large numbers of openings attract more people to the field to compete for these jobs. Unfortunately, a lot of the people newly attracted aren’t fully qualified SWEs. People not qualified are rarely selected and so keep applying and interviewing. To inject some sanity, companies look for more ways to filter the incoming stream to find the signal in the noise. Applicants look for ways to make their application look more like signal. And the wheel in the sky keeps turning…


And you default to assuming that someone who wrote code in order to have something to show a prospective employer is attempting usurp the integrity of your hiring funnel. Wtf is a fully qualified SWE anyway, and how is someone supposed to get there if not by getting in the door?

Lastly, it's absolutely not rational to follow that line of reasoning. If you find yourself out of work, and discover that the interview process has changed so dramatically that your resume basically accounts for fuck all, then you need to stand out somehow. If you assume someone is automatically unqualified, you might just not be very qualified to make these determinations. Ya filter however you're going to filter, but this is just prejudice.


If somebody is trying to stand out by having a github with two projects, one is a merge sort implenentation they typed essentially 1:1 from a book during an algorithms 101 class and the other is an almost-trivial shopping list app that neither compiles nor they can explain anything about it, and then put a link to this github at the top of their resume, then they'd have been better off not having created that github account at all. It's easy to see through this nonsense and the filter of evalutating this helps avoiding wasted time of a few interview hours.

And yes, I'm totally preducied agains people with those kinds of github contents. That's my whole point.


Github is used for all kinds of things. Most of mine is forks that I used to try and issue a PR to some other repo, or gists that I use for personal reference. Likewise, I have a website that I barely use, but it's there. Neither are indicative of professional capability or are labeled "portfolio", they're indicative of some of the stuff I do in my spare time. Employers ask for a Github link almost 100% of the time, this is a problem created by the filtering process itself and the proselytizing of having a "passion" for software.

Being prejudiced towards that is as stupid as anything.

Now if someone labels themselves as "an open source contributor" or something along those lines, sure whatever be as critical as you want. I'd probably expect to see at least frequent commits to a repo that people use.


"Ridiculous job market"? The job prospects for devs in todays market is an essentially 100% guarantee that you get a job. The demand is huge and there are more jobs to fill than candidates available. You may not get into the company of your dreams, but overall, what's ridiculous is not how low the job chances are, but how high the demand is. If you do 100 interviews and 0 offers then you have an issue. It may not be your fault. Maybe it's a visa problem or some medical/psychological condition that makes it hard for people to see a good future colleague in you. But in the general case, there should be no problem getting a job if you're not too picky. Compare that to many other industries where it actually is ridiculously hard to even interview.

My suggestion is to go for quality. Only put up on you github stuff you are genuinely interested in or proud of or do. Not some mandatory exercise which is obviously only there to check a box.

> You get negative points for being a dick.

Giving you the benefit of doubt, I'm assuming this was a "generic you".


If the job market was 100% guarantee, it probably wouldn't be rational to assume that everything on someone's github profile needs to be there to try and impress you; they wouldn't need to try anything extra, or grind leetcode problems, and Who Wants to be Hired threads wouldn't exist.

I'd personally prefer a low likelihood of getting an interview, because that's way more manageable than current hiring practices where many companies hold global talent contests as the first step, and send them to everyone, as though they're Amazon.


You'll miss out on a whole range of engineers that have a life outside of work (which also brings some balance and maturity to the job), and therefore have no time (or inclination) to groom a public presence on the internet. Raising a family, going cycling, volunteering, reading books - these are all more valuable insights into a candidate for me, more so than your retweets.


Folk post this on every thread as if denying the effect somehow makes it go away. As both a candidate and hiring manager, the effect is very real and it is folly to ignore it. As a candidate, I landed a FANG job early in my career almost exclusively on the basis of my (poor quality) tech blog attracting the attention of a recruiter. As a hiring manager, I've dumped all resumes for a position and practically begged an extremely young (barely legal) candidate to interview and work for me on any terms just based on the strength of the passion found in their resume and web site.

Simon's article is expressly about how little work is required to exploit this effect. You can still have a life outside of work while presenting the appearance of being passionate about what you do during work, it's really not hard.


> As a candidate, I landed a FANG job early in my career almost exclusively on the basis of my (poor quality) tech blog attracting the attention of a recruiter.

I would be careful attributing this to your blog or thinking that wouldn't have contacted you if you hadn't had a blog. I've never had a blog, live in the midwest, haven't contributed to my Github repos in years, and I don't even work as an engineer anymore (I've switched into product management), and yet I still get the occasional recruiter email from Amazon, Facebook, and even Google. Recruiters cast a VERY wide net because most people don't respond to their emails. I'm not saying I would necessary be qualified for any of these jobs, but merely haven't a recruiter reach out to you doesn't mean much.


> while presenting the appearance of being passionate about what you do during work

Why would anyone want this? It's fake. Let's try to keep the IT world free of as much BS as we can please. Don't follow this nonsense trends.


Why? You don't need to be passionate about your work to be a great employee.

Many days I don't feel like working and I'm not motivated. But I still do (I think) a great job and try my best.

Passion is bullshit. Passion is useful in some cases, but it's not requirement to do a great job.


I think the parent comment was more about the "fake" than about the "passion" - as in, don't fake something for the sake of getting a job, whatever that something is.


>Passion is bullshit. Passion is useful in some cases, but it's not requirement to do a great job.

I strongly disagree. Maybe for other professions, sure. But to write great software requires passion. Showing up and doing the bare minimum leads to the garbage software that proliferates the world today. Not that that really matters to the individual; if you're doing what's asked of you and nothing more, then more power to you for finding a good work life balance. But you simply cannot produce top quality software without being passionate about it.


Sucking at what you do != not being passionate.

Passionate people can also suck at their jobs. I did some terrible things when I was inexperienced.

There's nothing special about software. It's like asking the builder of your house how passionate they are about building houses. What I care about is how professional and experienced they are, not their passion.


What's fake about showing initiative? I was under no illusion the young lad would be an ideal hire, but I'd have been even more impressed to discover post-hire that he'd hoodwinked me. You can't advertise for or buy that kind of intelligence


> Folk post this on every thread as if denying the effect somehow makes it go away. As both a candidate and hiring manager, the effect is very real and it is folly to ignore it.

Overwhelming majority of employed developers has literally no public presence.


Then you'll have a leg up on the overwhelming majority of employed developers. Just because lots of people don't have public presence, doesn't mean that you having public presence doesn't make you stand out. Quite literally the opposite: it will make you stand out.


Thanks - that's exactly the point I was trying to make in the article.


From my article:

> The vast majority of candidates have little to no evidence of creativity in public at all. The same is true for many of the best engineers I have worked with.

> As a hiring manager, this means you have to learn how to source candidates and interview effectively: you don’t want to miss out on a great engineer just because they spent all of their energy making great products for prior employers rather than blogging, speaking and coding in public.


People on Reddit were making the same complaints, even when I expressly wrote "It’s not a must have, but if you do have it, it’s a leg up." I think people are just rationalizing why they don't need to do anything, so they don't actually read the text of the articles/comments and just project what they want it to mean.


"Why would you make a good candidate for this position?" "I actually wrote a popular open-source app that-" "Shh... do you ride a bicycle? And do you raise children?"


I think this is a bit of an obtuse take. Doing non-coding things can give one skills that are useful in a software engineering role. Soft-skills like writing or public speaking, organisational skills, etc.

Having an outlet that's not related to your job helps keep your mind sharp and fresh when it comes to work, too. Less chance of burnout if programming isn't 100% of what you do within and outwith work.

If you deal with end-users, having a social life that involves non-technical people is a bonus too. Helps one to maintain an open-mind.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: