Wasting time in tech interviews | Hacker News Reader

Wasting time in tech interviews

benjamistan.tech

266 pointscarrozo294 comments

> Despite a long and storied career in software development, I have few abstract problem-solving skills. I proceed through problems in increments, getting slightly better each time. The beneficial thing for you that my experience brings is that I can do it really fast. Fast enough to deliver a working piece of software in a timeframe that won’t bankrupt you.

> Never in my entire career have I whiteboarded a solution that even remotely survived contact with software frameworks, APIs and hardware constraints. A hundred different gotchas and restrictions lay in wait. The only way through them to a resilient solution is one step at a time. So, I can’t show you anything meaningful with Leetcode challenges unless I practice them as a discrete skill.

This, 1000x. This whole piece nails it, but this really jumped out.

I succeed and excel because I actually get things done, rather than "mostly done". No interview methodology ever can hope to screen for this. Or any of the other things mentioned above.

The process is getting worse, not better, and this piece rightly points out why.

You are assuming that the same person can't do both.

If the skill you're hiring for is to iteratively solve a real world problem, then it doesn't matter if someone can do both. You need to find someone who can iteratively solve real world problems.

People might have both, but some people only have one, and not the one you're hiring for. If they can ace Leetcode problems, or unicycle, or speak Klingon, that's lovely but irrelevant, and absolutely pointless to test for in an interview as a proxy for solving real world problems.

then you can work at a FAANG company and get payed handsomely to lock up all that talent selling people things they dont need through ads!!!! Some people see NASA and think of all the smart people who worked there and what they did. me, i see talent wasted on war and i imagine all the great things that these people could of done if they applied their talents to something meaningful.

What war has NASA ever been directly involved in?

The War of Elves and Sauron (not to be confused with the much later War of the Last Alliance)

The War on illiteracy and meaningful reading comprehension.

Even if you really meant "DOD" (Dept of Defense) instead of "NASA" (National Aeronautics & Space Administration, which is not involved in wars), work of the DOD is absolutely necessary to maintain the free society which you and I enjoy.

Unless you want to —literally— live under a Hitler, Stalin, Pol Pot, Mao, or Putin, democracies must always be better armed than autocracies. Autocracies always expand and take over less-well-defended self-determining peoples, and life under an autocracy always gets worse.

Obviously, it would be ideal if we didn't need to constantly and diligently defend ourselves from autocrats and would-be autocrats, they still exist in the world, and we must still defend against them. Yes, mistakes are always made, both in over-defending (e.g., Vietnam, Iraq) and under-defending (e.g., Balkans, Ukraine), but that does not eliminate the necessity. Wishing the world were different does not make it so, as much as you and I would like it to be so.

>> all the great things that these people could of done if they applied their talents to something meaningful.

Also, much of that work actually does get out eventually to products that are meaningful and useful to everyone. GPS, satellite communications, carbon fiber composites, and more are just a few examples of great things created initially for defense work, and that are now used universally. I work in carbon fiber and make things for everything from the DOD to sporting goods for kids.

None of it is a waste (anymore than there is waste and inefficiency inherent in any large organization). I hope that makes you feel a bit better about it.

I was in the "on-site loop" for a company you've likely heard about.

When we were smaller, I was tasked with writing an interview question for JS devs.

I created a handful of unit tests that were all really easy questions technically, though maybe a little obscure, because they were designed to spark dialogue. Think "escape room", solve one test, move to the next. Google was allowed and actively encouraged.

But it wasn't really about the tests (they had to pass, of course, and shockingly some didn't). A not-very-good candidate would still make it to the end and solve all the puzzles and get a rejection.

The goal was to create a lot of jumping off points to sort of "break the 4th wall" and see what the candidate actually does to solve a problem. If I could get someone to search the web as the fastest way to solve something, that was almost always a great sign.

Sometimes I can see them building an inefficient answer and ask them if they'd like to search online for an easier algorithm, and remind them to treat this how they would actually treat their job. Some people stubbornly refused.

If I could get them jazzed to tell me about their editor configuration, that was almost always a good candidate. Because people who care about writing code care about editors. Do you hate vim? Great, tell me why. Do you love emacs? Show me a lisp snippet or whatever you think is cool.

I'd see a lot of `console.log({ foo, bar })` but also some `console.log("foo: " + foo + "\nbar: " + bar)`. I'm not judging harshly on any one particular thing, but I just want to see some level of craftsmanship about something. If you're from the java world, cool, show me some intellij tricks as you're working in webstorm.

Do you reach for the repl/debugger to try out ideas by default? Good sign.

To me it's simple: would I want to work with this person? could I recommend the company hire them based on how they work? I can't actually work with you, so I want the closest thing I can do in an hour that feels like we're on the same team.

I think the question is now retired because it didn't scale, or maybe it's still there with a rubric that invalidates the point of it.

If anyone's trying to do ML in this space, try softball questions that require more search and discussion than code, then NLP the discussion and ignore the code. Use internal mock interviews to train it to match your target culture. I think that would make this approach scale.

I personally found pretty good success with the people I interviewed this way as peers, but I wasn't in a position to find out if they were really successful or not by internal metrics.

Your technique has already been proven to create unconscious bias, because you are more likely to hire people that are like you. You even said it yourself, you want to work with people that you like and that you get along with.

Here's one of hundreds of articles that talk about this:

https://www.forbes.com/sites/forbescoachescouncil/2018/05/01...

Unless there's data that backs your choices vs the ones that you rejected, all you're doing is reinforcing particular stereotypes in your company and in the software industry.

The other alternative is soullessness via standardized tests. Why? Isn’t it better for people to hire people?

> You even said it yourself, you want to work with people that you like and that you get along with.

And you.. don't?

> Unless there's data that backs your choices vs the ones that you rejected, all you're doing is reinforcing particular stereotypes in your company and in the software industry.

I've gotten plenty of training that makes it extremely clear that discrimination based on protected classes is unacceptable in all contexts, especially interviews.

At some point, you have to trust your team to build your team. Not everything can be blindly metrics driven.

You're hiring humans to work with other humans.

The point is to hire people who mastered skills different than what you have. You see interest in text editing as a major factor, but there are probably many software engineers who have no interest in text editing and just writes stuff manually with no focus on tricks, and are still very productive since really writing 100 lines of code is just a few minutes of typing but still plenty for a days worth of work.

> The point is to hire people who mastered skills different than what you have.

That's the job of the other engineers. I only know how to screen for the skills I do have.

Most engineers spend all day in their text editor and on Google, debugging code and searching for solutions.

I have never met a good craftsman that doesn't customize their tools.

I'm not saying everyone has to customize their editor. But if you move quickly and intuitively through the chrome debugger, the only way you got that skill was by doing it every day for way too many hours.

Also, you can learn a lot about how senior someone is by watching how fast they can parse out search results and SO answers.

I customize my shell and tools all day. Editor? Not so much, CUA FTW. In fact had to think five minutes before I remembered my snippets. They’ve been in git for 5-10 years.

> That's the job of the other engineers. I only know how to screen for the skills I do have.

But to strengthen a team you want to add people who have skills the other people in the team lacks, so your interview needs to be able to find such people easily.

In general you want the interview to test that they have done the basics of the work before, that they are smart and that they are nice. Your test helps assert the first, they have done the work before, and the discussion tells you whether they are nice. But it doesn't tell you whether they are smart. And if you think a bit there are probably simpler questions you can ask to check they have done the work that are more general and will pass more people, you want to sort by intelligence and not passion for text editing so the "have they programmed before" question should be as low level as possible and not require any special skills.

