There are also job descriptions that do not state whether it is a remote job or where on the planet you are expected to work. City, state, country? Anything? You go to their website and also no address or clue of where the company is.
"The next part of your assessment will take place during your follow up phone interview at a randomly chosen time slot between 10pm and 5:30am this night. Please remember to hold yourself ready. Thank you for your time and have a pleasant rest of the day."
I also learned lately if they wish to record the interview, it most likely is for their benefit to prove their "interviewing" other candidates. I had an experience earlier this year with a famous/popular "equity firm" that when I refused and asked if they were recording beforehand, went on a tidbit about how they needed too/it's normal.
Some kind of minimal helpful feedback upon request after an unsuccessful on-site is the big one for me. The hiring manager can share one sentence of filtered feedback with the recruiter, the recruiter can share that one sentence with the candidate over the phone. Five minutes per candidate all in. If you say "but legal liability" you have no courage.
I don't see why companies can't have some kind of waiver the candidate signs in order to get feedback. We already sign NDA's before most interviews to not provide the interview questions and stuff to people. Feels like something we should be able to trade for.
Best case scenario, they get some good word of mouth... which doesn't matter as FAANGs have more applicants than roles anyway. Worst case scenario they have an angry rejected candidate attempting to dispute the feedback. I doubt any large tech company would consider doing this.
I've always had an interest in giving people feedback and have pushed for it at a few employers. What I've been told -- and I have no way to check this, considering I am not a lawyer -- is that giving post-interview feedback is legally fraught, contingent on the localities involved and would impose a review burden on the feedback which would, necessarily, be delayed by some weeks, carefully scrubbed and written.
Dunno how accurate that is, but I've been told it at more than one shop.
I was surprised that I got feedback from my recruiter a few weeks ago when I finished an on-site at Google. To be honest I think she was only fine with providing feedback if we were on a call, since there's no paper trail.
No thanks. What I'm interested in is a _structured_ program for providing feedback and going off-script into potentially legally problematic territory as an individual doesn't tip the cost/benefit ratio in the right direction.
Again, like I said in the comment that this parent comment replied to: provide a waiver that basically says the candidate can't use the feedback legally. It's a similar thing with the NDA on the reverse end.
Firstly, NDAs and waivers are not bulletproof and may not hold up in court. And even with a rock-solid NDA guaranteeing a victory, going into a courtroom is not a desirable situation for any person who isn't being paid to be there.
Like I asked in the comment replying to your previous one: what benefit does this give the business whatsoever? This will cost money, time, and very possibly headaches (whether reputational or legal), and for no benefit to the business. Why would they consider this?
Common courtesy? Same with being nice and polite, saying hello/goodbye, etc. It wastes time because you could get to the point faster but it’s nicer and makes the interaction more pleasant. That’s it. No other reason. Just make the world a slightly better place with a tiny action.
I’d love for this to happen, but I feel like the outcome here may be someone signs one of these and gets told “we didn’t hire you because you looked like you were [protected class]”.
In my experience, interviewing for engineering teams is an afterthought that comes from how little interviewers are included in designing the interview process they have to use. When I approach each opening like a software project with a kickoff, buy-in from everyone working on the project, assignment of tasks, etc, you get more investment from the interviewers. You also get higher quality candidates making it past the recruiting stage, because the recruiters better understand what to look for. Without that, I think most engineers view interviewing as something that takes them away from their "real" job.
> Without that, I think most engineers view interviewing as something that takes them away from their "real" job.
This. I don't want to view interviewing as a thankless chore because I think it's important, but hard to view it any other way when your interaction with any given new hire will be minimal at best - especially since the extra work of interviewing usually just ends up as a footnote come review time. If you want people to take interviewing seriously, give them some skin in the game.
I agree - for me the idea of shared pipelines is what kills a lot of the motivation - I don't who what the person will be working with, what on, I might have a passing familiarity with another interviewer (but most likely not) - it's difficult to treat people as anything else than a calendar appointment.
>I’m exaggerating the amount of skill that I have. Everyone is. I use the right buzzwords on my CV. I inflate the scale of my achievements and the depth of my skillset. I even add tasks and responsibilities to historical jobs that fit your requirements. You’re never going to check, are you?
I don't, I'm honest in my CV and during interviews
I'm selling myself 'as-is' e.g despite using git for longer peroid of time, but mostly via GUI, then I'm not going to call myself proficient/experienced git user cuz I'd fail some above basics question
I don't exaggerate or list things I don't have significant experience with, but a relative who's in recruiting keeps telling me I'm doing it wrong. But I think they mostly do recruiting for big companies with bad automatic filters or people who don't understand the job doing the first weed-out pass on the résumé pile, so maybe that's why.
The recruiter's interest and yours are not aligned. Recruiters would like everyone to list every skill on their resume. They have nothing to lose from you being interviewed for a position you're not suited for. And they get paid if you get hired into something that isn't right. Both these outcomes are less good, for you, than being interviewed less and only hired into jobs which are right for you.
no, they get paid when you are hired. but the more people they send to interview, the more likely they are to get a hire, whether a good one or an indifferent one.
I put as little as humanly possible on my CV to reduce the chance of getting asked about stuff I have pretty much completely forgotten about.
I hate preparing for interviews and don't want to brush on my past. For example, I spent a year writing an LLVM backend for a DSP but I'm pretty sure I couldn't write more than a fizzbuzz in C++ now. Nor do I remember much about LLVM. I don't want to come across an LLVM enthusiast and have him start grilling me on details I have long forgotten.
I try to write just enough to get an interview, anymore information makes you more likely to fail your interview in my book. Plus writing less makes you mysterious ;p.
Most resumes I see have both a skills section and some sort of work history section. You can keep advertised skills focused while still listing past projects and work if you use a format that makes a similar distinction.
My problem is the skills section isn't going to match up with the experience section, most of my technical knowledge came from just screwing around and trying to hack/fix stuff. Most of my professional career could be described more as "code-monkey if that".
Last job search was depressing. I wanted to actually stick with it, and find me a job I actually wanted (as opposed to the same thing I've been doing for years + some more money). However nearly every job I applied to I got ATS screened out of, meanwhile the recruiters kept coming to me with more money for similar crappy jobs and I folded. Well either that or recruiters that never even read my resume spam me. I've been getting spam for RoR positions, I haven't touched ruby since 1.9 ad have never had professional experience with it.
What about: "LLVM (year 1970, mostly forgotten now)" -- a good judgement impression and showing the recruiter that you can (re)learn such things should you want to?
And to add the other side of things: as an interviewer, I do check.
Inflating your skillset is going to get you into the wrong interviews, and you'll do poorly in them (and consequently will have these kinds of negative experiences). Either accurately represent or slightly undersell yourself; it comes off much better and will save you time and money.
I hate embellishing on resumes. Unfortunately when the game went from humans filtering resumes to automation/keyword filtering, it's and unfortunate requirement. Sanitation Engineer and all that.
Required keywords "Agile/Scrum" does not appear on this resume, rejected.
Required keywords "Agile/Scrum" does not appear on this resume, rejected.
Is it really that bad now? If I were applying for employee roles today it would probably never have occurred to me that including "Agile" as a buzzword could be important to avoid getting filtered immediately. I can understand filtering someone for having no apparent experience in the main programming language you use if you have many other applicants who do. Filtering for something that basically every employer has claimed to do for about 200 years but no two of them would agree on what it means seems silly though.
This is not universally good advice. An interview is an obstacle that takes a limited amount of time. It can only approximate someone's true skill set.
One can oversell themselves based on their potential to learn and grow.
For example, if someone is a junior and they designed a micro-service with a senior but have a solid grasp of the process, then it's fair that they claim that they designed a micro-service. They can read up on the relevant concepts, answer a few questions in the interview and get a very nice opportunity in a cool startup. If they can learn to do it fast enough to be productive, then both they and the company are happy.
On the contrary, by underselling themselves or being accurate, they are more likely get a job at their current level of knowledge, which can limit their growth potential. Still, this can be a good idea if someone is already very experienced and doesn't want to spend a lot of energy to grow.
I've also gotten positive feedback for clearly stating what I know and what I don't know. I'm using a „skill meter” to distinguish between „I'm an expert in this language“ and „I've used this a couple of years ago“.
I got a job offer from a company whose main language is Go and I didn't even know the basics. A good software engineer can pick up any reasonable language in a reasonable amount of time [1].
I usually ignore recruiters who don't contact me via InMail. If they convey that they actually took a look at my profile, I'll reply.
I've had a very good experience with the three EU companies that I've been interviewing with this year. One had a take-home assignment that was reasonably scoped for 2-4h and well thought. The others asked some basics and some architechture / design / business understanding related questions. No leetcode or whiteboard coding. Open communication + quick feedback.
Was I just lucky in that regard or are there a lot of companies with a sane interview process out there, but some HN readers prefer to apply at those who don't?
Most of us probably don't interview at a statistically significant sample of companies, so I guess it's hard to say. For the record, I recently did three tech interviews for tech lead level roles.
* Company A: Small startup in a non-profit space. Technical part was an informal chat with a current tech lead, which led to them sending me a list of high level general questions around architecture and design to be discussed on a follow up call, then it moved on to a third non-technical round. Good approach overall, I appreciated being able to prepare in advance instead of being given a pop quiz, and I think it unpacked my skills pretty well. Total time maybe 3 hours? It led to an offer.
* Company B: Medium sized ecommerce company. Technical part was a live coding challenge via screen share, with a tech lead and an engineering manager watching. Think "given this list of categories and items, how would you loop over it to find the item with the highest cost? How about all the items in a specific category? How about all green items in any category?"; a very simple problem, used purely as a jumping off place to discuss thought processes, trade offs, approaches, tools, algorithms, etc. I dislike live coding challenges, but this was about as good as could be expected, and led to two more follow up round of high level architecture and design questions. Three total rounds, each 1 hour. Again led to an offer.
* Company C: Medium sized developer tooling company. Started with an take-home assignment that was very poorly defined. I was verbally told it should take "an evening" and "don't take it too seriously", but as I later found out they were expecting more like 18+ hours, finished to the standard you'd expect in production, ie, thorough unit tests, good code coverage, carefully chosen variable and method names, completely documented, all edge cases handled, etc. I didn't make it to round two, which would apparently have been a rigorous code review exercise on the code from the first step, which at the point I'm counting as a win.
I honestly disliked the coding challenge from company B, and semi-enjoyed the one from company C (or what I thought they were asking for). But I'd have been reluctant to spend the incredible amount of time they expected on an unpaid coding challenge even if they'd managed to convey they wanted that, which they didn't.
So based on my experience, about 1/3 of companies out there have terrible interview processes.
> I don't, I'm honest in my CV and during interviews
When I first started interviewing people I assumed everyone wrote their resumes just like me: Honest, accurate, erring on the side of humble, avoiding exaggeration of my abilities.
I learned the hard way that you can’t really trust what people put on their resumes. A lot of people are accurate and honest. Many people are actually too humble or often just bad at selling themselves, so you have to read between the lines and dig for their biggest achievements.
But unfortunately, a large number of people will exaggerate their accomplishments far beyond anything that could be considered reasonable. Claiming proficiency in programming languages they couldn’t begin to even talk about. Writing about projects they didn’t actually work on. Making up unrealistic numbers for how effective or profitable their work was.
The worst was when I receive a resume for a former coworker who hadn’t performed all that well when we worked together. The resume included some of my achievements, which the person hadn’t been involved with nor was even capable of. It was a shock to my naive system to see someone brazenly claim so much in hopes that they could slip past the interviewer and land a well-paid job where they presumably tried to blend in while dodging responsibility and accountability as much as possible.
And that is why we all have to go through onerous tech interviews, despite listing our experience on our resumes.
Not to discount this fact much, but there’s a reason that I optimise my interviews for weeding out liars.
Tech tests on DS&A are fine, I guess, but usually you can sus a person out if you’re technical enough after 30 minutes of talking about previous projects and their level of involvement.
Typically I ask more and more questions about it until they can’t answer, if they try to BS me once they’ve reached their level of incompetence then they're immediately disqualified no matter how good they are in other areas.
I’d rather take a weaker person who doesn’t try to masquerade than a strong person who will.
That’s fair enough, but from a candidate’s perspective most interviewers just want people who can BS effectively. They don’t want to train new hires in their particular stack. They want a ready-made candidate who already has “experience” in X Y Z W A B C.
Call it tragedy of the commons, but being honest is not an optimal way to play the game.
I wouldn't like to work in a place where most people lied to get a job. May be if I would be desperate to find a job, I'd lie as well, but software developer is a hot place now and it shouldn't be too hard to find adequate people IMO.
It’s not good for anybody, but it is some kind of game theoretic equilibrium whereby the hiring machinery is incentivized to find candidates who are good fits for a company’s stack, and candidates are incentivized to present themselves to be such.
The way to solve it is to make the hiring process independent of experience with a particular stack and just hire engineers with good fundamentals, which is what FAANGs do by necessity (because their stack is proprietary), but others don’t want to do because they are afraid it would be too expensive.
I should probably say that I’m in Europe. Things may be different in SV.
Reading coworkers resume or promo packet (more awkward) and finding stuff that you worked on is an instant classic I feel everybody goes through at least once
I'm kind of in a middle ground. I'm honest about what's on there, but what is truth one person is a lie from another. For example, I didn't have specific numbers for what my ICs were, but people like to see context, so I mentioned I did x and y for a company that did such and such in revenue that year, and that on the outside, my code seems to still be powering some of those sales. But honestly, if a colleague at that company asked why I lied about x, I'd just say "Really? My bad, what was I mistaking that for?" because quite frankly I don't remember acutely what specific component I wrote JavaScript for in a huge complex system 6 years ago. It's not that important to begin with, and I only keep the high level details archived in memory.
For example, I might remember working on it, but maybe what I actually did at the time was tested it extensively, or investigated a performance issue, or even collaborated on solving some problem in that specific bit. If I look at the code, I couldn't tell you what my code looked like at that time. There no evidence aside from commits that I did or didn't work on it, and so there's a good chance that either of us are right. Either way, I don't care, it's a trite issue. I got fired from that job anyway and list it on my resume as experience, which it was, but I don't say anything about what I stopped working there. Doesn't make it invalid and it's none of an interviewers business.
Their point is that just because someone can do leetcode does not mean they can program well, and they may too just be faking it to get a job they aren't qualified for.
In my opinion "program better" (or actually better at system modeling)
requires way more time, way more examples, way more code written.
I believe that in order to be "somewhat decent" at leetcode (not top level competitor)
you just need to learn theory, techniques, tricks and get some practice.
Meanwhile in order to get better at system modeling you need to model a lot of systems from scratch, change them and see how your initial design supported that refactor part
You need to be aware of various approaches / architectures, yada yada
And generally spend a lot of time thinking about how it'll affect readability or easiness to get into the project for new ppl, scalability, extensibility, etc.
So, in generally I believe that leetcode is just learn theory, practice everything you learned and go ahead and do 50 / 100 tasks
If you fail, then you can check answers and learn from them
meanwhile there are no correct answers for system modeling.
Additionally for leetcode you have sets with tasks to practice, meanwhile the "real" system modeling experience comes from real projects where requirements are being thrown and changed by somebody else whenever he/she wants
____________
>I don't know how one can study leetcode and fail to learn to program better.
I don't see how even hundreds of hours on leetcode would make you better at OOP, system modeling, building abstractions.
> I don't see how even hundreds of hours on leetcode would make you better at OOP, system modeling, building abstractions.
Because you know the foundations.
Knowing how a compiler works all the way down makes me a better programmer. Knowing assembler makes me a better high level language programmer. Knowing in detail how a car works makes me a better driver. Knowing how electricity works at the low level prevented a very costly mistake by the electrician who was wiring it (he had no idea). Knowing chemistry prevented a very costly mistake by the roofer of my house.
More about algorithm questions vs system modeling:
I'm thinking that
1) getting good at algorithms takes less time, than getting good at system modeling. — One will see one's mistakes sooner, within minutes, compared to system modeling, in which case one would need to stay at a workplace for months or years, to see how a system design eventually turned out to be a mistake?
But 2) it's also harder to get good at hard algorithm questions — most people won't get that good at it, also with weeks and months of practice. And they still wouldn't have any real chance in a Google coding interview.
And in that way, algorithm questions make sense?
They give more information about the person's ability to think and learn — good for the company —
and takes less time for the candidate to get good at (weeks or months — compared to working for years?), good for the candidate?
(I'm someone else than GP)
PS. I wonder what the electrician was up to? :- ) and the other one
I don't know how one can study leetcode and fail to learn to program better.
LC can help you program "better" -- but in a narrow, "just tell me what I need to know to pass the friggen' test" sense.
To learn how to really program better - you'll have to start building things. And reading books. Meaning, you know, "hard" books. Not books about how to get past the LC barrier. And these things known as "papers", and man pages, and specifications, and the raw source code as written by people much, much better than you (even though 99.99 percent of it has nothing to do with LC problems). And by getting down there, in the trenches, and working with people who are plainly better than you are, and who you can almost barely keep up with.
That's how you get to be better. Not by ... studying to pass the test.
> I learned the hard way that you can’t really trust what people put on their resumes. A lot of people are accurate and honest. Many people are actually too humble or often just bad at selling themselves, so you have to read between the lines and dig for their biggest achievements.
What exactly separates accurate/honest from humble/bad at selling oneself according to you?
We don’t have to do it, companies are just gun shy about bad hires. They could easily accept everyone resume unread and remove people only if they failed to live up to expectations for an example of an alternative
When a company is going to invest half a million bucks in a new hire, they're going to do what they can to determine in advance if the hire is going to work out.
Most likely, but we still shouldn't assume its a property of the universe. Its a choice they are making and so the consequences good or bad should be attributed to them
When they invest $500,000 of their own money and it makes millions, do they decline the profit? Their behavior is perfectly rational, but still ultimately a choice they make, and both the good and bad are a result of that.
Unless you are going to argue that they aren't rational adults with agency of their own, in which case I would question letting them decide anything at all
Tbh I don’t know what your comments have to do with mine either?
I was responding to the phrase “have to”, and pointing out that they don’t “have to” do this. Then you brought up things like people investing a lot of their money? It still doesn’t change that it’s a choice. They could be investing the gdp of Canada and making rational decisions around the money, but it is still ultimately a choice
This is the original comment I replied to, I thought you were asking a clarifying question and tried to reiterate my main point. My apologies if there was a confusion
Yea, in my critique, it’s probably not a sentence that triggers people towards good conversation, but I’m not really sure how to broach the concept that everyone has free will when people are legitimating discussing how the people in charge of businesses have no choice and have to do something bad.
Tbh the defense of most business leaders sounds like someone defending a rabid dog or a killer robot’s action’s.
I really can’t understand how some people can simultaneously believe that execs and founders deserve the outsized compensation for making all the decisions critical to the business, while simultaneously believing in this neo-Calvinist philosophy where the elite _have_ to fuck over everyone for their own benefit and it’s ridiculous to think that they could chose ethics over money
Like, do they have free will and so you can make the argument that their choices led to greater profit and they deserve a big cut, or are they simple tiny dancers on the wind of fate who can’t do anything of their own accord which (if you were being consistent) means that they brought nothing of benefit to the business and therefore should get none of the profit?
I have trouble with this argument because on the other hand, once they’ve got good people that are consistently producing valuable output, they penny pinch and give tiny below inflation raises (if at al)… and promptly lose these people to competitors and have to hire all over again.
Companies could buy crappy software, could spend millions in unnecessary offices, expenses for unnecessary dinners, offsites, whatever, on crappy salesmen who can probably cost them more in the long run, etc
It’s a single person, if you identify that he can’t make it within the first 3 months, he will never cost you 500k.
> if you identify that he can’t make it within the first 3 months, he will never cost you 500k.
It'll take longer than that just for the new employee to get up to speed, let alone contribute much and prove his worth.
Also consider that the benefits package is often worth 50% of the salary or more. Then there are the taxes the employer pays on employment, the cost of the facility and equipment for the person, etc.
Then there are all the expensive and costly problems if the person is in a protected class. The employer has to prove they can't do the job, which can take a year or more.
no, you go through them so they can pay you less, and you are the tool used to accomplish this.
also, you should never assume people lie on their resume. before you know it you will carry that bias into every interview. if i was your manager and i knew what you just wrote, i would find someone else to interview people.
> When I first started interviewing people I assumed everyone
> wrote their resumes just like me: Honest, accurate, erring
> on the side of humble, avoiding exaggeration of my abilities.
You may be missing the point of a resume.
There are really two goals:
1. Get you through the door, so you can get an Informational with the Hiring Manager. This means passing the Recruiter and (usually) the Hiring Manager's 30-60 second screen while looking at 50 candidates. Often an email or a Linked In Message is more effective than a CV at this.
2. Sufficiently and credibly explain your background to the interviewers who will be reading it 5 minutes before the interview.
I think you are missing the point of the GP post. Yes, a resume/CV is a marketing document designed to get you past an initial screen, and to tell an interviewer what you are about. But, ideally (and it's certainly not too much to ask), such a document should also be accurate. "Marketing" and "lies" should theoretically be disjoint sets.
Unfortunately, the fact that so many people outright lie on their resumes means that people who don't are at a disadvantage.
I worked at FedEx ground for two weeks in college, but one week was in June and the next was in July, so while that was relevant experience, it went on my resume with June-July and it may have looked like I worked there for two months.
It's common to only list the final position one held, so someone who was in the mailroom for 5 years, somehow got into a deskjob for two weeks and then left is going to show 5 years at the company, deskjob (unless they're looking for a new mailroom gig). It's true, but misleading. Of course, some people go beyond that and claim things they didn't actually do, etc.
After a certain point of interviewing candidates, I stopped reading their resumes. All of the interesting stuff I would ask about never had details behind it, because it was fluffed up, but never enough to disqualify a candidate either.
When I see a new grad say they're an advanced Java developer, I take it was a grain of salt. Then they don't remember what the associative array implementation is called in Java (HashMap). If you don't know your language's standard library implementation of common collections, you're not advanced.
But I make sure to not judge them on that. They're often over zealous and looking for a job, so I don't blame them. The content of the interview is the real meat and potatoes in my experience.
> But I make sure to not judge them on that. [...] The content of the interview is the real meat and potatoes
Which is to say, the difference between a genuinely good candidate and one that merely claims to be is clearly visible in exactly the kind of interview the linked article is arguing against.
I think there's lots of room for criticism of the Big Tech Coding Interview. But "it doesn't work" is just not reasonable. It does work, it objectively works very well, probably better than other techniques (the existence proof being that there aren't any other hiring organizations out there beating the FAANGs at their own HR game).
If you want to criticize, point out that it doesn't necessarily work fairly. It rejects specific qualified candidates more often than it should, and it fails to reliably measure other areas of qualification than mere technical skill.
But don't say it doesn't work, or that it's a waste of time. Show, don't tell. If you know how to hire better people, then do so and beat the world.
I have one and it’s quite difficult because it requires the interviewer to know their shit: drill down on a feature or technology listed in the resume in the interview with the developer. Get into the technical scope, the tradeoffs, pinch points and cruxes of problem set. Understand what the definition of success was in that feature and the individual contribution involved. A dev who only passably did the work or did so heavily relying on others expertise won’t be able to answer precise trade off questions in this way. Ultimately though if they did the work they did the work, and that’s more important than any leetcode/trivia nonsense.
People have been re-discovering this technique for over a decade now at least. It's actually used at quite a few big tech companies, but only for strategic hires.
You touch on one of the reasons this technique isn't used in general:
> it’s quite difficult because it requires the interviewer to know their shit
Having an interviewing team in an engineering org n > 100 with the following properties is nearly impossible:
1. Everyone knows their shit
2. Everyone cares enough to give the interview well
3. Has enough throughput to meet the company's hiring needs
4. The interviews are given in such a way that legal isn't worried we'll get slapped with a discrimination lawsuit
> If you don't know your language's standard library implementation of common collections, you're not advanced.
Heh. I've written production code—and lots of it—in... god, eleven or twelve languages? Not counting transpile-to-JS languages—add another two for that. Also not counting markup languages or CSS or anything like that. Oh, and I forgot bash, if that counts (not sure I'd count it).
I'd probably get stuff like "how do you declare & populate an associative array?" wrong in at least half of them, and the others I'd basically be guessing but luckily several accept syntax so similar that if I used it on all of them I'd be correct in enough cases to get me up to about half-right. I'd have about as much trouble with this task in languages I last wrote fifteen years ago, as ones I wrote code in today.
Stuff that's common to most or all languages, I tend not to keep in my head. Any given language probably has this kind of feature, so I just expect it to be there, and not confined to any particular language. I crib off nearby code, let my tools tell me the correct invocation, or look it up. If it's anything even somewhat common, there's usually an example nearby to use as reference, so it hardly even slows me down. If it's uncommon enough in the codebase that I have to look it up or spend 10 seconds finding an example in some other file, that probably means I'm not having to do that often, so that's OK too.
That's fine if you're talking about languages you use infrequently, but if you can't declare and populate an associative array in the main language you're interviewing in you shouldn't be surprised if your interviewer fails you.
I usually try to drill syntax for about 30 minutes before an interview, for this reason—I'll forget it a few hours later, but that's fine, since it doesn't actually matter—but it's hardly ever been turned out to be a factor in a 20+ year career and 7 or 8 job switches, anyway. I mostly do it for my own peace of mind.
But to GPS point, if this is going to be the new production language for this person for the next period, they’re going to lookup how to do this in seconds and then be an asset to you. Would you really rather have the junior developer who knows the answer to this question off the top of their head, but has so many other lessons to yet learn that GP can bring to the table?
Honestly, once a person has demonstrated some proficiency in a cross section of languages, you should just skip the language proficiency section and instead talk about how learning new languages has gone in the past. Look for any red flags or biases that are going to be a hindrance in the new languages particular paradigm, but otherwise the “can you X” is already a done deal.
> but if you can't declare and populate an associative array in the main language you're interviewing in you shouldn't be surprised if your interviewer fails you.
What if I can google how to do that in all of the languages I've used (and many I haven't) faster than most can write it out from memory? How do I convey that to you and what is it worth to you?
Wrote memorization like that is one of my weaknesses but I can compensate for it. I heard an interesting theory that one aspect of intelligence is how efficiently you can forget information that you don't benefit from retaining. If our brains have finite storage capacity that seems pretty logical.
I will often pick something "expert" on their resume to dig into, if nothing else than to gauge what "expert" means to them.
Recently I interviewed someone who emphasized databases on their resume, and later mentioned they were very highly skilled in that area, so we started talking about indexes. I think I asked something like "Why wouldn't we just put an index on every field?" and the best I could get from them was "it might speed up, it might slow down" but they couldn't articulate why.
Another one I will sometimes ask: You're an expert in language / framework x and have been using it for 10+ years? Cool. What recent additions have you most excited about it? What things about it do you hate/disagree with the most?
Not being able to answer these things don't mean you 'fail' the interview of course, but to me it's a strong signal that our definitions of "expert" are different, and so I'll make that assumption about everything else on your resume.
When directly asked about my git skills, I say something to the effect of "I've probably gotten myself into and out of most of the obvious sticky situations one can get themselves into. My main skills for getting out of them are 1. don't panic, and 2. look things up on google."
I think I'm the same, I try not to list too much to stop spam. Professionally I do JavaScript/TypeScript and work with React so I write that.
I do like having a 'Familiar' section where I list languages I like to dabble with outside of work, generally where I can create a personal project but don't know the ins and outs. I find these useful to talk over in an interview as I don't want to come across as a very one-dimensional JS developer.
Please continue doing it. I have read too many CVs in my life. I can smell liars from just looking at their CVs. True, you might easier pass the HR/recruiter but latest when someone with a little bit of knowledge screens it, a liar is gone.
You might argue, that not every pipeline works like that! Right. But now imagine the consequences if you are hired. Independent whether you fail, think how toxic a workplace must be, if liars are regularly employed. The hiding. The avoidance of responsibility. The amount of bad solutions. The success stealing. The meeting slideshows. The horrible code. So many consequences.
The author is in DevOps, which seems like it should have its own interviews process distinct from general SWE. Seems like putting such folks through the Leetcode gauntlet would be a mismatch in expectations.
Yup similar experience here. Field and experience should be taken into account when offering leetcode interview. Maybe langage should be added too. In python for exemple there are lot of standard library that implement and optimise the leet code stuff.
While I do understand where this view is coming from, I think it's also a major waste of time to complain about it.
Let me put it this way - you are not entitled to a high-earning FAANG job. It's really that simple. It's a free market, and companies can select the way they recruit their people. You feel like it's a waste of time to learn Leetcode questions? Then don't do it. Case closed.
I say this as someone who failed multiple algorithm questions because I did not invest enough time to be good at them.
>you are not entitled to a high-earning FAANG job. It's really that simple.
He's not talking about FAANG jobs. He's talking about Joe Blow companies that pays "market rates," and "great benefits!" to code really boring stuff with no highlights on the resume.
He said these companies are too lazy to research any references and are just copy/pasta leetcode tests to their interviewees; tests the hiring people probably can't even validate as correct without an answer key.
>I think it's also a major waste of time to complain about it.
Why's that? People are obviously taking time out of their day to read the complaint, and a non-zero amount of those people may be in a position to enact some small changes.
>Let me put it this way - you are not entitled to a high-earning FAANG job.
Not once reading this entire thing did I feel like the author felt entitled to a high-earning FAANG job. They actually make it pretty explicitly clear that they are talking about non-FAANG companies employing FAANG-style (or, what those non-FAANG companies think is FAANG-style) interviews. And it's still pretty clear, to me at least, that the author doesn't feel entitled to those jobs either.
>You feel like it's a waste of time to learn Leetcode questions? Then don't do it. Case closed.
That's... That's what they did. And they wrote about it.
Kind of an extension of this is that Facebook isn't looking for qualified developers. They're looking for qualified developers who will bend over backward to make a pile of money.
And many non-Facebook employers are looking for qualified developers who will bend over backward to make a much smaller pile of money. They might be making a bad decision, but it's their bad decision to make.
Of course interviewers are entitled to or able to do these kinds of interviews. That doesn't mean one can't complain about it, and thereby hope to shift attitudes to where they change what they do. There'd be little to talk about or do if we could never describe ways in which we want things to change. This person is themself entitled to complain, and yet here you are complaining about them complaining (which you are entitled to as well).
It took me 5 tries over the span of 3 years to land a lucrative job at a FAANG. The effort I put in was very well spent and is minimal compared to other types of exams (law, medicine...).
That being said, this is survivor bias and I understand it would be very frustrating to work on the preparation and not get a position in return. But to those who don't like the process, they have many other companies to choose from.
I think OP is saying that 99.9999% of the other companies aren't FAANG even though they pretend to be. Their use case is displaying JPG images, not creating a new JPG algorithm. You don't need multi-dimensional array manipulation leetcode hard problems to do that. Yet their interview process is geared around that, and the recruiters/management don't know enough to know to make a useful decision. And then everybody complains "Oh, we can't find competent talent. Give us more visa openings!". But the free market eventually is taking care of those companies. You're seeing major layoffs in the crypto industry because they overhired on leetcoders and apparently not enough people who could help them turn a profit.
To be fair most of the people employed at FAANGs are just moving things between protocol buffers and hash maps and back again.
They just make the interview hard because they pay a high salary and get too many applicants.
People complaining about interviews should be more explicit about the companies they interviewed for. It might not be a FAANG company, but what if it's a database company? Or an MLOps company? Or even a gaming company. They need SWE with good algorithm and data structure skills too.
This is a very naive and unconstructive point of view.
Interviewers have an interest to screen for the best quality with the least effort. If they can reduce false negatives, they could fill positions more quickly. If there's a concensus a particular method is always better than asking for leetcode hards in 30 minutes, companies are likely to adopt it. Companies that adopt better practices perform better, and hopefully there's less time spent by people on practising leetcoding and more time spent on more productive activities.
Nothing would be done if these conversations are not had. Many fail to make a difference, but sometimes something good comes out of it. You should learn to have some humility that many privileges that you currently enjoy are won by people who care and try and you should not shut them down.
And as a practical matter, industry insiders do read these complaints.
Sure, it's hard to make big companies change what they do. But companies do adapt. Many small companies adopted alternative practices that are less heavy on leetcode and hire well. With some time and effort, maybe big companies would change too, and we could all be better off.
What I don't get is when they ghost you, but with positive feedback! I was talking to a guy not long ago, everything was a fit, I'd done exactly what they wanted in my previous job, had team management experience, and so on. The HM/founder says I sound great and we should talk again.
So he goes on holiday.
Then his HR lady goes on holiday.
They get back, apologize for the delay, and want to proceed.
Nothing happens. No response...
He's probably right about homework too. I can't tell if they are actually testing for you already having a solution on the shelf that you can slightly modify for them. Regardless, if someone did a homework assignment for me, I would make sure they got feedback. If it wasn't good enough I would think really hard about what I said about the conditions (don't spend too much time, it's ok if it isn't perfect) before dumping them. At best it is just a kind of fizzbuzz: if they can stand up a k8s thing in a few hours, they are likely not making this up or even copy pasting it.
End of the day software has some odd ideas about what evidence is. Just about every other profession is just a CV, some chat, a light grilling, then a response. If the person is making it up they'll get found out and dumped out soon enough. Software somehow manages to do both: several interviewers have told me they dumped out a guy after a brief stint, then tried the whole Leetcode/homework/tech chat thing.
Here's the thing that irks me about things like "standing up k8s in a couple hours": It's something that only gets done a few times for an entire project - once or twice in dev and test, then again in prod. Not even a few times a year - a few times per project/code stack.
The actual work will be "tweak this to have six side cars instead of five", or "set it to spin up a few more nodes", or maybe even "upgrade k8s from version X to version Y without downtime, test your solution on dev first". There has to be some way to test that.
Instead they give you "Bring up a vpc, resources with terraform or cloud formation, spin up k8s, program a webapp that tells me my IP in a container, set up a build system to package it, configure Route 53, then make it all run." - all in three hours.
I don't write scripts or even yaml from scratch that fast. I don't know anyone who does. Most people copy/paste old projects or stuff off of StackOverflow and then mangle it to try to do these silly things.
I'm definitely going to ask probing questions about the tech. And the more familiar I am with it (and the more relevant it is to the job), the more detailed and discerning I will be.
It works too. The outcome is usually either, the interviewee is rattled and straight up admits that they don't know as much as their resume claims; or, we get to have a pretty in depth conversation about what the interviewee has actually done
The former is fine with me. I think most developers understand it's better to come clean early. When interviewing with me, that's the right call, because if I think you don't know you're stuff, you'll fail, but if you admit that you aren't so familiar with $technology, then I'll shift my questions to something else.
The latter is ideal though, since it segues well into the actual job requirements, and the interviewee gets real insight into what they are walking into.
The person who wrote this article is a-typical. I've interviewed people with github accounts, but most of the time they are full of college course work or cloned open source repos, so they aren't really worth investigating too deeply. But someone with an active open source project on github and a popular blog seems like an easy interview, but I've never had the opportunity to speak with anyone like that.
This is why I wish cover letters were more popular. Having a candidate tell you they don't have much experience using X to do Y but that they'd love to learn to / have been working on it on their spare time is better than having them lie on their resume (or miss out on candidates that are too honest for their own good).
Honestly you're lucky if anyone reads your CV. Standard practice for the technical interviews, i.e. where someone on a team somewhere is taking time away from real work to interview you, is for them to maybe spend 90 seconds, just 5 minutes before the start of the interview, to give it a skim
We had this recently with a candidate I interviewed. List full of technologies but < 5 years of experience. Started probing a bit - “can you explain about the project you did with X” and for pretty much every one we got back “oh, I haven’t done much with that”. It was almost laughable because it was literally every skill listed we asked about, we never got to a point to bounce off of.
> But someone with an active open source project on github and a popular blog seems like an easy interview, but I've never had the opportunity to speak with anyone like that.
I have many thousands (tens, definitely; hundreds, maybe) of lines of code I've written on GitHub. I also have a blog (not sure I'd call it popular though). In my recent interviews (which I blogged about at length) I don't think _anyone_ had looked at my repos on GitHub. Certainly no one asked questions about those projects. A few had read my blog, however.
A couple times I did show them some of my work on GitHub, primarily a project I was working on at the time that had a UI I could screen share.
I just read a few of your blog posts and I'm sure you'll be hired quickly.
Easy to see that you're an old perl hacker that's now into rust and you're active in community stuff that matters (LWN, CPAN).
I feel like you might over-share on your blog in a way that could turn off potential employers, but those are companies you wouldn't want to work for anyway.
I get the vibe you might be opinionated and risky, but are clearly technically competent.
I'd probably put you in a team with other rust-enthusiasts for maximum success. You're likely to inspire newer developers.
You might want to take HTML/CSS/JS off your resume because JS pretty much means React/Vue/Angular these days and you don't seem too interested in that stuff.
That's the sort of stuff I'd check about you before the interview.
>if I think you don't know you're stuff, you'll fail
Have you ever experienced the opposite and been the one that's failed the candidate? Maybe either via a bad job description or answering questions inaccurately or dishonestly? Any times you've had to come clean as the interviewer?
To be honest I looked at github - there's barely any activity, projects have little if any descriptions, the professional experience has been 12 years of mix of project management and customer support, some 2 years of freelance and contract devops work. Medium posts are mostly crypto related. Now compare that with LinkedIn about section, and there's an entirely different picture.
It could be that the reason you are getting the interviews is the Linkedin profile (especially as often companies encourage interviewing people with atypical background), but maybe you fall short of the image you are projecting? The form of the interviews might not help highlight your skills, of course, but it's probably not the only factor.
I think an ever bigger evil is companies who do not calibrate their Leetcode type tests to their hiring needs. I was given a take-home test few years ago by a well-to do medical software company based out of Verona, WI. Their programming test had a question from past ICPC.
Typically Olympiad questions takes well-to-do teamwork & few hours of brainstorming - not a 30min timed test you give with a proctor watching your monitor
Epic doesn't expect that you will finish every question on the exam. That's actually the point of giving harder questions: the ability to calibrate against the entire candidate pool. If the test is so easy everyone aces it, how is that calibration going to go?
In a 50 min test with 10 min MCQs and two timed questions, where one question is a ICPC derivative question & the other one is refactor a pseudocode similar to MUMPS language, what CS talent is it exactly testing?
I don't mind writing MUMPS if I was hired, but the test is not my ability of understanding MUMPS-styled syntax or predicting the win percentage in some chess layouts without using MCTS.
I recently went through an interview process where to advance to the technical interview I would have to learn Go. I know a ton of languages. Haven’t done much with Go. Could I learn it? Sure, I could. But… I am not going to learn a new language where I am comfortable enough to do an interview just so that I have a chance to work for your pre-A round company. I am especially not going to do it when I have 2 job offers sitting on the table that I am currently considering. If you’re a startup founder recruiting other devs, don’t ask them to learn a whole new language on spec so they can interview with you. I’m sorry. You’re just not as hot as you think you are.
>given me a take-home coding assignment of at least 30hrs of work
It's absolutely astounding to me that people must entertain these at a sufficient rate that companies still try to pull this free labor nonsense.
One company I interviewed with provided a take-home assignment and said to bill them for the hours; I found that to be a fair offer, although due to other circumstances limiting my available time, I declined to continue the interview at that point.
If the take-home assignment is expected to take a few hours, maybe it's worth considering. Any longer, and they can look elsewhere for free labor. That time is much better spent sending out more applications, networking, leetcoding for FANG interviews, working on personal projects, or simply taking a walk outside.
I'd by happy with even $20 an hour, shit even $10 for doing their stupid take home assignment would make me less angry. At least they are buying me a couple of beers.
I agree with you in principle, but I don't think characterizing most of these types of assignments as "free labor" is quite accurate. What I suspect is going on is that companies simply aren't taking the time to calibrate the effort required to complete their take home projects. I've had many "two hour" projects end up being more like 6-8 hours to properly complete (I tended to just stop at 3-4 hours and opt out of the rest of the process on this type of thing).
Calling it "free labor" implies to me that the company is going to get some kind of actual value out of it in the end, other than as a candidate assessment. Most of these types of things I've seen simply haven't been the type of project that would be useful in that sense.
OTOH, the big mistake I see a lot of companies doing is doing a 2+ hour take home assignment, then not making the tech portion of the actual interview process just a discussion of the take home project. If I'm going to commit that amount of my own personal time to your interview process, I want to know that it's going to get me out of at least as much "whiteboard hazing" in the end. In my experience, this frequently has not been the case.
>I’m exaggerating the amount of skill that I have. Everyone is. I use the right buzzwords on my CV. I inflate the scale of my achievements and the depth of my skillset. I even add tasks and responsibilities to historical jobs that fit your requirements. You’re never going to check, are you?
I don't think everyone does this. I certainly have never done this. I've never had an issue getting interviews using an honest accounting of my work experience, and I know as an interviewer I use the candidate's resume as the basis for forming my questions to ask them. I would expect others to do the same. Filling your resume with things you didn't actually do just makes the interview harder.
I too once scoffed at grinding leetcode. I’d rather work on side projects or blog instead.
But after 5 years of failing to get a job offer, I finally caved. Putting in the effort to deeply understand DS/algos and grind away leetcode led me to getting offers I liked and IMO has made me a better engineer.
I now have a “gold star” on my resume and am confident I can still answer most leetcode questions. I consider that time spent as a great time investment, since landing my next job will be much easier.
Money wasn’t my original goal when I got into CS, but it eventually became my driving force. I regret taking so long to notice this, and letting my feelings get in my way (of how it “should be”) / resisting leetcode for so long.
> If you want better candidates filling roles, you must stop being lazy and relying on Leetcode or lazy CV parsing. Check the candidate’s portfolio. Pose realistic questions.
Lets be honest. What you want is easier questions. Vague questions that can be discussed and argued one way or the other.
It is not a waste of hiring team time if we avoid hiring a candidate that doesn't meet our standards. We try very hard to find good candidates, but it doesn't mean we will stop interviewing if the candidate pool runs dry. We'll just have to spend more time looking for quality applicants.
Back in the nineties, I worked for a big company where lots of people wanted to work. We had what I called "resume reading parties". A half-dozen of us, managers and ICs, would sit around a pile of resumes in the middle and start reading. When we finished each one we would check either "Y" or "N" and pass the resume to our left...except two noes and the resume was put in the reject pile. Sometimes they fed us. From there would be phone screening then on-site interviews. HR didn't like being cut out of the loop but we knew we were better at screening than they were.
A benefit of this process is that your resume-writing skills improve a lot. Read a hundred or so resumes and you'll learn what catches your eye and what gets ignored.
Alas, nobody else does this. I used to mention this process at places I worked but people thought I was nuts. It worked, though. We rarely had a hire that didn't work out.
The HR recruiter involvement in the hiring process is madness to me. I get that managing somebody through the pipeline is work, and probably a dev isn’t the right person for that job. But having HR out there rejecting resumes is insanity.
I'm confused by this statement. Every company I have worked at for the last 15 years has had hiring managers and usually some senior engineers on the team screen resumes. How else do you even decide who to move to the phone or in-person interview stage?
309 comments
[ 3.0 ms ] story [ 264 ms ] thread> There is no test for debugging SSL certificate chains in production at 3am
Dunno how accurate that is, but I've been told it at more than one shop.
Like I asked in the comment replying to your previous one: what benefit does this give the business whatsoever? This will cost money, time, and very possibly headaches (whether reputational or legal), and for no benefit to the business. Why would they consider this?
Common courtesy? Same with being nice and polite, saying hello/goodbye, etc. It wastes time because you could get to the point faster but it’s nicer and makes the interaction more pleasant. That’s it. No other reason. Just make the world a slightly better place with a tiny action.
This. I don't want to view interviewing as a thankless chore because I think it's important, but hard to view it any other way when your interaction with any given new hire will be minimal at best - especially since the extra work of interviewing usually just ends up as a footnote come review time. If you want people to take interviewing seriously, give them some skin in the game.
I don't, I'm honest in my CV and during interviews
I'm selling myself 'as-is' e.g despite using git for longer peroid of time, but mostly via GUI, then I'm not going to call myself proficient/experienced git user cuz I'd fail some above basics question
I thought it was more common that they'd get paid per person hired and still at the job 3 months later? But I'm a bit clueless
A bit misaligned incentives in the same way as agencies have, I'm thinking
She basically told me I am underselling some of the experience, and I should put some of it more, and perk it up a bit. It was very helpful.
Engineers have that. You have to take example a bit from real estate agents, on how they describe a place. Always highlight the positives.
I hate preparing for interviews and don't want to brush on my past. For example, I spent a year writing an LLVM backend for a DSP but I'm pretty sure I couldn't write more than a fizzbuzz in C++ now. Nor do I remember much about LLVM. I don't want to come across an LLVM enthusiast and have him start grilling me on details I have long forgotten.
I try to write just enough to get an interview, anymore information makes you more likely to fail your interview in my book. Plus writing less makes you mysterious ;p.
Last job search was depressing. I wanted to actually stick with it, and find me a job I actually wanted (as opposed to the same thing I've been doing for years + some more money). However nearly every job I applied to I got ATS screened out of, meanwhile the recruiters kept coming to me with more money for similar crappy jobs and I folded. Well either that or recruiters that never even read my resume spam me. I've been getting spam for RoR positions, I haven't touched ruby since 1.9 ad have never had professional experience with it.
I could slightly understand if some people write whatever in their CVs if they're trying to get past the machines
Inflating your skillset is going to get you into the wrong interviews, and you'll do poorly in them (and consequently will have these kinds of negative experiences). Either accurately represent or slightly undersell yourself; it comes off much better and will save you time and money.
Required keywords "Agile/Scrum" does not appear on this resume, rejected.
Is it really that bad now? If I were applying for employee roles today it would probably never have occurred to me that including "Agile" as a buzzword could be important to avoid getting filtered immediately. I can understand filtering someone for having no apparent experience in the main programming language you use if you have many other applicants who do. Filtering for something that basically every employer has claimed to do for about 200 years but no two of them would agree on what it means seems silly though.
One can oversell themselves based on their potential to learn and grow.
For example, if someone is a junior and they designed a micro-service with a senior but have a solid grasp of the process, then it's fair that they claim that they designed a micro-service. They can read up on the relevant concepts, answer a few questions in the interview and get a very nice opportunity in a cool startup. If they can learn to do it fast enough to be productive, then both they and the company are happy.
On the contrary, by underselling themselves or being accurate, they are more likely get a job at their current level of knowledge, which can limit their growth potential. Still, this can be a good idea if someone is already very experienced and doesn't want to spend a lot of energy to grow.
I got a job offer from a company whose main language is Go and I didn't even know the basics. A good software engineer can pick up any reasonable language in a reasonable amount of time [1].
I usually ignore recruiters who don't contact me via InMail. If they convey that they actually took a look at my profile, I'll reply.
I've had a very good experience with the three EU companies that I've been interviewing with this year. One had a take-home assignment that was reasonably scoped for 2-4h and well thought. The others asked some basics and some architechture / design / business understanding related questions. No leetcode or whiteboard coding. Open communication + quick feedback.
Was I just lucky in that regard or are there a lot of companies with a sane interview process out there, but some HN readers prefer to apply at those who don't?
[1] https://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-pr...
* Company A: Small startup in a non-profit space. Technical part was an informal chat with a current tech lead, which led to them sending me a list of high level general questions around architecture and design to be discussed on a follow up call, then it moved on to a third non-technical round. Good approach overall, I appreciated being able to prepare in advance instead of being given a pop quiz, and I think it unpacked my skills pretty well. Total time maybe 3 hours? It led to an offer.
* Company B: Medium sized ecommerce company. Technical part was a live coding challenge via screen share, with a tech lead and an engineering manager watching. Think "given this list of categories and items, how would you loop over it to find the item with the highest cost? How about all the items in a specific category? How about all green items in any category?"; a very simple problem, used purely as a jumping off place to discuss thought processes, trade offs, approaches, tools, algorithms, etc. I dislike live coding challenges, but this was about as good as could be expected, and led to two more follow up round of high level architecture and design questions. Three total rounds, each 1 hour. Again led to an offer.
* Company C: Medium sized developer tooling company. Started with an take-home assignment that was very poorly defined. I was verbally told it should take "an evening" and "don't take it too seriously", but as I later found out they were expecting more like 18+ hours, finished to the standard you'd expect in production, ie, thorough unit tests, good code coverage, carefully chosen variable and method names, completely documented, all edge cases handled, etc. I didn't make it to round two, which would apparently have been a rigorous code review exercise on the code from the first step, which at the point I'm counting as a win.
I honestly disliked the coding challenge from company B, and semi-enjoyed the one from company C (or what I thought they were asking for). But I'd have been reluctant to spend the incredible amount of time they expected on an unpaid coding challenge even if they'd managed to convey they wanted that, which they didn't.
So based on my experience, about 1/3 of companies out there have terrible interview processes.
Live coding isn't very, but I found live code review + occasional adjustments quite effective when interviewing candidates.
When I first started interviewing people I assumed everyone wrote their resumes just like me: Honest, accurate, erring on the side of humble, avoiding exaggeration of my abilities.
I learned the hard way that you can’t really trust what people put on their resumes. A lot of people are accurate and honest. Many people are actually too humble or often just bad at selling themselves, so you have to read between the lines and dig for their biggest achievements.
But unfortunately, a large number of people will exaggerate their accomplishments far beyond anything that could be considered reasonable. Claiming proficiency in programming languages they couldn’t begin to even talk about. Writing about projects they didn’t actually work on. Making up unrealistic numbers for how effective or profitable their work was.
The worst was when I receive a resume for a former coworker who hadn’t performed all that well when we worked together. The resume included some of my achievements, which the person hadn’t been involved with nor was even capable of. It was a shock to my naive system to see someone brazenly claim so much in hopes that they could slip past the interviewer and land a well-paid job where they presumably tried to blend in while dodging responsibility and accountability as much as possible.
And that is why we all have to go through onerous tech interviews, despite listing our experience on our resumes.
Tech tests on DS&A are fine, I guess, but usually you can sus a person out if you’re technical enough after 30 minutes of talking about previous projects and their level of involvement.
Typically I ask more and more questions about it until they can’t answer, if they try to BS me once they’ve reached their level of incompetence then they're immediately disqualified no matter how good they are in other areas.
I’d rather take a weaker person who doesn’t try to masquerade than a strong person who will.
Call it tragedy of the commons, but being honest is not an optimal way to play the game.
The way to solve it is to make the hiring process independent of experience with a particular stack and just hire engineers with good fundamentals, which is what FAANGs do by necessity (because their stack is proprietary), but others don’t want to do because they are afraid it would be too expensive.
I should probably say that I’m in Europe. Things may be different in SV.
"A place where most people lied to get a (tech) job", is the world. And the world is the only place that has jobs.
Do you really think everyone has a spot at FAANG-etc? They don’t - I know because I work at them and we reject so many people at the on-site stage.
About how many percent?
What could be ways to find out sooner that they're not the best person for the job? (What about doing half the interviews remotely?)
For example, I might remember working on it, but maybe what I actually did at the time was tested it extensively, or investigated a performance issue, or even collaborated on solving some problem in that specific bit. If I look at the code, I couldn't tell you what my code looked like at that time. There no evidence aside from commits that I did or didn't work on it, and so there's a good chance that either of us are right. Either way, I don't care, it's a trite issue. I got fired from that job anyway and list it on my resume as experience, which it was, but I don't say anything about what I stopped working there. Doesn't make it invalid and it's none of an interviewers business.
I don’t mean to burst your bubble, but these type of people have no problem studying leetcode for a few weeks. Sorry to say.
After all, I learned chemistry, physics, math, mechanics, thermodynamics, etc., by working problem sets.
requires way more time, way more examples, way more code written.
I believe that in order to be "somewhat decent" at leetcode (not top level competitor)
you just need to learn theory, techniques, tricks and get some practice.
Meanwhile in order to get better at system modeling you need to model a lot of systems from scratch, change them and see how your initial design supported that refactor part
You need to be aware of various approaches / architectures, yada yada
And generally spend a lot of time thinking about how it'll affect readability or easiness to get into the project for new ppl, scalability, extensibility, etc.
So, in generally I believe that leetcode is just learn theory, practice everything you learned and go ahead and do 50 / 100 tasks
If you fail, then you can check answers and learn from them
meanwhile there are no correct answers for system modeling.
Additionally for leetcode you have sets with tasks to practice, meanwhile the "real" system modeling experience comes from real projects where requirements are being thrown and changed by somebody else whenever he/she wants
____________
>I don't know how one can study leetcode and fail to learn to program better.
I don't see how even hundreds of hours on leetcode would make you better at OOP, system modeling, building abstractions.
Because you know the foundations.
Knowing how a compiler works all the way down makes me a better programmer. Knowing assembler makes me a better high level language programmer. Knowing in detail how a car works makes me a better driver. Knowing how electricity works at the low level prevented a very costly mistake by the electrician who was wiring it (he had no idea). Knowing chemistry prevented a very costly mistake by the roofer of my house.
I'm thinking that
1) getting good at algorithms takes less time, than getting good at system modeling. — One will see one's mistakes sooner, within minutes, compared to system modeling, in which case one would need to stay at a workplace for months or years, to see how a system design eventually turned out to be a mistake?
But 2) it's also harder to get good at hard algorithm questions — most people won't get that good at it, also with weeks and months of practice. And they still wouldn't have any real chance in a Google coding interview.
And in that way, algorithm questions make sense?
They give more information about the person's ability to think and learn — good for the company —
and takes less time for the candidate to get good at (weeks or months — compared to working for years?), good for the candidate?
(I'm someone else than GP)
PS. I wonder what the electrician was up to? :- ) and the other one
LC can help you program "better" -- but in a narrow, "just tell me what I need to know to pass the friggen' test" sense.
To learn how to really program better - you'll have to start building things. And reading books. Meaning, you know, "hard" books. Not books about how to get past the LC barrier. And these things known as "papers", and man pages, and specifications, and the raw source code as written by people much, much better than you (even though 99.99 percent of it has nothing to do with LC problems). And by getting down there, in the trenches, and working with people who are plainly better than you are, and who you can almost barely keep up with.
That's how you get to be better. Not by ... studying to pass the test.
What exactly separates accurate/honest from humble/bad at selling oneself according to you?
Unless you are going to argue that they aren't rational adults with agency of their own, in which case I would question letting them decide anything at all
I was responding to the phrase “have to”, and pointing out that they don’t “have to” do this. Then you brought up things like people investing a lot of their money? It still doesn’t change that it’s a choice. They could be investing the gdp of Canada and making rational decisions around the money, but it is still ultimately a choice
This is the original comment I replied to, I thought you were asking a clarifying question and tried to reiterate my main point. My apologies if there was a confusion
> we still shouldn't assume its a property of the universe
is actually a bit funny I think. One could post that comment as a reply to almost anything :-)
And then see how they interpret it and how they react
Tbh the defense of most business leaders sounds like someone defending a rabid dog or a killer robot’s action’s.
I really can’t understand how some people can simultaneously believe that execs and founders deserve the outsized compensation for making all the decisions critical to the business, while simultaneously believing in this neo-Calvinist philosophy where the elite _have_ to fuck over everyone for their own benefit and it’s ridiculous to think that they could chose ethics over money
Like, do they have free will and so you can make the argument that their choices led to greater profit and they deserve a big cut, or are they simple tiny dancers on the wind of fate who can’t do anything of their own accord which (if you were being consistent) means that they brought nothing of benefit to the business and therefore should get none of the profit?
Government, on the other hand, just increases the budget.
It'll take longer than that just for the new employee to get up to speed, let alone contribute much and prove his worth.
Also consider that the benefits package is often worth 50% of the salary or more. Then there are the taxes the employer pays on employment, the cost of the facility and equipment for the person, etc.
Then there are all the expensive and costly problems if the person is in a protected class. The employer has to prove they can't do the job, which can take a year or more.
also, you should never assume people lie on their resume. before you know it you will carry that bias into every interview. if i was your manager and i knew what you just wrote, i would find someone else to interview people.
You may be missing the point of a resume.
There are really two goals: 1. Get you through the door, so you can get an Informational with the Hiring Manager. This means passing the Recruiter and (usually) the Hiring Manager's 30-60 second screen while looking at 50 candidates. Often an email or a Linked In Message is more effective than a CV at this.
2. Sufficiently and credibly explain your background to the interviewers who will be reading it 5 minutes before the interview.
The CV needs to present well and be credible.
Unfortunately, the fact that so many people outright lie on their resumes means that people who don't are at a disadvantage.
I worked at FedEx ground for two weeks in college, but one week was in June and the next was in July, so while that was relevant experience, it went on my resume with June-July and it may have looked like I worked there for two months.
It's common to only list the final position one held, so someone who was in the mailroom for 5 years, somehow got into a deskjob for two weeks and then left is going to show 5 years at the company, deskjob (unless they're looking for a new mailroom gig). It's true, but misleading. Of course, some people go beyond that and claim things they didn't actually do, etc.
After a certain point of interviewing candidates, I stopped reading their resumes. All of the interesting stuff I would ask about never had details behind it, because it was fluffed up, but never enough to disqualify a candidate either.
But I make sure to not judge them on that. They're often over zealous and looking for a job, so I don't blame them. The content of the interview is the real meat and potatoes in my experience.
Which is to say, the difference between a genuinely good candidate and one that merely claims to be is clearly visible in exactly the kind of interview the linked article is arguing against.
I think there's lots of room for criticism of the Big Tech Coding Interview. But "it doesn't work" is just not reasonable. It does work, it objectively works very well, probably better than other techniques (the existence proof being that there aren't any other hiring organizations out there beating the FAANGs at their own HR game).
If you want to criticize, point out that it doesn't necessarily work fairly. It rejects specific qualified candidates more often than it should, and it fails to reliably measure other areas of qualification than mere technical skill.
But don't say it doesn't work, or that it's a waste of time. Show, don't tell. If you know how to hire better people, then do so and beat the world.
You touch on one of the reasons this technique isn't used in general:
> it’s quite difficult because it requires the interviewer to know their shit
Having an interviewing team in an engineering org n > 100 with the following properties is nearly impossible:
1. Everyone knows their shit
2. Everyone cares enough to give the interview well
3. Has enough throughput to meet the company's hiring needs
4. The interviews are given in such a way that legal isn't worried we'll get slapped with a discrimination lawsuit
Heh. I've written production code—and lots of it—in... god, eleven or twelve languages? Not counting transpile-to-JS languages—add another two for that. Also not counting markup languages or CSS or anything like that. Oh, and I forgot bash, if that counts (not sure I'd count it).
I'd probably get stuff like "how do you declare & populate an associative array?" wrong in at least half of them, and the others I'd basically be guessing but luckily several accept syntax so similar that if I used it on all of them I'd be correct in enough cases to get me up to about half-right. I'd have about as much trouble with this task in languages I last wrote fifteen years ago, as ones I wrote code in today.
Stuff that's common to most or all languages, I tend not to keep in my head. Any given language probably has this kind of feature, so I just expect it to be there, and not confined to any particular language. I crib off nearby code, let my tools tell me the correct invocation, or look it up. If it's anything even somewhat common, there's usually an example nearby to use as reference, so it hardly even slows me down. If it's uncommon enough in the codebase that I have to look it up or spend 10 seconds finding an example in some other file, that probably means I'm not having to do that often, so that's OK too.
Honestly, once a person has demonstrated some proficiency in a cross section of languages, you should just skip the language proficiency section and instead talk about how learning new languages has gone in the past. Look for any red flags or biases that are going to be a hindrance in the new languages particular paradigm, but otherwise the “can you X” is already a done deal.
What if I can google how to do that in all of the languages I've used (and many I haven't) faster than most can write it out from memory? How do I convey that to you and what is it worth to you?
Wrote memorization like that is one of my weaknesses but I can compensate for it. I heard an interesting theory that one aspect of intelligence is how efficiently you can forget information that you don't benefit from retaining. If our brains have finite storage capacity that seems pretty logical.
I'm smarter than what I thought :-)
& frequently forget how to iterate through arrays and objects in Typescript although been using it for years
> if I can google
Sounds fine with me, or via an IDE, or pseudocode
Recently I interviewed someone who emphasized databases on their resume, and later mentioned they were very highly skilled in that area, so we started talking about indexes. I think I asked something like "Why wouldn't we just put an index on every field?" and the best I could get from them was "it might speed up, it might slow down" but they couldn't articulate why.
Another one I will sometimes ask: You're an expert in language / framework x and have been using it for 10+ years? Cool. What recent additions have you most excited about it? What things about it do you hate/disagree with the most?
Not being able to answer these things don't mean you 'fail' the interview of course, but to me it's a strong signal that our definitions of "expert" are different, and so I'll make that assumption about everything else on your resume.
I do like having a 'Familiar' section where I list languages I like to dabble with outside of work, generally where I can create a personal project but don't know the ins and outs. I find these useful to talk over in an interview as I don't want to come across as a very one-dimensional JS developer.
You might argue, that not every pipeline works like that! Right. But now imagine the consequences if you are hired. Independent whether you fail, think how toxic a workplace must be, if liars are regularly employed. The hiding. The avoidance of responsibility. The amount of bad solutions. The success stealing. The meeting slideshows. The horrible code. So many consequences.
Stay with the truth!
Let me put it this way - you are not entitled to a high-earning FAANG job. It's really that simple. It's a free market, and companies can select the way they recruit their people. You feel like it's a waste of time to learn Leetcode questions? Then don't do it. Case closed.
I say this as someone who failed multiple algorithm questions because I did not invest enough time to be good at them.
He's not talking about FAANG jobs. He's talking about Joe Blow companies that pays "market rates," and "great benefits!" to code really boring stuff with no highlights on the resume.
He said these companies are too lazy to research any references and are just copy/pasta leetcode tests to their interviewees; tests the hiring people probably can't even validate as correct without an answer key.
Why's that? People are obviously taking time out of their day to read the complaint, and a non-zero amount of those people may be in a position to enact some small changes.
>Let me put it this way - you are not entitled to a high-earning FAANG job.
Not once reading this entire thing did I feel like the author felt entitled to a high-earning FAANG job. They actually make it pretty explicitly clear that they are talking about non-FAANG companies employing FAANG-style (or, what those non-FAANG companies think is FAANG-style) interviews. And it's still pretty clear, to me at least, that the author doesn't feel entitled to those jobs either.
>You feel like it's a waste of time to learn Leetcode questions? Then don't do it. Case closed.
That's... That's what they did. And they wrote about it.
And many non-Facebook employers are looking for qualified developers who will bend over backward to make a much smaller pile of money. They might be making a bad decision, but it's their bad decision to make.
That being said, this is survivor bias and I understand it would be very frustrating to work on the preparation and not get a position in return. But to those who don't like the process, they have many other companies to choose from.
The devil is in the details, of course.
New buzzword for me today.
About as much as complaining about complaining.
Interviewers have an interest to screen for the best quality with the least effort. If they can reduce false negatives, they could fill positions more quickly. If there's a concensus a particular method is always better than asking for leetcode hards in 30 minutes, companies are likely to adopt it. Companies that adopt better practices perform better, and hopefully there's less time spent by people on practising leetcoding and more time spent on more productive activities.
Nothing would be done if these conversations are not had. Many fail to make a difference, but sometimes something good comes out of it. You should learn to have some humility that many privileges that you currently enjoy are won by people who care and try and you should not shut them down.
And as a practical matter, industry insiders do read these complaints. Sure, it's hard to make big companies change what they do. But companies do adapt. Many small companies adopted alternative practices that are less heavy on leetcode and hire well. With some time and effort, maybe big companies would change too, and we could all be better off.
So he goes on holiday.
Then his HR lady goes on holiday.
They get back, apologize for the delay, and want to proceed.
Nothing happens. No response...
He's probably right about homework too. I can't tell if they are actually testing for you already having a solution on the shelf that you can slightly modify for them. Regardless, if someone did a homework assignment for me, I would make sure they got feedback. If it wasn't good enough I would think really hard about what I said about the conditions (don't spend too much time, it's ok if it isn't perfect) before dumping them. At best it is just a kind of fizzbuzz: if they can stand up a k8s thing in a few hours, they are likely not making this up or even copy pasting it.
End of the day software has some odd ideas about what evidence is. Just about every other profession is just a CV, some chat, a light grilling, then a response. If the person is making it up they'll get found out and dumped out soon enough. Software somehow manages to do both: several interviewers have told me they dumped out a guy after a brief stint, then tried the whole Leetcode/homework/tech chat thing.
The actual work will be "tweak this to have six side cars instead of five", or "set it to spin up a few more nodes", or maybe even "upgrade k8s from version X to version Y without downtime, test your solution on dev first". There has to be some way to test that.
Instead they give you "Bring up a vpc, resources with terraform or cloud formation, spin up k8s, program a webapp that tells me my IP in a container, set up a build system to package it, configure Route 53, then make it all run." - all in three hours.
I don't write scripts or even yaml from scratch that fast. I don't know anyone who does. Most people copy/paste old projects or stuff off of StackOverflow and then mangle it to try to do these silly things.
I'm definitely going to ask probing questions about the tech. And the more familiar I am with it (and the more relevant it is to the job), the more detailed and discerning I will be.
It works too. The outcome is usually either, the interviewee is rattled and straight up admits that they don't know as much as their resume claims; or, we get to have a pretty in depth conversation about what the interviewee has actually done
The former is fine with me. I think most developers understand it's better to come clean early. When interviewing with me, that's the right call, because if I think you don't know you're stuff, you'll fail, but if you admit that you aren't so familiar with $technology, then I'll shift my questions to something else.
The latter is ideal though, since it segues well into the actual job requirements, and the interviewee gets real insight into what they are walking into.
The person who wrote this article is a-typical. I've interviewed people with github accounts, but most of the time they are full of college course work or cloned open source repos, so they aren't really worth investigating too deeply. But someone with an active open source project on github and a popular blog seems like an easy interview, but I've never had the opportunity to speak with anyone like that.
I have many thousands (tens, definitely; hundreds, maybe) of lines of code I've written on GitHub. I also have a blog (not sure I'd call it popular though). In my recent interviews (which I blogged about at length) I don't think _anyone_ had looked at my repos on GitHub. Certainly no one asked questions about those projects. A few had read my blog, however.
A couple times I did show them some of my work on GitHub, primarily a project I was working on at the time that had a UI I could screen share.
Easy to see that you're an old perl hacker that's now into rust and you're active in community stuff that matters (LWN, CPAN).
I feel like you might over-share on your blog in a way that could turn off potential employers, but those are companies you wouldn't want to work for anyway.
I get the vibe you might be opinionated and risky, but are clearly technically competent.
I'd probably put you in a team with other rust-enthusiasts for maximum success. You're likely to inspire newer developers.
You might want to take HTML/CSS/JS off your resume because JS pretty much means React/Vue/Angular these days and you don't seem too interested in that stuff.
That's the sort of stuff I'd check about you before the interview.
Good luck!
I don't think my blog posts had too much of an impact on my offers, although of course I guess some places could've just said no and not told me why.
Have you ever experienced the opposite and been the one that's failed the candidate? Maybe either via a bad job description or answering questions inaccurately or dishonestly? Any times you've had to come clean as the interviewer?
It could be that the reason you are getting the interviews is the Linkedin profile (especially as often companies encourage interviewing people with atypical background), but maybe you fall short of the image you are projecting? The form of the interviews might not help highlight your skills, of course, but it's probably not the only factor.
Typically Olympiad questions takes well-to-do teamwork & few hours of brainstorming - not a 30min timed test you give with a proctor watching your monitor
I don't mind writing MUMPS if I was hired, but the test is not my ability of understanding MUMPS-styled syntax or predicting the win percentage in some chess layouts without using MCTS.
You might as well just say Epic Systems LOL
It's absolutely astounding to me that people must entertain these at a sufficient rate that companies still try to pull this free labor nonsense. One company I interviewed with provided a take-home assignment and said to bill them for the hours; I found that to be a fair offer, although due to other circumstances limiting my available time, I declined to continue the interview at that point.
If the take-home assignment is expected to take a few hours, maybe it's worth considering. Any longer, and they can look elsewhere for free labor. That time is much better spent sending out more applications, networking, leetcoding for FANG interviews, working on personal projects, or simply taking a walk outside.
Calling it "free labor" implies to me that the company is going to get some kind of actual value out of it in the end, other than as a candidate assessment. Most of these types of things I've seen simply haven't been the type of project that would be useful in that sense.
OTOH, the big mistake I see a lot of companies doing is doing a 2+ hour take home assignment, then not making the tech portion of the actual interview process just a discussion of the take home project. If I'm going to commit that amount of my own personal time to your interview process, I want to know that it's going to get me out of at least as much "whiteboard hazing" in the end. In my experience, this frequently has not been the case.
I don't think everyone does this. I certainly have never done this. I've never had an issue getting interviews using an honest accounting of my work experience, and I know as an interviewer I use the candidate's resume as the basis for forming my questions to ask them. I would expect others to do the same. Filling your resume with things you didn't actually do just makes the interview harder.
But after 5 years of failing to get a job offer, I finally caved. Putting in the effort to deeply understand DS/algos and grind away leetcode led me to getting offers I liked and IMO has made me a better engineer.
I now have a “gold star” on my resume and am confident I can still answer most leetcode questions. I consider that time spent as a great time investment, since landing my next job will be much easier.
Money wasn’t my original goal when I got into CS, but it eventually became my driving force. I regret taking so long to notice this, and letting my feelings get in my way (of how it “should be”) / resisting leetcode for so long.
Same, once I realized that the reasons I originally loved programming were never going to present in a my career.
Though currently I'm more tempted to eat the loss, shed the golden handcuffs and go do something else.
Lets be honest. What you want is easier questions. Vague questions that can be discussed and argued one way or the other.
A benefit of this process is that your resume-writing skills improve a lot. Read a hundred or so resumes and you'll learn what catches your eye and what gets ignored.
Alas, nobody else does this. I used to mention this process at places I worked but people thought I was nuts. It worked, though. We rarely had a hire that didn't work out.
I'm confused by this statement. Every company I have worked at for the last 15 years has had hiring managers and usually some senior engineers on the team screen resumes. How else do you even decide who to move to the phone or in-person interview stage?