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?
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 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.
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.
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.
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 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.
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. :)
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.
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."
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.
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.
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.
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.
> 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.
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.
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.
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.
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.
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.
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.
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.
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?
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.
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.
>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.
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.
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.
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 ;)
> 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.
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.
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.
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.
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.
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.
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".
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.
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.
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.
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
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!)
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.)
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.”
> 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 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.
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.
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.
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.
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
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.
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?
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.
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.
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.
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.
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.
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.
> 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.
And still a mere semester at Stanford or year at Facebook still seems to stand out over all. The elite Silicon Valley institutions are extremely efficient at attracting, filtering and acquiring the best of the best. Their simple mention on a resume signals strongly to middle managers the world over that "the right stuff" has fallen into their lap, to the detriment of the rest of us.
> The elite Silicon Valley institutions are extremely efficient at attracting, filtering and acquiring the best of the best.
Not sure. Google and Facebook have gotten so large, that they had to drop their bars quite a bit.
I do agree that they are still seen as good signals on your CV. But the attraction to hiring managers might be in the same vein as the venerable 'nobody ever got fired for buying IBM'.
Having FAANG, well the A selling stuff over the internet, on your CV was a stronger thing a couple of years ago than it is now. At least my experience, but than it could be industry specific.
I always wanted to have a public gh and website that has my name on it... My only problem is that most of my non work related projects are either
a). Reverese engineering projects that may or may not be legal. I don't care at all but I wouldn't put it next to my name. Most of my projects fall under this category
b). So personal that it's very unlikely that anyone would find it useful.
c). Can only be used or even demonstrated with data that falls under strict NDA.
Do it. Even if you can only publish parts of them...
a) you could write-up just the parts that aren't (borderline) illegal
b) I think you'd be surprised at what people find useful and interesting
c) maybe you could apply a little bit of (a) to this one but even if you have to not publish about this, you'll still have something from (a) and (b)
My own experience backs this up: on the hiring side, I always use someone's personal projects as a fun discussion point in interviews (if they don't have any it doesn't count against them ... but like simonw says, it may help get an interview). On the being-hired side, I have a fair bit of tech writing and a few personal projects on my own website. I do these because I enjoy coding and learning, not because I want to get hired, but one of them (GoAWK) piqued the interest of Canonical's CTO and got me an interview and then a job.
Side projects show only one attribute that is a reason why id hire someone, which is their technical ability. Delivering on time with reasonable quality, working within given constraints, with people from other disciplines are other aspects that are as important as technical capabilities but blogging and side projects cannot convey, therefore side projects wont make you standout imo unless you built a business around it. Id much rather work with people who have another life outside tech than not.
Depends a lot on what you have to stand on. Got FANG on your resume? or NASA or something? Coast through your career if you want. Fresh out of a bootcamp or a college that isn't One Of Those Big Ones? Yea, a project is a great way to prove you know your stuff.
Having a project I was actively working during my job search was great for a lot of other reasons, too. A lot of interviewers don't really know what to talk about, hadn't looked at my resume, etc. I could quickly take control of these interviews by bringing up my project, and many interviewers would seem almost relieved to have the pressure taken off of them. This had relatively obvious advantages for me insomuch as I controlled the narrative of the interview, came off as very competent (despite having literally no working experience), and left interviewers with a good impression. All in all I consider this, along with my volume of applications, to be the most important aspect of my job search.
The opposite is also true. I work in system engineering (sometimes it's called sysops. Hybrid programming/administration, often production stuff) and I've learned to I hide my creativity.
A lot of employers want people they can understand and they can trust.
The companies I work for generally don't want someone that's creative. They want someone that's dull and reliable. Show your creative side and they'll look for someone else, even if you've got 10x more skills than someone else.
Given that creativity doesn't pay anyway (there's a cap on pay and I've already reached that cap), there's no point to show it. I can get hired based on what's on my resume alone and by answering the same set of questions they always ask.
Then I get hired, I automate everything in under 6 months and I go sit on my ass or do something else. Flaw in the capitalistic system. I know what I'm worth, I can bring across what I'm worth, but it's simply outside the bounds of what's expected or needed.
And I know that sounds weird, but think of it like this:
No one is going to pay the fastest cashier in the world 3x minimum wage. Not even if they check out customers 6x faster than the next person. And claiming you're the fastest cashier in the world during the hiring process just gets you thrown on the discard pile.
The same goes for a lot of other professions, including mine.
I've been in interview debriefs where the fact that the candidate speaks at dozens of conferences a year has been raised as a potential problem, since it suggests they may not be as dedicated to the work that needs to be done.
>I've been in interview debriefs where the fact that the candidate speaks at dozens of conferences a year has been raised as a potential problem, since it suggests they may not be as dedicated to the work that needs to be done.
You are right, that's another good example. Hiring someone that's very passionate might just not be in the best interest of the employer.
I'm sorry to hear it, but it's definitely true for certain kinds of employer. I once met somebody doing similar work to yours. Like you, he would bust his ass early on to automate everything and then be kind of bored. At one point he had two full-time jobs where he had done that and he still had time to play a lot of video games.
I hope he found an employer who could really challenge him, as he was happier during the initial phase of hard work. But I wouldn't be surprised if he never did.
What is it called.. Market failure? It's got a name, I don't remember it.
The job market doesn't support certain overqualified people. I gave you an example.
Rationally, you'd think that a cashier that works 3x faster than other cashiers can make 3x the income. Or even 2x.
A plumber could do that, or a woodworker (they might have to start their own company, but they can do it). But a cashier relies on employers and they're just not going to pay a cashier that much. Cashier being an example. There are many support jobs were it just doesn't pay to be good at your job.
These people are technically incentivized to be mediocre. And they often are. Some of these positions allow growth paths, but not all. And just because I'm the world's best cashier, doesn't mean I'm a good store manager.
> Rationally, you'd think that a cashier that works 3x faster than other cashiers can make 3x the income. Or even 2x.
I don't think so, because a cashier's main job is just to wait for customers to show up. They are faster at clearing bottlenecks when a lot of customers show up at once, but they don't handle anywhere close to 3x as many customers over the course of their entire shift.
That's going to depend on the store and the shift.
I'm sure you understand that I gave an example that's easy to understand and I'm not trying to discuss the intricate details of being a high performing cashier.
If it's really needed I can come up with a different example, but otherwise just assume it's not a neighborhood pet store, but a very busy and successful supermarket with 35 check out registers that are always busy.
But you can just as easily swap it with an overqualified dentist assistant that provides a massive value by detecting things the dentist misses.
Or a engineer at a mine that's so damn good, that he repeatedly detects machinery failure 5 minutes before it breaks catastrophically (and some of these machines cost millions).
Or a bricklayer that lays three times faster than any other bricklayer. It doesn't matter.
The point is they are supportive roles that can't function independently of the corporation, yet will never receive a salary that's proportional to the value they provide.
> 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.
This is one of the key things I pointed out in a post I made after going through a lot of co-op resumes and interviews[1]. A little documentation and attention to detail goes a long way! If someone looks promising I DO look at their LinkedIn/GitHub/Website because it gives me some indication into their capabilities and whether they're willing to go a little above and beyond (to learn or present themselves more professionally online). I know not everyone has the time to do this (I have a 7 year old and don't have a great online presence) but if you're trying to start out in this industry it should be the minimum you're willing to do.
That discussion was part of my inspiration for writing about this.
The point I'm trying to make here is that the idea that you need to invest vast amounts of effort into side projects in order to increase your chances of being hired is misleading.
But... putting just a small amount of effort into having e.g. a couple of blog posts and a single public project on GitHub CAN give you most of that value.
Hiring managers faced with five candidates, one of whom has a blog post about the technology they are hiring for, are more likely to bump that candidate through to a phone screen or interview round.
But if that candidate only made the blog posts and put stuff on github to help them get work, and not, say, because they were interested in the subject?... Then that becomes a reason to ignore their blog and github.
> “Oh God,” they answered. “No, anything but that. Nothing says ‘person exactly like every other bright-eyed naive new doctor’ than wanting to help people. You’re trying to distinguish yourself from the pack! [...] Okay, tell you what. You have any experience treating people in disaster-prone Third World countries? [...] Talk about how you want to become a doctor because the people of Haiti taught you so much.”
> During my interviews, I talked about my time working in Haiti. I got to talk to some of the other applicants, and they talked about their time working in Ethiopia, or Bangladesh, or Nicaragua, or wherever. Apparently the “stand out by working in a disaster-prone Third World country” plan was sufficiently successful that everyone started using, and now the people who do it don’t stand out at all. My interviewer was probably thinking “Oh God, what Third World country is this guy going to start blabbering about how much he learned from?” and moving my application to the REJECT pile as soon as I opened my mouth.
Honestly that wouldn't make a difference for me. If it was obvious that they had only put up blog posts to help them get work, but the content of those blog posts was good, they'd still bump themselves up my list of candidates compared to candidates that hadn't done that.
The signal I'm looking for here is proof that the candidate can write, can think and can do some aspect of the work. A resume usually won't prove that to me on its own.
Sure, ok, fair enough. p.s. I did enjoy the article, thanks for that. :-) It's encouraging to be told you don't need to feel like you need a gapless decade on github and/or blogging, that anything is still something.
> But if that candidate only made the blog posts and put stuff on github to help them get work, and not, say, because they were interested in the subject?... Then that becomes a reason to ignore their blog and github.
they only wrote their resume to help get work, not because they're... i dunno, interested in resume writing. should i ignore their resume?
it's all just a source of stuff to talk to them about.
It's hard to believe you're arguing in good faith - you allow that a resume is written only to get work and so consider it, but if they write a blog only to help them get work you dismiss it with the reason "they only did it to help them get work"? How is that consistent?
It's not something you screen for - as I said in the article, "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"
But if someone has it, you're likely to take it into account. So as a candidate it's useful.
In the article you state "you don’t have to put very much work at all into public creativity in order to stand out as a job candidate". This implies that when I am acting as a hiring manager I would be screening for "public creativity." I'm trying to understand why I would want to do that. I've been a hiring manager for well over a decade and it's never been something I thought I should screen for. Indeed, in my career the majority of the best coworkers I've had have had little to no public presence online and I can think of at least one counterexample of a person who was extremely prolific with blogging and giving talks at conferences who happened to be absolutely garbage at their role. There is some underlying assumption in this article that I'm not grokking.
> I can think of at least one counterexample of a person who was extremely prolific with blogging and giving talks at conferences who happened to be absolutely garbage at their role.
My employer once hired someone into a leadership role who we all knew from conferences and press coverage. We were pretty excited to land such a high-profile guy.
Turned out, he spent most of his time prepping and going to conferences, and working on his press coverage. Very little actual work got done, and we quietly parted ways with him in less than a year.
In retrospect, it’s a bit of a “well duh” moment, connecting the dots. But at the time, we all just assumed that there must be incredible substance for him to have such a high profile.
I took a big lesson from that: people who are good at building an audience would be a great hire if you need to build an audience. If you need something else, don’t assume the audience (or conference organizers, or reporters) have actually vetted that person for the skills you need. They probably didn’t.
Ultimately, he ended up as an executive at another company, with responsibility for raising their profile and finding new clients. His skills and inclinations are perfect for that.
Yea, it took me a while to realize that the people with amazing stage demos multiple times a year have optimized their career for amazing stage demos; they effectively have a different career than practitioners. Presenting at conferences is not a 10 percent time project you do while supporting the company as an SRE the other 90 percent of the time. You have to spend time developing talks, pitching them at open RFPs, and rehearsing them that a pager somewhat precludes.
I can picture someone who fits this profile to a T. I’m sure it’s not the same person but now I’m thinking about how many people could fit this description.
Obviously there is a market for these people to exist and for companies who want to pseudo acquire their audience.
I wonder what the total number of these folks are in our industry and worldwide…
I tried really hard to make it clear in this post that as a hiring manager it is your job to find great candidates who don't do this. So you shouldn't "screen" for this, in terms of filtering candidates based on whether or not they have evidence of public creativity.
But... of course I look beyond the resume that the candidate has sent me. Which means that, as a candidate, a relatively easy way to stand out is to have a small amount of public creativity on display for hiring managers to spot.
Sometimes a candidate might interview poorly because they get nervous... but there's clear evidence out there of their skills and experience which can help guide a second round of interviews that help avoid missing out on great talent.
IE, unless the role is explicitly "go be the face of the company and smile on youtube and praise our products and their awesomeness", no one cares about your github resume since they've barely looked at your resume before the interview. Just try and demonstrate you know what you're talking about during the interview and can relate some real world experiences in a sane manner, and you're halfway there.
So the advantage in doing this is for candidates that don't interview well? That doesn't jive with the statement in the article that "you can give yourself a big advantage in terms of standing out from the crowd with a relatively small amount of work", which seems to imply that a hiring manager would prefer candidates with blogs or a twitter audience. When I'm reviewing resumes and someone lists their blog or twitter handle on their resume, I'm going to assume it's because they don't have concrete accomplishments to point to. It's not going to rescue a candidate who has a weak resume from being passed-over and it's not going to compensate for a candidate who made it to the technical interview but then couldn't solve the assigned problem. It's nice to see when someone posts a really great piece of code in their github, but I have no way of knowing whether they were even the person who wrote the code or not, so the technical interview is their chance to show me they have at least a basic grasp of coding. If they fail that, there's nothing short of a ten thousand star project in github that might make me reconsider a poor performance in the interview and that's never happened to me before. So I still don't understand the premise that candidates with a public presence should stand out more nor the premise that if I'm a candidate a small public presence would help me. I could be wrong - it could be that most managers like to see this sort of thing, but it's never been something I've screened for and I've yet to be convinced I should start.
I'll rephrase the GP's question because I'm also curious, and I don't feel your response answered the question.
Is there a signal which suggests that "public creativity" equals "good engineer", particularly when the resume already speaks for itself? Or is it purely to compensate, as you suggest, for a possibly poor interview performance?
I'm honestly skeptical that such a signal exists (but can be convinced otherwise), except insofar that a person may be invited to give talks _because_ they have demonstrated strong engineering skills or talent -- whereupon, yet again, their resume should speak for itself.
I don't believe that public creativity is required for a good engineer.
I do believe that candidates with public creativity are more likely to make for a promising interview. Thinking back, I can't remember many cases where a candidate with some evidence of public creativity bombed the interview completely.
So if the hiring manager does not screen by this, what should I bother then? It does not give me any advantage because you are stating you are not screening for it for FOMO great engineers. Just in the eventuality of a tie? I doubt 1-2 blog posts will be the deciding factor.
For me, they will be. If I have ten candidates and only one of them has 1-2 blog posts about a technology I am using, that candidate is going to be one of the subset that gets an interview.
The amount of information available on candidates to hiring managers is extremely limited. Evidence of outside creativity is a pretty good sign that someone is not a bozo.
When I was a founder it was incredibly hard to find people who are "available" and skilled because they feared listing themselves as available on LinkedIn.
When I'm not a founder and skilled it's incredibly hard to get to hiring managers. Usually I get warm intros from people within companies I'm interested in, it works way better, and usually often results in jumping straight to the on-site interview step.
Why isn't there a central website where you can just post your name-redacted-resume, accomplishments, and (optionally) target location and salary range anonymously, and if someone wants to reach out, then you can reveal your real name and e-mail?
Or better yet a Tinder-like interface where companies swipe candidates and candidates swipe companies, albeit with no photos, just a name-redacted resume?
This may not provide you with the desired results - you usually want to hire people for their technical skills, not how good they are building an online presence and marketing themselves.
Again - I fail to see how the second part is derived from the first. If I'm already engaging in a screening process, wouldn't it be better to ask the candidate to solve a problem that relates to their role than to ask them if they've done any blogging on the topic of tech?
Because it gives you a more rounded sense of the individual. Other passions. Other ideas. Areas they’ve worked in unrelated to your problem.
Job/coding interviews are very difficult to do well, and many people such as myself tend to perform poorly due to the stress of the interview (so much that I’d rather stay in a mediocre position than go through the agony of interviewing — I hate it with every fiber of by being, and it correlates 0% to my in-job performance).
It’s just more data, which is especially useful if you’re on the fence with someone. You can also see creativity which isn’t something you can test well for in an interview — especially technical interviews.
My ability to solve an artificial problem on a whiteboard time limited with a gun to my head correlates directly to my job performance?
Not only does it not in my case, I don’t know how you could even make such a claim without knowing me, my work, and how I perform in such interviews… and that’s just me. Much has been written on this subject with similar anecdotes as well as quantitative research done by Google’s HR department. Clearly 0% is an exaggeration at large, but it’s well documented to be a poor correlate.
Being able to write and communicate clearly is an important skill for software engineers, especially in senior roles - and it's something that's difficult to evaluate in an interview setting.
Interviews don't tend to include writing - and strong communicators who get nervous during interviewers may end up at a disadvantage.
I think you're missing the "stand out" part of this.
I've done a lot of tech interviews lately, which is where I get at ability to do the work. But when a hiring team is trying to pick among the people who do approximately as well on that, then other factors can help.
At that stage, I definitely like to see things that indicate people are excited about something enough to just make a thing (a library, a small project, a blog post). If that's related to our domain or tech stack, even better. But even without that it's a plus in that it's a sign I can just give them a user problem or a technical issue and trust they'll go off and do something good with it.
By the time you've gotten someone in an interview you've already committed a huge amount of effort towards them. Seeing a cool project someone made is a very strong signal that interviewing them won't be a waste of time.
I'm not sure. There does seem to be a pretty significant increase in selection criteria for a lot of things, from hiring to investing, that biases heavily toward rewarding "influencer" and/or "celebrity" traits.
I’ve been told in the past by hiring managers my resume (at the time) was too creative. And later by hiring gurus that you need a creative resume to be noticed. Noticed doesn’t necessarily get you the job
The more experienced you get, the harder it is for any one interviewer to really grok your breadth and depth. This is doubly true in youth-biased tech cultures like Silicon Valley, and quadruply true 12 years into a bull market for tech.
At some point the game becomes: read your interviewer and tell them what they want to hear.
There's a different interview strategy for every middle manager under the sun. Engineers want a single algorithm to land them a job. Middle managers want someone they get along with to maximize productivity and minimize trouble, and that's a target that moves with every interview.
I have a Wikipedia blog. Been doing it for over a decade. I post articles I find interesting, categorize and tag them, do some light copyediting, find/create a 300x300 pixel image to illustrate each, format them in a digestible feed, and added a random button.
For years people asked me why I bothered. I did it because I love Wikipedia and wanted a record of my wikiwalks, but it has also become a fun example of my style and interests to show prospective clients.
I agree with this - if you're a student or just starting in the workforce. However, a lot of companies in the industry have IP agreements that prevent you from sharing code in public - and there have been cases where companies have told employees to stop work on their personal projects/stop contributing to open source because of this. Some even restrict public comments to social media or participation in online discussions.
Now a lot of people, including me, have a Github and contribute to open-source using a anonymous screen name. However that also means that prospective employers can't use this to find me, and that I can't really mention these projects in a job interview.
I'm just surprised that no one has mentioned this here, as I've seen quite fruitful discussion on HN before on such agreements and am surprised this hasn't came up. I know some employers that would definitely tell you to cease work on your (publicly visible) Github projects once you are hired if you mentioned them in your interview.
Is a doctor also going to publish achievements?
A construction engineer should he/she publish calc of beam dimensions?
A carpenter how should he/her show creations. If it was doors or windows installed in people's houses. Something is wrong here in this industry.
I think the crux of the matter is that for almost all other such professions (MD, Engineers, Lawyers, etc.), there is a more formal type of gatekeeping when it comes to recruiting.
Education, licenses, and similar - often in combination.
The world of software development is MUCH more open to people that necessarily don't have the correct formalities, because there's a common knowledge that there are tons of talented people that never studied CS / Software Engineering / etc.
That, combined with high pay, of course attracts a lot of incompetent people.
So what would the solution be, to require all "professional" developers to have a degree and/or some professional license? I mean, yes, it could work - just look at the Cisco certification system. Some of those are quite rigorous, so the networking industry knows that if you hire someone that hold certain certs, they're probably competent.
But, then again, most the certifications boom of the 90s kinda died out.
That's why we're stuck with the grinding leetcode + technical interviews + side projects situation today.
Id rather grind leetcode and system design problems and get credentials for it and dont have to again. Wait.. thats what my university degree was for..
Yes - but for some reason, there's this extreme (irrational?) fear that imposers might have coasted through Uni., and you get these infamous blogs and articles stating that "comp. sci graduates can't code anymore! candidate failed fizzbuzz!", and everyone seems to have their own anecdote about that one co-worker that couldn't code themselves out of a wet paper bag.
It seems like we're in a situation where companies would rather pass on 10 competent devs, rather than hire 1 incompetent dev.
Personally, I think most of the above boils down to bias. You only remember the best and the worst coders you meet in your life, as far as work quality goes. And those are outliers. Coding interviews are stressing, so you can end up with competent candidates completely blocking due to the stress, and thus failing trivial problems.
Anecdotes seem to be the gold standard, as far as evidence goes.
Every contractor I've ever hired to work on my home has a portfolio of projects they can show. Modernized folks have them online, old-school folks have binders they'll bring in to show you, but they have them, and will also provide references. As will doctors, BTW, especially surgeons. Asking to see examples of prior work is in no way unique to technology.
Depends. If you’re a framer they just want to know if you have tools and when you can start. If you’re a lead it’s important to know stuff like how to square a foundation and calculate stair risers and hips/valleys, and you should be familiar with different hardware and where it goes. But nobody is going to ask you about which cracker-jack spec houses you built at your last job.
Yes but at some point there will be a position such as 'senior doctor of whatever' and having a medical licence would be taken as a given, and yet there will be some competition for that place.
I don't know really if these discussions are around hiring for your average SE role or something more specific though.
My experience has been that if you're interviewing for a younger, or more modernized company, then side-projects and such can be a cool thing to talk about.
But if you're interviewing for some F500 dinosaur, your CV is all that maters.
We’re actively encouraging peacocking. It’s no surprise since it’s the current pattern in social media, and obviously it was bound to seep into tech.
‘Keeping up with the Johnsons’ scaled like hell in the digital world. We all know it’s bad, but here we are. If you can’t beat them, join them, and let’s just keep making the world shittier.
The main reason why this line of advice (original tweet) is bad is because it is self promotion for the sake of self promotion.
Here’s a quiet solution:
Have a small website and a projects page. Describe a few of the projects and what’s interesting about them. Then send it to the company. It’s no one else’s business.
My point here was meant to be that you DON'T need to invest a huge amount of effort in peacocking. Just a small amount of effort in ensuring there are public examples of your work out there is all it takes to get a boost against other candidates who haven't done that.
A small website and a projects page is exactly the knid of thing I'm suggesting here.
But the active promotion via the social channels is what sets off the ‘keeping up with the Johnsons’ effect. Some people are so shy that they would never consider advertising like that. The peer pressure builds, and suddenly you have a generation of self conscious people maintaining appearances.
Just because you stand out doesn't mean you stand out in a positive way.
The idea that every piece of writing or open-source code you produce in public will be seen as a positive by everyone out there is patently absurd. Yes, you can put "creative" stuff on your resume. Some companies might appreciate it, many will ignore it, and most will judge you for it.
One obvious outcome of putting your blog on your resume in today's environment is that you will have to scrub it of anything anything even remotely controversial or unusual. You will have to constantly self-censor from that point on.
One unintended consequence of this advice being widely followed will be a lot of (or, frankly, "even more") write-only projects appearing on Github. As an interviewer I wouldn't be against this metric, but I would prefer to see that it wasn't too obviously gamed. You'd hope that the public creativity was pursued for intrinsic reasons (interest in the topic) rather than extrinsic.
I'm not saying that people shouldn't get hired if they don't have some huge repo that everyone loves, just that this shouldn't turn into some new thing for people to desperately grind.
At the very lowest level, I'd expect to see a lot of plagiarism and projects that are barely competent rewrites of someone else's work. I often go searching for various exotic keywords and often see fragments of things that I've worked on "written up" in almost entirely content-free blog posts; more likely to attract clicks rather than interviewer attention, but still.
In my experience none really cares about your side projects during interviews. I have plenty of side projects, given plenty of talks, I list some of those in my resume along with my github link, yet from 40 interviews I had in the past 5 years I think ~3 mentioned something about my talks and side projects. And definitely didn't give me any advantage over the other interviewers.
But I am fine with that, I do my side projects & talks because I enjoy it and not to increase my chances when applying to a new job. Although there is nothing wrong to do a side project to increase your chances to get a better job.
Really? I have a blog (not very active) and two android apps (not popular). I do think the apps help, but I don't think that really makes me stand out. Most places value creativity second to output.
Any time I've been screening candidates I have taken this kind of thing into account.
If I was hiring an Android developer the fact that you have two Android apps would absolutely play into my decision process - it would increase the chance that you'd get to an interview, and I'd very likely ask about them during that interview.
I mean, it could be helpful, but my guess is that you would go with someone who has worked on it professionally. Plus you would probably want someone with more recent Kotlin experience.
I'm hiring for a relatively small cross-functional team that has to deal with a variety of work. One of the characteristics we need is people who are willing to step outside their technological comfort zone and just make something work. We have no mobile code and probably won't, but I was still happy to talk with somebody who'd built a couple of iOS apps for fun. It was a sign they were enough of a self-starter that I could trust them to learn on the job when that was necessary, and also that they could think about user needs and how to solve them.
It's true that some places basically take the resume of a current engineer and try to clone them by hiring an exact technology match. I'm not sure if that gets them better results or it's just something that's easier for a cumbersome recruiting process. But consider that maybe those are places you wouldn't be very happy anyhow.
"One of the characteristics we need is people who are willing to step outside their technological comfort zone and just make something work."
Honestly (and no offense), this sounds just like every place. My current job expects me to be full stack on multiple stacks, be the application security champion, and provide rotating (1 week every 3 weeks) prod support for about 10 apps that we own. And it's a mix of legacy and somewhat newer stuff, so DB2 to Dynamo, JSF to Angular, plus all the no-code stuff like Tableau. I feel like this is a huge efficiency drain. Did ECON 101 stop staching about specialization of labor? I'll never be an expert when split across 10 different technologies. I have a bad mid year rating because I'm "slow", but it shouldn't really be surprising when I'm context switching all over the place.
I would love a place that says "you will do this one [tech/language/stack] 90% of the time". As soon as a posting or manager starts talking about a plethora of tech that I will have the "opportunity" to work with, I mark that as a potential red flag, it's really just a matter of magnitude since they all do it.
The last large company I worked at had specialized per-technology teams. The IOS devs would be on a team with other IOS devs. Android with Android, web with web, back end with back end. My boss was seen as unusual for just trying to get different kinds of engineer on one team, even though they'd still specialize.
I do think there's a difference between "this is a small team, so we all need to cross-train enough so that we don't have silos" and "we're a large company that never cleans up a mess, so you'll have to be able to work with the code from 7 different half-assed projects going each going back 1d20 years". There's no excuse for the latter, and I'm sorry you're in it.
It makes the job of the person referring you so much easier. If we agree that getting a referral is the easiest way to get a job, which I think it is, then making the job of the person referring you is the most important thing.
If they can talk about you for a couple of minutes and then email their boss a link to a well written blog post, you derisk the act of referring you. You allow the boss to sell himself by providing the material, so your friend isn't on the hook as badly.
I've interviewed probably >100 people and maybe 7 or 8 had anything interesting that I could look at publicly on their resume. It doesn't even have to be job-related. It's cool to see a website that's just photography or motorcycle customization or whatever. It helps me get a handle on the person I'm interviewing as an individual, maybe gives us something to talk about.
I don’t even think it needs to be technical. A friend posted a jokey video he made in college introducing himself on his website, beside his resume, and he says recruiters often say they contacted him because the video was funny. He’s obviously qualified too, but it just helps him stand out.
Recruiters read so many CVs in a day that at some point they all become irrelevant. Has anyone here tried TikTok's new resume feature where people apply to jobs recording a video of themselves on TikTok?
I have a feel having a nice to read and simple layout (one that when recruiters copy and paste into their template without your contact details) might matter just as much!
My job opportunities are limited to what my real connections and friends can help me get.
If I want to expand my opportunities I have to add nodes and strong ties in my network.
Not gimmicks for the interview lottery and pray the hiring manager doesn't have a friend going for the job.
From my past positions I suspect people highly underestimate how many times they go on an interview with no real chance for the position because the hiring manager already has someone in their real network in mind. I mean a real friend or friend of a friend, not someone they just added on social media but don't really know.
> You will jump straight to the top of the hiring manager’s mental list, maybe without them even noticing.
That sounds like an unconscious bias that you should fight rather than indulge.
I've interviewed hundreds of candidates for FAANG and I intentionally don't look at their CV to avoid biases. Personal projects can help with the interview if they are relevant, but I'm conscious about not "punishing" candidates who don't have any of those.
Interviewee: Check me out! I wrote a NES emulator that is cycle accurate and supports a game with a specialized chip that I reverse engineered that no other emulator supported.
There’s a large spectrum of quality of public content out there. You could say the same thing about any resume.
But that's a counterexample to the OP's thesis that "it doesn't take much". An "NES emulator that is cycle accurate and supports a game with a specialized chip that I reverse engineered that no other emulator supported" is a MASSIVE undertaking that would take a huge amount of time and effort. I would certainly give a candidate like that a second look - if NES emulators were remotely related to the kind of skills I was looking for.
You're presupposing that the hiring manager would be able to tell what skills are involved in making an NES emulator, or even what skills they are looking for.
I think you're taking the post's 'it doesn't take much' too literally, and the 'I have 239 twitter followers / wrote an emoji generator' reads like a straw man argument. Of course that wouldn't be impressive. The article mentions putting screenshots into a README on a project, but doesn't mention what the project would be... clearly if you're being judged from public information, the less impressive it is the less impressive you'll sound.
This is an interesting post - though it saddens me. It seems modesty is going the way of the dodo. Though it leads to an interesting quandary - is it possible to have an online presence and still honestly call yourself a modest person?
To elaborate - my issue with this post is that it promotes the further commercialization of activity. If you’re doing it because you want to, then you would’ve done it already.
This post basically says, “hey, you - person who probably doesn’t do it, do it and you’ll have an advantage!” IMO it promotes further insincerity, not to imply that those who do have a presence are insincere.
> It seems modesty is going the way of the dodo. Though it leads to an interesting quandary - is it possible to have an online presence and still honestly call yourself a modest person?
If by "modesty" you mean not bragging and not presenting yourself as better than you are, that's absolutely a desirable quality. And that's perfectly compatible with publishing your work.
If by "modesty" you mean keeping your work unpublished, or presenting yourself as worse than you are, that's neither a useful nor a desirable quality.
The article here talks about posting a project to GitHub with a README and screenshots, or having a technical blog with some articles about things you've learned or worked on. That seems perfectly reasonable.
> If by "modesty" you mean keeping your work unpublished, or presenting yourself as worse than you are, that's neither a useful nor a desirable quality.
To be fair, historically the entire point of modesty was to present yourself as worse than you are (historically this was done with attractiveness specifically).
Has modesty taken on a new definition where it means simply not bragging? I honestly wasn't aware.
I don't see much value in arguing over the definition or intepretation of the word "modesty", beyond the degree to which that started this subthread in the first place.
I'm suggesting that either you can interpret modesty as a positive trait (moderation, unpretentiousness) that is perfectly compatible with what this article suggests, or you can interpret it as a negative trait, or you can interpret it as an entirely unrelated trait. But anything that suggests you shouldn't publish your work is unhelpful and not something to admire or aspire to.
In reality, modesty is not used in the way you say it is. You call someone modest when it is a slightly negative trait. You would otherwise call them unpretentious or humble.
Posting on GitHub and having a decent internet presence seems like something a humble person may do, not something a modest person may do. A modest person would have all of their code on private servers, or would have nothing impressive associated with their public/resume persona.
That's exactly the point I'm getting at: to the extent modesty is incompatible with publishing your work, it's not a positive trait, and nobody should lament it "going the way of the dodo".
(I was, earlier in the thread, attempting to find a charitable interpretation of modesty that was compatible.)
>historically this was done with attractiveness specifically
And money. Mostly money, at some times and places. Many examples of ostentatious displays of wealth being discouraged or forbidden. Lots of good reasons for that, social and individual.
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.