The algorithm interview is what the industry settled on to solve this. It tests extremely trivial coding, so you can do the coding if you have ever coded before. The hard part is the algorithms, and that might require some to study, but since it is standardized that becomes a reasonable proxy for intelligence. And social comes from being able to talk about a technical problem and describe what you are doing in a stressful situation, that is good enough to work on a team.

> Also, you can learn a lot about how senior someone is by watching how fast they can parse out search results and SO answers.

This is true, but you don't need to customize anything for that. VSCode text search gets you 99% there.

> I have never met a good craftsman that doesn't customize their tools.

To the contrary, personally I even take some pride I can work on any PC you can possibly give me immediately. This has tons of upsides - from helping someone walking over to them, to knowing tools in their default configurations inside out and explaining keybindings or quirks that are guaranteed to work (and writing better docs).

Programming really isn't about my personality, I want to strip any of that and produce the least amount of very default, simple code anyone can work with. And you don't need to type fast or use scripts to produce that small amount of code.

Largely same goes for debugging, I better create a good logging and monitoring system than spend time tweaking my tools, because that'll immensely benefit the person who maintains the code after I'm gone. Nobody will install my personal tweaks to catch bugs. Granted I mostly work with very good tooling already (C#).

>I've gotten plenty of training that makes it extremely clear that discrimination based on protected classes is unacceptable in all contexts

There are plenty of cases where discrimination against unprotected classes still happens. Cases where studies cannot find a correlation between selected candidates and things like retention rate, performance etc. These include cases where one would be skipped over despite having personality attributes the team is sorely lacking.

>You're hiring humans to work with other humans.

It's because we work together as humans, most of the things you said don't really matter. Most humans can work together despite their differences. That's one huge problem with hiring as a whole, trying to find carbon copies of each other while espousing they value diversity.

That's not to mention all this "one of us" hoo-ha just stimulates chameleon behavior. Which benefits the person opposite of you, but it doesn't do you much favor in the long run.

> And you.. don't?

The problem in this situation is that YOU are the one acting as a gatekeeper as to who gets into the company.

The company should be the one setting the standards, and determine the best person for the job, and you should be able to work with whoever is best suited for the job, regardless of whether or not you like them.

This is where the unconscious bias comes from.

If he said it himself, then it’s not an unconscious bias, is it?

The point of interviewing is bias in the first place - to find people who are good - and it’s not unreasonable to assume that “I want to be good” and “this potential hire is good” would result in correlated features

If one can’t escape or compensate for it, then it doesn’t matter if it’s conscious or unconscious bias.

You can escape it by becoming a better software engineer.

Up to the limit of your IQ, which is the real bias that everyone sweeps under the rug, especially all the bigtech companies espousing “inclusivity” (all lies, actually exclusivity, as they don’t hire most people, especially stupid people).

> You can escape it by becoming a better software engineer.

Why? Are better software engineers less biased? Why would that be? I would assume that they are human, and therefore just as prone to biases, like everyone else.

Rationality doesn't work when studies have repeatedly found virtually no correlation between 'someone good doing hiring as they like' and good candidates in the context of retention, performance, and more.

Even rationally it doesn't make much sense. You're judging people on what they do in a year given how much an individual likes them and believes them to be good given a day's worth of input. Even if such an individual finds a lot of 'good' hits, nothing would tell them if it was this particular selection mechanism, other selection mechanisms, the workplace, luck, or none of them. The same goes the other way around for 'bad' hits.

Not to mention, if rationality worked, we'd see 'years of experience' have great correlation with 'good' candidates. Yet YoE always fails to contribute greatly given the presence of other metrics.

Cool, next time you're hiring, remember this and hire someone with no experience, no technical interviewing, just by "divine inspiration" (a.k.a. your emotions) and/or chance.

sounds like a “who is smarter” pissing contest.

> If I could get someone to search the web as the fastest way to solve something, that was almost always a great sign.

Interesting how things change. At a big, known software company they used to put a candidate at a computer running Visual Studio and ask him/her to write a program. That program would be impossible to code without including multiple winapi(?) calls and neither help nor internet were available. This was around late 90s/early 00s.

>If I could get them jazzed to tell me about their editor configuration, that was almost always a good candidate. Because people who care about writing code care about editors.

I agree with much of your post, but just wanted to point out that many of these things are not universal. I personally have little interest in code editors and even less in discussing them, though I do use Emacs and will probably never invest in learning another editor. It's just a tool to me though, and writing custom lisp functions to make it work just how I want has just never been of my thing.

If I could get you to express that in an interview, I'd say something like "do you have any tools you find value in customizing?" and try to lead the direction in whatever you think of as "custom" in your world, so I can hear how it helps you be effective, so I can understand what you think it means to be effective.

I probably shouldn't have picked text editor as the example, it's really not about that.

> "do you have any tools you find value in customizing?"

Anecdata: don't think I have any? My best tools for years were pencil and paper, and I usually get things done, very fast.

To which my answer would be: I've been in this game for 25 years. I lost my will to configure long ago, and now just use the default. The default is better tested, good enough for most tasks, and doesn't leave you hobbled whenever you have to work on a fresh machine as you try to remember what custom things you had set up, or if your config git repo is properly up to date and doesn't introduce unwanted dependencies (or if you can even connect to it).

It's also a major source of WFM (works for me) syndrome, where something in your custom stuff is unintentionally needed by the build.

I'd rather be building things than playing with my tools. If I really need something esoteric, I'll find another tool or write a Python script

lol. This is why I reach for vi

Same for me, a custom configured environment has often become yet one more thing that can break and needs maintenance. I make sure I have basic emacs keybindings but that’s almost it. In my experience, the people that spend most time on customizing the tools have mostly been junior developers. Though if you asked me on productivity tools we’d have an interesting discussion. I guess it’s just a matter of focus.

I find value in tools that don't need much customizing.

A lot of the effort people devote to customizing their tools doesn't seem to be about productivity or effectiveness in any measurable sense.

Echoing the other comment about bias, it seems like a strong personal preference of yours, but it's unclear whether this is actually a good indicator of a strong fit or not.

Like @kstenerud, I tend to keep the default settings as I am happy to just learn the default to at least avoid things from breaking, when the next IT/infrastructure update happens at "the company", or maybe I have to use a clean machine to do some coding.

Instead, I spend some time to look how I can be more productive (keyboard shortcuts, etc), and then will just leave it at that. I've had both types of colleagues: customizing/non-customizing, both types have been high performing.

Similar to other replies, I also am not so interested in customizing my tools. I use a small number of tools and as out of the box as possible (but learn them well). If you led the conversation in that direction I'd probably try to steer it away.

So it's horses for courses.

Yeah editor chat isn’t a bad sign, I enjoy it, but I also don’t put a whole lot of stock in it. It’s a plus if someone can explain their editor choice through original arguments delivered with passion and conviction, but that applies to any number of technical topics.

If I could get them jazzed to tell me about their editor configuration, that was almost always a good candidate. Because people who care about writing code care about editors.

I've spent a great deal of time modifying my editor config. I advocate for "tools day" where I work, which is a day where a team get together to share ideas about tooling and collaborate on config to make the team more productive. I regularly share what I change in my config with people.

I couldn't spend more than 30 seconds talking about it though. I have a problem, I solve it, I share the solution, and I spend no time or effort remembering what I did after that. It's one of the least interesting things about dev...

The same here, but to such an extent that it sometimes becomes a problem during interviews. For example I hate laptop trackpads, I always use a mouse, so then during a tech interview they give you the crappiest laptop imaginable without a mouse.

I also for example press F7 to compile (along with 20 other shortcuts), so when confronted with a generic editor in a test I'm again wasting half my time struggling around on it.

I find editor usage quite interesting, in fact. I’m responsible for mentoring and training other developers, and mastery of an IDE is the easiest, biggest win you can get for productivity.

How do I easily attach the debugger? How do I jump between recent files? How do I use column mode to fix a bunch of sample data? How do I jump between file and test?

Junior devs by and large can’t do any of these things, and it has a material impact on work output. So I teach them.

What I liked about Square’s pair programming interview is that they would tell you its about these things instead of smugly hiding them as dark patterns.

There are waaaay more interviews that say you can use a search engine and then take points off for doing it. There are way more interviews that are more like academia that rely on rote memorization for an assessment and would consider reference material cheating.

Industry needs a trade group just for interviewing practices. You’re so confident in what you wrote its comical.

Leetcode-style interviews : software engineering :: auditions : acting

Auditioning is nothing like being an actor, but that's primarily the only way actors get gigs. Unless you're so well-known that they seek you out. This is exactly the same thing as in programming. You have to submit yourself to a humiliating barrage of LC and systems design questions because that's how companies like Google have decided that's the best way to determine talent. And based on their multi-trillion dollar valuation, it's hard to say that they're wrong.

So unfortunately, unless you can come up with a better way, auditioning for your software engineering job is here to stay, just like auditioning for your acting job. So you might as well accept it.

Isn't it true that contractors/freelancers aren't expected to do leetcode interviews?

it's probably also true that if they're working for a livable wage they also have a decent portfolio...

How do we know that this is the case?

There was a period when I was looking for freelance gigs via Upwork - I had to send hundreds of applications to get a single few hours worth order. May be it gets better with a higher rating but I never got to this point. I would rather spend a month preparing to leetcode style interviews than spend it writing Upwork applications.

But Upwork is not necessary for this kind of work. In fact, only a small portion of freelancers are on those kind of platforms.

Nope, not true. I’ve been contracting for 15 years and regularly encounter leetcode interviews.

When I can, I’ll outright ask if the client intends to do this kind of interview. If they say yes, I’ll explain my objection to the process and if they aren’t willing to modify their interview approach for me I will decline the interview.

I have on occasion had this sprung on my without warning halfway through an interview and I’ve declined to do it; most of the time I get hired anyway.

Whenever I can I try to convince hiring managers (and I’ve been one myself) to ditch leetcode nonsense for future interviews.

> modify their interview approach for me

What do you like instead of LC?

I think the issue with LC for contractors is unpaid work resulting is the loss of opportunity with other potential clients due to the effort involved. The equation is fundamentally different than for a salaried employee.

valuations are mostly made up and they have nothing to do with how they hire.

and you are wrong that it’s there to stay. if people decide to no longer play ball and organize that will be the end of it.

the current system was created by a single woman who simply created it to build a consulting business around it. and you are all too naieve to see it.

It's ridiculous to imply that Google and Facebook aren't one of the most successful companies in the history of the world. And there's no way they could have made it to one of the most successful companies in history with a company full of terrible employees.

you need to ask the question, why they became succesful and why they are still here, collecting data about you every day. they know you better than yourself.

> created by a single woman who simply created it to build a consulting business

Who's that? (I don't agree but I'm curious about your opinions anyway)

the author of cracking the coding interview

Ok thanks (was a bit who I was guessing you'd mention :-))

>So unfortunately, unless you can come up with a better way, auditioning for your software engineering job is here to stay, just like auditioning for your acting job. So you might as well accept it.

If I was able to come up with a better way, I would sell it to Google and never work a day again in my life.

Pointing out that current methods suck is free advice, though.

Not sure about this. Past a certain level of experience (and given some prior knowledge of the system being worked on) I’d expect someone’s white boarded designs to come out close to the mark at least some of the time. Not always, maybe not even half the time, but “never in my entire career” would surprise me.

Hm, his GitHub profile starts in 2017, before that according to his LinkedIn profile he was a project manager, and since then works as a DevOps guy. Though he was already writing SQL migrations in 2008 (from MySQL to SQL Server 2005). ¯\_(ツ)_/¯

It's not terribly surprising to me that he simply doesn't have experience with coming up with architectures on the spot. Doing interviews is hard, from both sides. No candidate wants to seem arrogant by explaining that why the question/task/problem is bad in the context[0], so the frustration remains and gets vented in blog posts.

[0] Because roles (job descriptions) in the tech industry is so vague, and goes through so many hands. (HR, recruiter, engineering managers, job portals, etc...) And by the time the interview happens it's no wonder the parties have a lot of mismatched expectations of each other. And that's just the baseline, what the post describes is just plain old fucking shitty behavior in a shit job market.

> It's not terribly surprising to me that he simply doesn't have experience with coming up with architectures on the spot.

Or, maybe they spent their career mostly building applications and not architecting systems. Those are very distinct skills.

Of course, it also doesn't help that in an interview context, "system design" can mean "design infrastructure to support a system," or "object-oriented design of a system."

Not only that, whiteboarding a design will bring up lots of the issues you'd otherwise find in those small steps anyway. It just shifts them left - boasting about purposefully delaying finding them is not great.

Sorry but your parent post is right.

It's not realistic to day dream yourself to a real product.

I realised this from the waterfall model days itself, where elaborate documents used to be written before we even wrote a single line of code. And every single time the paper planning would be totally useless and nothing like what the original deliverable would turn out to be.

"totally useless". maybe just "useless". my experience is you learned a lot about the problem domain and the system constraints during the creation of those documents. you didn't learn enough to solve the problem, but it got you started.

There's a lot these tests don't pick up for sure. I feel soft skills is one and being focused on the day to day tasks is another. By hiring based on drills you run this risk of hiring a nasty or emotional person that just wants to use framework x rather than do any of the mundane bill paying work. If soccer teams started hiring based on ball-juggling skills they'd be full of street perfromers and clowns rather than world class strikers. I find tests are really bad for generalists too or older people who can't remember vividly the math they did at school. However we gotta suck it up and it is quite fun refreshing some skills and knowledge between gigs. What's worse is when you pass the tests but then don't get the job. Makes you feel it was something about you personally.

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

Recruiters get paid per interview? Or directly when someone got hired?

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

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.

Aha, they're happy with mediocre hires, just good enough -- although it could have been (much) better for the company with another person

A bit misaligned incentives in the same way as agencies have, I'm thinking

Same... and I got scolded by an recruiter after she asked me more questions about my experience.

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

Would they think you’re inexperienced though?

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 is ATS? ... Aha, applicant tracking software? So you got rejected automatically by a machine? How annoying.

I could slightly understand if some people write whatever in their CVs if they're trying to get past the machines

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.

That's a fair point. We do very little algorithmic/automated filtering, so I'm biased in my predilection.

If you use a headhunting firm, they certainly do.

We don't, at least to my knowledge.

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?

[1] https://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-pr...

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.

Still sounds like a good ratio, I'd say.

Live coding isn't very, but I found live code review + occasional adjustments quite effective when interviewing candidates.

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

>I wouldn't like to work in a place where most people lied to get a job.

"A place where most people lied to get a (tech) job", is the world. And the world is the only place that has jobs.

Software is hot only in the sense that there are “jobs” available. Whether or not those jobs are good or pay well is another factor.

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.

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

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.

>And that is why we all have to go through onerous tech interviews, despite listing our experience on our resumes.

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.

In fact, these are the exactly the kind of people that the LC process is designed to filter for.

How is studying programming considered cheating?

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.

I don't know how one can study leetcode and fail to learn to program better.

After all, I learned chemistry, physics, math, mechanics, thermodynamics, etc., by working problem sets.

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

Out of curiosity, what knowledge about electricity and chemistry did you have that prevented the mistakes?

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 you are investing $500,000 of your own money, are you going to check it out thoroughly first?

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

I don't see what that has to do with what I wrote.

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

I didn't write "have to". Perhaps you are replying to someone else?

https://news.ycombinator.com/item?id=31902260

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

That comment,

> 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

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 that do a poor job of hiring and retention tend to fail. It's a self-correcting process.

Government, on the other hand, just increases the budget.

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.

The CV needs to present well and be credible.

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.

Resume truth isn't the same as spoken truth.

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.

I am on the humble side in my resume and I have landed a job that pays well, but for which I am completely overqualified for.

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.

> how efficiently you can forget information that

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

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.

Stay with the truth!

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.

> Alas, nobody else does this.

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?

I've probably triaged 1000 resumes over the years, across three different companies.

can you post some examples of these. would love to hear what makes a resume stand out and is actually leading to a good hire.

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.

> Money wasn’t my original goal when I got into CS, but it eventually became my driving force.

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.

Achieve financial independence first. You never know what life will throw at you

I'm in the software business for over 20 years. Currently working as an architect, but still do a lot of coding daily. I believe I have a pretty good grasp on computer science concepts. Know several programming languages very well. Keep myself up to date with the latest trends.

I couldn't pass a technical interview. At some point in life I gave up. I realized the only way I can get a good job is via somebody in the company knowing me, ideally them reaching out to me to work for them. For the jobs, where I passed the technical interviews, I quit fairly quickly, as they were horrible jobs.

So when doing interviews myself, I just chat with them about the project we have and things they mentioned on their CV. You can easily detect if they are honest in their CV and their level of competence without actually asking too many technical questions, just by having them talk about the stuff on their CV.

I'll give my 2 cents on why larger firms strongly emphasize these white boarding skills.

In an organization of ~500+ highly paid and (hopefully) competent engineers - there is a very high premium on outward signs of technical competence. If a fresh college grad isn't quite sure that their "senior" is really "senior" - or worse a neighboring manager becomes displeased, then there is a problem. Similarly in very large code bases with heavy testing and performance requirements, iteration times can become slow... resulting in a stronger need for planning, design, debate etc.

The white board technical interview effectively tests that you can communicate competently on an arbitrary coding/design topic. An inability to do this can be a death sentence in a large, interconnected engineering organization.

Yep, that's the thing. I'm bad at on-the-spot communication. My mental process is too complicated and during the pauses when it's happening, I show all aspects of an incompetent person. If I have the time to think/prepare for a particular topic, you get a very difference experience. But yeah, for large companies, having a quick brain and being able to talk about anything pretty much immediately is a very useful skill.

| interconnect engineering organization

Have you worked at FAANG before? Their "interconnectedness" is near non-existent.

I'd agree if you'd say that some teams are well connected. I'd also agree if you mentioned that these teams are almost always senior+ level engineers. These are not easy teams to join... In my experience they're almost impossible to join without connections.

I think @lukaslalinsky has a much better opinion on this.

That being said I think your point is valid for companies which do have pronounced non-siloing culture... But, in my experience, those companies haven't given me white boarding or LC style interview questions ;-).

Google and Facebook doesn't silo their teams, and they have harder algorithmic interviews than Amazon or Apple (although Amazon and Apple focus more on other skills).

I have a close friend who's at Google and disagrees with this.

I have, and the interconnectedness is strong. Even a junior engineer's work is visible to a group of 30-100 people typically. If someone is missing what's interpreted as "Basics" then it will become apparent quickly. Basics here could mean "putting out sloppy CRs/Designs", not communicating timelines well, or when problems arise - not addressing them in a way that everyone else on the team thinks is correct.

Bear in mind that most FAANGs are also built on 20-30 years of fast paced technical development. There are services built on top of internal frameworks, built on top of internal frameworks that sometimes haven't been maintained in 5-10 years. Searching for the answer is many times impossible.

Glad you've had a positive experience with it. All I'm arguing is it's much less likely that an entire company has this versus a particular org or even a specific set of teams.

I have many friends at FAANG and many of them would disagree with your take on them being interconnected and definitely lean more toward it being team dependent. This also is similar to my experience.

Totally Agree. It is also very insightful for the recruiter and vey fair (time wise compared to take-home assignments) to the candidate.

> You’re never going to check, are you?

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

Contra this, cover letters aren't popular (at least for SWE hiring) in my experience, because nobody reads them.

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.

Good luck!

Thanks for the kind words. I ended up at MongoDB and I've been there about 7 weeks now.

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.

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

Interviewing gets discussed a lot here. Very little actually gets improved. If you want a (1) high paying job (2) and want to work on products that scale to millions, there's just no way you can escape leetcode style interviews. I've 2 decades of experience and have resisted it for sometime, but eventually gave in. These companies have way too many candidates to filter, so unless you're one of those inventors of popular frameworks like Tensorflow/Pytorch, you've to go through the grind. And with the popularity of blogs/tutorials/coaching classes the bar is only increasing. 2 medium problems in 30 mins is not a joke unless you've solved the same problems before or solved hundreds to quickly decipher the patterns. All this really breaks the back of staff/sr. staff level folks who rather choose to stay where they are even if that means lesser pay.

I don't want agree but I do.

I think there might be an alternate to leet code studying. I did Advent of Code (AoC) in 2019 to learn a new language. I then did some interviewing, and remember a few things on leet code problems "oh, this just like this AoC problem" and applying the same skill set.

So maybe doing AoC and solving funny Elf and Sleigh problems could be more fun? Maybe not as efficient though. ;)

AOC is way more engaging than any leetcode problems I've ever done, but I wonder if that's because I could choose whatever language I want or a feel allows me to best express the solution.

Not sure what you're talking about; Leetcode also allows you to choose any language.

From a limited selection that they offer...

Which one are you looking for? LC has 17 different languages available right now.

As a counterpoint, I did most of the recent AoC after grinding leetcode for work -- I felt like LC was much more efficient. I wouldn't prep for a serious job interview (FAANG) with just AoC.

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.

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.

Isn't that all any computer program is? Every AAA game is just moving input from the keyboard and mouse to the video card and network.

The devil is in the details, of course.

Yes, this trivialization of modern software development is annoying. Yes, we are modern-day plumbers. Turns out, plumbing can be hard.

I don't think so but cars are easy: just some rubber wheels glued to a steel chassi, and batteries. Shouldn't be allowed to be so expensive

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.

> MLOps

New buzzword for me today.

Not a buzzword, MLOps is legit. It basically means taking care of ML pipelines: https://databricks.com/glossary/mlops

> think it's also a major waste of time to complain about it

About as much as complaining about complaining.

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.

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.

The point was that the GitHub should not be used which he said up front -_-

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've said this before, but I'll share it here. This is my current interview process for any front end dev, regardless of level, including the thinking that goes into it. The whole thing is designed to take 2 hours or less. Note: We provide either a physical laptop if onsite, or an AWS box pre-set up for this.

1. Here's a project with a back end API server, it's a repository already cloned to disk, and includes a README.md with very detailed (local) deployment instructions, that one can copy+paste. Thinking: Validates the individual's ability to read, and synthesise

2. Run the API server - this in turn provides a swagger API, that allows users to see the available APIs in their browser, and instructions to do so. The machine has various chrome plugins, Postman, curl, etc pre-installed. Thinking: Validates curiosity, and basic understanding of the modern(ish) web.

3. The candidate is to create a new project (framework of their choosing). They have the time of their choosing to implement an impossible to complete task (which we share). They have to create <something> that can trigger various APIs to insert, update, and remove data from a database. We provide the sample data in text files such that copy+paste is possible. Thinking: Validates if and how they reach out for assistance. Helps us understand where the candidate likes to spend the time of their choosing while working on a solution. Encourages a conversation about difficulties, frustrations, what could have gone better, and feedback.

This entire process is designed to ensure that we actively interview the candidate with something "real". It allows us to understand the real level of a candidate based on their efforts (i.e write tests, don't write tests). This is not perfect - but it's the best we could get. I'd love feedback.

To put on a devil's advocate hat: This is a great interview for someone whose job will be to create basic CRUD web/mobile apps.

And there's nothing wrong with that! 90 (99?) of the software the world needs are basic CRUD web/mobile apps. Hell, for probably 60% of that, a basic no-frills CRUD app would be an improvement!

But HackerNews measures it's baseline of the tech industry against "BigTech". That's more than FAANG, that's now also the 500+ unicorns imitating FAANG.

All these unicorns don't get to where they are by building CRUD Apps - They're Changing The World. (facetious)

And changing the world (serious now) requires not hiring engineers who can build CRUD apps with a database, but engineers who could build the database, the next Swagger, etc.

The bad thing about this is that they (BigTech) can afford to hire the next Edison and have him build CRUD apps in 60h shifts trying to pass performance reviews... And even get away with it financially (for a time at least).

I'll be blunt: your hiring process sounds very similar to what this article is trying to ridicule.

If I was handed someone else's machine preinstalled with a load of tools that you assume I know how to use, I'd probably excuse myself from your interview. What if I use a different keyboard layout? What if I don't use a Mac/Windows? What if I've never used Swagger?

Unless you explicitly highlight to a candidate how 3 is impossible, you are excluding candidates who would do what you want in a real job, but not in an interview setting.

When I was younger, I was always stumped by "trivial" questions, as in why would someone ask me a question with an obvious answer (though my pool of "obvious" answers was pretty large, so I had to tone down those expectations as well)? I've learned to consider all questions in the simplest way possible, but my brain simply glosses over those otherwise, and especially in a test setting, I might look to see if I am missing something ("what's the caveat?").

Curiously, I also do pretty good in leetcode style questions, but I think people are usually taken aback by the number of things I consider simple (I appear to not know shit simply because I avoid talking in big words ;)).

While I applaud your effort in keeping the process simple and "real", keep in mind that nothing beats saying explicitly what you are after with each stage: most people in "interview mode" think differently from "get stuff done mode".

> Unless you explicitly highlight to a candidate how 3 is impossible, you are excluding candidates who would do what you want in a real job, but not in an interview setting.

That's exactly what we do. We make it abundantly clear that it's not possible, nor is the expectation such that it happens. We also turn this into a collaboration and pairing role, with times to dive in and out.. pretty much like exactly what this role entails.

This is how we avoid the "take away assignment" or "l33tc0de" problem. We invest in our technical interviews. Similarly - we let candidates know in advance that this is exactly how they take place, and that they're free to use their own equipment if they prefer. The idea is to "simulate" work.

This doesn't replace the need to go deeper. Instead, this eliminates a very specific type of filter, in exchange for getting to know each other, collaborating, and hopefully mutual understanding.

That's great to hear!

As for going deeper, I don't think there's a way for someone to go deep enough without actually putting them on the job :)

>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 have more than a decade of experience in SWE and a resume that boasts big tech names. If you hired me based on my GitHub, I would not have a job.

Truth be told, I haven’t used public git since undergrad (for assignments). I don’t do extra curricular projects. Mostly because I don’t have the time to. I’ve never had it, except maybe the first year of my professional experience. All the free time I have if any, goes towards other projects that I do at work. And honestly, I am okay with that. Building a portfolio takes a lot of time, and it becomes irrelevant real fast. It is also, a waste of time.

I recently got kicked from a hiring process after a good third round call with the CTO because at some point I’d refused to do a leetcode. I hadn’t, but I had pushed back and asked why round one was a hackerank round, when it was a senior management SRE-team position. Not normally a role with a lot of leetcode. I’d only asked why it was necessary, not refused it. In that actual interview the interviewer (their principle engineer) said he’d looked at my resume as prep, wondered why HR even scheduled a leetcode and skipped the code review and asked questions instead.

He passed me. 2 rounds later the recruiter decided he didn’t lie I’d pushed back early on.

Personally I hate leetcode style challenges and seldom use them. Designing our recent hiring process for our org I included a take-home, but made sure it:

- time limited to 2-4 hours

- had the team practice and verify it’s doable

- clear objectives

- clear marking criteria

- any language they want

It came down to a somewhat typical platform eng/sre/DevOps type task of working with APIs, so chose our company’s public API, so it’s somewhat relevant and interesting, and asking the candidate to write something to read and process our API data.

The really key goal being to weed out people who:

- just can’t write any code at all

- don’t approach problems in a code-first repeatable way.

I learn a lot through running it, and improved the take-home in many ways based on feedback.

The rubric offered the option to do it in a session as a leet-code style round, no one ever asked for that out of hundreds of candidates.

the best take homes i ever had were of this sort - public api, clear measurable goals, any language/framework you want

then even if you dont get the job at least you feel you've learned something or proven to yourself you can handle a challenge

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.

In your next employer, if your recruiter is game, just do what I suggest upthread, don't bother asking permission.

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.

Ah that's fair. I do it for the warm and fuzzies, not for my own self-interest.

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?

> 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 don't think saying hello opens yourself up to lawsuits in the same way.

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

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.

I had a github profile once, but a conflict with the Go team lead to my account being blacklisted (flagged). So I deleted 150+ repos from it and the account. I host my own gogs and recently gitea instances now and there is little public code there. The public code is not representative and I won't give you access to my private code.

I also won't do pre-noon interviews.

If you start pressuring me I'll revoke the application.

You can be lucky I even applied to your company, despite all the bs buzzword requirements you have posted you have no clue about what they mean.

I am very angry at current hype driven job ads. And yes I wager they're more of an ad for the company than actual job ads.

From some ads where I sent my application to I have never even heard back, which means they probably sold my info.

Even reading all those job ads is tiresome. Most don't even write if they're ok with 100% remote. Most don't even write if it's ok to not work 100% full time. Most don't write how much they're willing to pay. Most job ads are just a waste of time spicked with bs trendy buzzwords.

I'm so pissed at the whole state of everything.

Context: I am myself a tech lead / team manager and at the moment I try to recruit a more senior developer.

My way to assess candidates differ from the style the blog describes, but of course I do some kind of technical screening. From my point of view, this blog, obviously, just describes the view of the candidate. And maybe this person is quite good at his job. But you have to consider, that you get a lot of candidates who can't get things done. I screen candidates who want to do a PhD in computer science but write code like we are 20 years or more in the past. I get candidates with a degree in computer science who do a little programming task that won't compile at all.

What I want to say is, don't underestimate the sheer number of people who apply (or get brought in by recruiting companies) who, to be honest, cant develop software that's a little more complex.

I'm honestly curios, so please bear with me.

All the HN threads about recruiting mention this. I get the argument, and yes, there seems to be no better way than to test the candidate (no matter if it is a take home test, online, or onsite). As I see it, most of these tests are about algorithms and data structures, not real, practical problems the company has/had.

What I do not get is the following. Most companies (especially FAANG) demand a CS degree and then give you those coding tests about algorithms and data structures your degree actually proves you know about. If the candidate got the degree thirty years ago, then (maybe) fine. But even candidates fresh out of university? And even if you do not recall them in an instant, your degree should prove you can successfully research and understand them. Is a CS degree actually anything worth then, if I still have to prove this knowledge every time I apply for a job? And if it's not about theoretical things, why demand a degree and test for theoretical knowledge instead of practical problem solving skills?

I live and work in germany so the environment might be way different then in the us or other countries. What I do is a small programming task that candidates can do in there own time frame at home. For the task you have to implement one interface consisting of 2 methods. Its nothing special in terms of computer science. What do I look for in the solutions I get? - Is the code readable? - Does it compile - Are there any unit tests - The implementation needs to work with the filesystem, how is that solved and how is it tested (if it is tested)? - Is there some kind of error handling? I check these points and in the next interview with the candidate I discuss the solution with him or her.

The whole "demanding a CS degree" thing is just another filter. FAANG can afford to apply a ton of arbitrary filters and still get enough good candidates to fill their ranks.

OTOH, I am hiring for the startup I work for, and I explicitly don't require a CS degree, or any degree whatsoever in my job descriptions. It's not just because I don't have a CS degree myself (my degrees are in math), but because nobody gives a shit what degrees anybody has here as long as they can do the job. Conversely, you can have a CS degree from the #1 school in the world, and I don't give a damn if you can't do the job.

As someone who is 98% done with my CS degree, at a decent school, I think that 50% of fellow graduate cheated or had enough help from roommates to the point where a CS degree doesn't mean anything.

I once found myself in a small friendship that I found was fake (recognized someone from a large group project in my algorithms class) and he asked me for help on a problem so I went to meet him with the intention of helping while still following the academic policy. It then turned out to be 8-10 people all around a giant table passing a laptop around giving different problems a try. I subtly asked how they didn't get caught and they said they would complete a pset, distribute it to everyone at the table and on their own time would change things around.

Actually, if you get stuck on any problem you can just go to office hours and I've even seen TAs just typing code on a student's laptop.

My roommate TA'd a 4000-level class once and said that a lot of assignments looked similar to each other but no one went after anybody for honor code violations.

I absolutely believe it's possible to graduate without knowing much about CS or programming.

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.

> a well-to do medical software company based out of Verona, WI

You might as well just say Epic Systems LOL

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.

Interviewing in tech is a mess especially with the self-aggrandizing questions.

Besides the questions, you get interviewed by recruiters. The recruiter, very likely a person that has never done anything technical, been in a technical team, delivered products/features under tight timelines...

Companies do not want their engineers and product people spending time interviewing prospects, so they throw recruiters at the problem and end up frustrating and wasting the time of other engineers. Like, it's your problem, not ours.

If a recruiter reaches out and I'm interested, I ask to talk to someone technical.

> If a recruiter reaches out and I'm interested, I ask to talk to someone technical.

How do you phrase this? What are some successes and failures you've encountered with this approach?

I recently had a first round interview with a hiring manager, not a recruiter. It served as the screening call and hiring manager call.

I was a bit surprised, as I’ve long said how much I want to talk to the HM as early as absolutely possible.

Of course then I learned said HM had only been at the org for two months and the entire Infra team was ostensibly just the hiring manager on the other side of the zoom call and I was suddenly a great deal less enthused and interested in the role.

> Of course then I learned said HM had only been at the org for two months and the entire Infra team was ostensibly just the hiring manager on the other side of the zoom call and I was suddenly a great deal less enthused and interested in the role.

Why?

Rant incoming, you asked for it ;)

Having been in organizations where the Devops/Infra org was brand new, it's not something I'm remotely eager to be a part of again.

Some people have the tolerance to be the 'founding' Devops/SRE talent, who help the company go through that "transformation" from the ground up, implement the IR process, create the standards, win the hearts and change the minds, and thrive when the Devops tradecraft and practice is very new to the parent organization.

I'm not one of those people.

Some people would balk and say "shouldn't this be done by a CTO?"

and my honest answer would be "I don't know anymore", because I really don't. I keep hearing Devops needs buy in from the top. And I used to think so too. Then I found myself eight years into this field and seeing the rhetoric was CONSISTENTLY failing to match the reality of whatever the hell we're "supposed" to be doing in Devops, because it can mean whatever the org needs it to mean. And I'm just cynical enough to think, nowadays, that companies know this. They know they can just slap the Devops job title or SRE job title on any assortment of tasks that do not improve developer experiences, minimize toil, improve quality or provide visibility to applications, services and infrastructure and get droves of candidates.

So many Devops/SRE job descriptions lately point out the painful truth that so many companies are cargo culting their way through operations; they don't know what they actually need, they don't know who they need to be hiring, and as a result you end up with companies hiring "Devops enginees" to do any kind of technology work that isn't writing app features or building a product thing.

I've gotten around this by having a litany of very specific questions I ask in interviews (which have been commented on "wow you ask some VERY tough questions". Yes. I know. That's intentional), and a pencil cup full of little yellow, orange and red flags that I look for when deciding if I want to continue interviewing at an organization or not.

"Our devops team is brand new, I'm the manager, and I just started a month ago"

is one such red flag. Doesn't mean it's a bad organization or they have bad people, just that it's a bad organization for me.

> Some people have the tolerance to be the 'founding' Devops/SRE talent, who help the company go through that "transformation" from the ground up, implement the IR process, create the standards, win the hearts and change the minds, and thrive when the Devops tradecraft and practice is very new to the parent organization.

As someone who has been this founding engineer in the past, in my experience, this is a fun situation to find yourself. There is rarely a "win the hearts and minds" aspect when at such an early stage. As long as it works, you're golden. You literally get to call all the shots, pick all the tech, lay the foundation and the bill really only comes du when you're building a team around it and your engineering hires start asking questions. They're usually good questions, and are usually known issues (although sometimes you can learn a lot from another experienced engineer assessing your architecture), but it becomes work from that point forward. Assuming you get that far, which if you do you've largely succeeded as engineer #1 as your technical decisions didn't take the company down with them.

It seems like companies do this because the stakes are so high to them. That is, if you hire this person and they fail, they will somehow do serious damage to the company. If you do this at a large enough scale, then you are putting the company in serious danger.

How do you de-risk this? My take would be to focus on getting "good enough" candidates in and then if they don't work out, be able to fire them easily. It's tough to normalize that. It's legal in states that have at-will employment but it seems that there are still taboos to doing that.

The problem with firing people isn't with how hard it is. It's with the effect firing has on morale and culture of those that remain.

As a dev, the moment someone on my team is fired for performance is the moment I'm looking for a job elsewhere.

It's like the minimum wage; nobody actually does it.

Every US state is at-will. The only state that significantly varies from this is Montana, wherein employment is at-will for only the first six months of employment, which would cover your case here.

https://www.paycor.com/resource-center/articles/employment-a...

I think the taboos are less around the law and more around trying to avoid a reputation that the company will can you a couple months after you've perhaps uprooted your life and moved to a whole new city. I wonder if the taboo will lessen in remote work contexts, where the employee is not so expected to uproot their lives for a job.

Things like this are why I'm glad I live in a country with sensible employment laws.

Firing people willy-nilly SHOULD be taboo, if you find yourself firing people all the time then you're the problem not the people you're firing. Make an effort to support and develop people rather than looking for mythical unicorn candidates.

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.

Yeah agreed. It's like setting up a new repo, or configuring a new machine. It's done seldom enough that you may as well Google it each time.

Avoiding the p1ssing contest is very important, as well as ensuring we don't have egotistical a-holes interviewing.

In a role we're currently interviewing for, we intentionally ask deep-dive style questions. We first explain our approach by telling the candidate we don't necessarily care about the answer; we seek to assess aptitude, rather than ability, and so we ask the candidate to be as vocal as possible to display their reasoning. So far, it has helped us narrow-down the pool to two promising candidates. Of course, we also mention in the interview that, "we'd make liberal use of google, and we understand that most other people would too" - but some of our better interviews have turned into pleasant, fruitful technical discussions, and not just a back-and-forth "pub quiz". Just my $0.02.

I gotta agree here. I don't do leetcode challenges. There was one point in my life where I began studying them to pass these filters, but I rather be doing anything else than leetcode...so I stopped. I've never been unemployed so its easy for me to decline jobs when they present me with these challenges. If I were ever out of a job and struggling to get a job I am pretty sure that would change my tune. Until then I reject those companies.

Now thats not to say I won't do coding assignments, but I weigh those pretty heavily. If the employer seems pretty amazing I'll do them, if they seem meh then I decline.

On the flip side, I've had interviews where they asked me no technical questions and no coding challenges. That is an enormous red flag to me.

High tech interviews are as much a personality test as a test of intellect. What do people do when they buy a car? They kick the tires, bounce it on it's shocks to see how it responds, get in and hit the gas hard, take it fast around a few corners. If the interview was about what you're supposed to know it wouldn't be too stressful, would it? No, they want to hit you with some curveballs from multiple people and see if you fly off the handle or handle it with grace and humor. Humor especially. If you can make people smile or laugh you have a much better chance. That's been my experience. I've failed every interview where I got angry, even if I didn't express it. They could tell.

Reading the comments on these kinds of HN posts stresses me out. Not for me, but for you.

I wish I could just give you all a big hug and a pep talk.

The demand for software engineers is expanding faster than new engineers are minted. There are lots of excellent, well-paying jobs going unfilled out there and with persistence one of them is yours. If you fail a tech interview, it's ok. It happens, and all too often it's a blessing in disguise. Well-designed tech interviews bring your strengths to the surface and you will do well. Otherwise it's just a crap shoot and sometimes you win anyway.

Chin up. You will make it.

I have found most software developers cannot write software…at all. Most interviewers seem to find people that can actually write software grossly incompatible.

Knowing this I try to cut through all the bullshit and immaturity by focusing on leadership and measures. Software is exceedingly immature and biased, but it doesn’t have to be that way.

I interviewed at a FAANG this year and it was one of the worst: leet code nonsense and false assumptions about performance that don’t survive reality. They might pay well, but the interview made it feel like a dead end hourly job flipping burgers.

He is absolutely right! I've wasted a lot of time of my live that I'll never get back. I could have spent with family, friends, which some have passed away.

It got extremely hard for me between issues with IR35, Brexit and the pandemic. 4 stage interviews in multiple places with long take home tests; some which I didn't even sleep to deliver as quickly as possible.

Some interviewers had nothing much on their public profiles, either GitHub or personal sites. An absolute lack of respect.

Https://GitHub.com/heldrida

The thing I hate the most is that 80% of the time you will be kicked out of the interview process before you even talk to the person you will be working with.

Your GitHub doesn't matter Your resume to a degree doesn't matter If you can answer the questions and solve the problems that matters

...but what matters most is if you have a good attitude and can do the job you are being hired for and it's pretty rare someone hires you based on gasp the job they expect you to do.

Show me someone who can write merge sort from scratch and I'll show you an unemployed programmer.

I really hate the discourse around tech interviews. Every blog post is exactly the same: that leetcode isn't an indicator of real skill, that the whole landscape is terrible, and everything is completely awful and no one knows how to hire anyone.

We need good data based approaches to tech interviews to move the discourse forward; I really like triplebyte's talks and blog posts on how to hire, and what they mainly point out is that a good interview process provides a decent signal on how successful an employee will be.

Ive been trying to negotiate interview processes (I have 15+ years experience, staff/principal level). Been relatively successful getting adjustments at smaller startups (approximately 10-20 engineers).

It seems anything larger I run into push back. Perhaps maybe the size of the company may be a key indicator? Maybe as a company scales you can’t be dependent on hiring managers knowing how to hire good people so you rely on filter mechanisms that are cheap and lazy.

> It seems anything larger I run into push back

Only semi related, but I built a lot of things in my life from hacking, that could be computer systems, social systems or something else.

But these day I find myself up against powerful entrenched bureaucracy. I'm convinced that some of these can't be beat (at least not by a single insignificant person).

Contrary to the OP I think Leetcode questions are useful to test the abilities of candidates, including their understanding of Big O complexity.

What I don't understand is why there isn't a standardized (proctored) test that companies could rely on, instead of re-testing each candidate themselves.

Couldn't FAANGs put resources together to establish an independent testing institute? Wouldn't that save everybody a lot of time and money?

A degree in the field from a reasonable school requires passing many proctored tests and submitting many completed projects.

Companies don't seem to find this sufficient.

Why is that? Would a board test fix this? I would back this idea if it would work, but I think it's crazy that I have a BS and PhD in CS, years and years of having my work vetted, professional experience, etc, and yet if I wanted to find a new job...time to leetcode.

Universities have mixed incentives at best in terms of certifying graduates. A degree program that routinely failed a high portion of students of the program would soon find few students entering the program. Because universities see students as a customer first, there is a strong incentive to give the customer's the product that they're paying for.

University degree program do care about rankings, which entails some concern about the quality of graduates awarded a degree. But they mainly address that by filtering students at admission time. Some program still have weed out courses to nudge students into alternative programs early on. But once the student is committed to the program, there is a strong incentive to award a degree regardless of their demonstrated capabilities.

> You won’t read my code because reading code takes 10x more time and effort than writing it.

> Particularly in DevOps, my specialism. There is no test for debugging SSL certificate chains in production at 3am.

> We can’t replicate having no answers as to why production is down at 6pm on Christmas Eve or how we will stay at our desk until it’s fixed.

So, I’m getting the sense that this person enjoys devops. I wonder if they are trapped between engineering and ops - good at both, but not great at either.

if this person wants to work at a larger tech company, maybe this person should apply to be an SRE?

They have very valuable skills and the pay for SRE often exceeds the pay for engineers. I’d not expect an SRE interview to be as focused on whiteboarding, but have a much deeper understanding of a systems toolchain, eg how to use Linux tools to diagnose a network issue.

If you are as skilled as you say you are, getting through a few challenging questions in a technical interview should be a breeze. Also, don’t discount the feedback that your interviewers don’t like your personality. If you have heard that more than once, that may be the crux of your problem.

It is what is weird to me. Those leetcode problems seems weirdly designed, some even seems counterproductive. I've juste been offered an interview about easy-medium level leetcode questions. I went to the site and ... the easy questions seems to be fundamental questions that no one deal with in real life. Medium are some common practical problems that were implemented and optimised in standard libraries a long time ago. Hard problems are actually fun to deal with and probably more revealing about myself. What am I supposed to do ? ask for difficult problems only ?

> I’m not going to use Google before your very eyes, either. Obviously.

I have the hardest time convincing interview candidates that I in fact want to watch them use Google to solve a problem. It turns out that many people are ineffective at finding and reading documentation.

As an employer, we are always trying to improve our technical interview. At this point in time we've found the best approach is to look at the ticket board and think "If I had a new developer, what could they work on?". Then come up with a single real world question and ask the candidate this during the interview. The question should allow for a junior or senior to give an answer where the depth of the answer would likely vary much like the feedback on a hypothetical peer review would. We try to avoid anything requiring too much business domain knowledge. You should be able to explain the scenario to someone off the street (non-developer). We then have a face to face (or screen share) discussion about the problem, any questions or scoping and the approach that could be taken like any real developer would if they were given this as a ticket.

As an example:

---

We have an existing job management system to track and update the progress of warranty repairs (e.g. whitegoods). Sometimes parts need to be ordered to complete a repair. If we wanted the job system to book and track parts orders into third-party warehouse management systems; how would you address the following?

- Credential management

- Data types and their life cycles

- Sources of truth e.g.

    - Customers who have purchased whitegoods are the source of truth for new jobs

    - Our staff operate the job system and our clients (manufacturers) are the source of truth for parts

    - Tradespeople operate the job system and are the source of truth for new parts orders

    - Warehouse staff operate the WMS and are the source of truth for stock levels

- Required/Optional API calls and their triggers

- Fault tolerance and monitoring

- Compensate for variations/shortfalls in existing WMS APIs (in some countries we use a 3PL)

WMS: Warehouse Management Software

3PL: An external company who operates a warehouse and dispatches items on your behalf. These companies may do so for multiple tenants and have established staff, processes and WMS.

I would outsource the development of this simplest CRUD system offshore for like $30/hr, using managed platform like Microsoft PowerApps Portal. This would be perfect and cheapest for enterprise, but answer like this wont get me software gig :)

auth via ADFS/SAML/Kerberos, everything else is managed and provided by office365 ;)

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.

Personally, I just remember getting bored talking with AWS and Google reps, then just sort of wandered back to focus on something more interesting. Understanding corporate cultures is similar to ecology: https://en.wikipedia.org/wiki/Competitive_exclusion_principl...

There should come a point in your career when you realize “Process” people have a different set of priorities, and being secure enough to not make decisions in simulated peril is wise. ;-)

This topic (whiteboarding in tech) is so common and SO boring! I work in an engineering org with ‘real’ engineers (mech eng, electrical, chemical eng etc) and I’m on a multidisciplinary team. No one tested my code on a whiteboard on the way in. They trusted the fact I have a CS degree from an elite U.K. university and numerous other software qualifications. Whiteboarding is just a bizarre fetish for people who want to felate Silicon Valley wankers. Screw this sh1t

> I’m exaggerating the amount of skill that I have ... 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. ...

> If you want better candidates filling roles, ... Check the candidate’s portfolio.

Why wouldn't a candidate's portfolio be fake too? Someone else's work, plagiarized with minor edits / refactorings to make it look unique, for example

Why would it be off limits to cheat on GitHub but ok in one's CV

hot take: OP is confusing memorizing "how to debug SSL certificates" with problem solving skills

> A company recently wanted me to choose an application, terraform an infra for it (including CI/CD pipelines) and have the whole thing launchable from zero in a single line. They estimated this piece of work at four hours. Four hours if I copied and pasted the lot from Github, perhaps.

Oh boy. Yeah, that's the issue I see with most of those "take home" exercises

(and then of course they take the candidates that spent 20h on it instead of 4h)

One important reason for coding questions I haven’t read in the comments is the need to avoid the interviewer’s personal bias. I’ve seen a lot of people say they can feel someone is a bad interviewer but how do you quantify that? Large corps need to protect themselves.

They also need to make candidates feel like they were tested using the same criteria as other candidates.

The best "coding test" I saw recently was a company that just asked "send us some technical writing (white paper, blog, whatever) you did about working a problem, if you don't have anything you can legally send us, just write a short essay about something cool."

The funny part was that they linked to it and called it a coding test.

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.

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

Nice blogpost but you're just in the wrong industry. It's really your own fault if you don't get offers thrown at you daily with the skillse you have. Stop messing around with solidity and this rotten industry and start writing real software.

Leetcode is great. If you can't solve a couple of easy LC questions, I would question your problem-solving skills.

If the difficulty of the LC questions were calibrated for the role, I'd agree. But the times I've run into LC it was rarely the "easy" questions. Instead I've seen LC questions thrown at me that would take someone already familiar with the solution a couple hours to implement, but I'm going into it cold and am given 30 minutes with someone watching me. Or worse, I've seen LC questions that were once the basis for someone's CS PHD. It might have taken Dijkstra 20 minutes to come up with the algorithm he is most famous, but you're not interviewing Edsger Dijkstra here.

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.

End of the day hiring the wrong person is worse than hiring no one. So I’m willing to forgive companies for how much scrutiny they have.

Sure some it’s kinda performative, but I’ve been on teams where HR was just letting anyone in and it screwed a lot up.

Gatekeeping ceremony is strong with the IT.

I feel like 95% of people are friends or family anyway. 5% are hired off the street.

TL;DR

> There is no test for debugging SSL certificate chains in production at 3am

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

Heh, how about debugging another company's cert chains so you can inform their technical team to connect to them successfully...

Just don't bother with amateur companies. Sometimes it means doing the FANG leetcode grind. Lesser of two evils IMO

I can't relate to these articles anymore, honestly...

I get it, interviewing sucks, Leetcode sucks and FAANG-level interviews are tailored for a very specific skillset.

And while Leetcode problems are a horrible proxy, there are a few caveats to be aware of:

- In terms of acquired skill level, I guess we all agree it's harder to gain context on a new codebase and debug production issues at 6am. However, we do this repeatedly, every time we switch jobs. Contexts are different, business, issues and tech stacks are different. Yet, we always succeed. Leetcode should be the same: just a crap you have to shove down for a few months before interviewing and then forget about. It's not pleasant, but, if you can debug prod issues with ease, a few relaxed months doing some closed-form problems that repeat themselves over and over should be _doable_.

- Not all companies require technical interviews based on Leetcode.

In the end, the weight of: effort put in vs. company reputation vs. salary will end up dictating what you will be able to (or want to) apply for and work hard for.

I personally am on your boat: hate leetcode, suck at it 100%, but, I've accepted that there are many, many great companies which have fair and representative interview processes and still allow you to do meaningful work. You know, the companies you've never heard about on the internet in your local area or city? Yep, those ones.

I believe that this kind of "self-pity" or claiming that the entire industry sucks, is broken, needs Leetcode is a bit too much. Sure, some very high stakes companies do it, but, again, those will attract the engineers who have the willingness, perseverance and skill to power through those problems (plus system design too!!) and get the job. It's a skill. The more conscious effort you put into it, the better you will become.

The real issue is then losing sight of the forest for the trees: the real work begins once you are hired. I don't know if this process truly finds _better_ candidates in average... But, imo, it doesn't need to: there will be extremely smart people who will simply stay away out of these types of processes and that's totally fine, as it keeps the talent pools balanced and creates super cool and interesting work environments and projects centered around "the other 99%" of companies.

It's not healthy when an industry makes it extremely hard (grind for months) for staff+ candidates to switch companies and expects them to prove themselves every single time. Not sure if other professions have similar strategies. Again, I've accepted it but this needs to be said. Also, you mention "a few relaxed months doing some closed-form problems". Sorry, they're not relaxed at all. You've to find time to do them after work when you're tired + need to ensure you can remember the patterns.

> You won’t read my code because reading code takes 10x more time and effort than writing it.

When I first read this I assumed sarcasm and moved on, but later it seemed odd as the tone of the article isn't very sarcastic overall.

If this wasn't sarcastic then I disagree 1000%. Code should be much easier to read than write. The only code I've come across that I'd put as harder to read than write is a few cases of just terribly written code. They were the exceptions, not the standard.

Downvotes and no comments. Lets try again.

If you are a junior developer you very well could write code that is harder to read than write. Being junior that is to be expected as you need to learn these skills. If you are past junior and your code is harder to read than write you need to rethink your profession as you are bad at what you do.

Reply on news.ycombinator.com