Agreed. The solution is to not work at a tech company, but instead work in a tech capacity at a real company.

- No silly games (before or after hiring).

- Better benefits (I'd rather have proper health coverage and a pension than a room full of toys and vaporware stock options).

- Immensely more job security (Henry Ford didn't have an "exit strategy").

- People respect you more as a professional with a needed skillset, and not a throwaway cog in a machine who can be replaced or offshored on a whim.

- And in many real companies, proper internal HR groups focused on making you a better person and a better employee, and not some farmed-out commission-based headhunter group that makes money on employee churn.

> In an ideal world, you could trust someone's resume.

That's not an ideal world. That's the real world. Meaning not SV, and its wannabes.

Some of the best career advice I've ever gleaned is to work on something that visibly makes money for the company. I get to do that every day at my tech company. I don't know that I could say that if I worked in a technical capacity in another industry.

9:00 - 4:30 daily hours, no nights, no weekends. Full benefits, good salary, good yearly bonus, quiet office, great people who were there to get a job done and then go home.

Had to wear a shirt and tie but that's not the worst thing in the world.

I left because it was my first job out of college and I wanted to see what else was out in the world. But it stays a fond memory of a solid job.

Yes, a lot of adults wear sweatshirts and hoodies now. However, if you wore a shirt and tie to a high school, they would make fun of you for dressing up like your dad. We have collectively agreed on a "grown-up" attire.

Yes.

Dressing for comfort, or to suit the physical demands of your job are valid motivations. I wore a shirt and tie at my first job (back in 1987), but within a few years, I didn't bother any more because no one else did. Nowadays, "business casual" is fine by me.

My initial reaction was to guffaw at the ridiculousness of such a statement. Expression through fashion and attire is pretty much the entire reason we dont all wear the same thing as each other every day. I feel the exact opposite as you: people who dont dress with the awareness that their appearance is a statement to the world they walk into are missing a massive opportunity to affect their day. How people treat you. How people respond to you. Etc.

But since I'm growing less cynical in my old age, I would care to learn more about your perspective if you care to share.

Which, of course, tech companies don't value at all. From what I've seen, they much prefer to hire a fresh grad over somebody with a long record of proven performance.

So, I agree that one should seek work in tech at a non-tech company.

The skill I look for over all others is an understanding of the standard principles of software design, and principles of testing is a bonus. I want to see that the candidate is honestly interested in our language to the extent that they are familiar with the obvious pitfalls of the standard language features. Candidates who prepared by writing option pricers and passing leetcode challenges won't necessarily understand any of these, because they are simply writing functions.

I assume that anyone who got through a rigorous engineering undergrad has the mathematical preparation to perform as a quantitative developer. This won't be true for all roles, but it's true for all of the QD roles that I have contact with at BB.

If you are interested in a dev role in finance, and see requirements for basic financial knowledge, risk, etc. -- as long as the requirement isn't quite specific, such as experience pricing specific option types, pricing complex products, or with a specific product, I would just ignore it and apply. Many of these concepts are quite simple compared to what SEs are trained to model and implement, and the people on the team who need help know that.

I've seen GPU and C++ skills requested for a Pandas shop. Just apply.

I think hiring managers and HR think they will attract better candidates by adding these things, but it is counterproductive.

From what I can tell from salary surveys, we pay an entry-level dev better than many others. >150 guaranteed all-in first year, and better than that afterwards if you just do your job. Promotion path is good because modern skills are in dire need.

The only trouble is that finance is only in the NYC area. You can't be there if you are in the valley.

There used to be some in Chicago. Bank of America, Swiss Bank, First Chicago. Swiss Bank is now UBS and I don't know where they do their trading system development. First Chicago got absorbed by JP Morgan Chase. B of A might still do some trading development there, but I have no idea.

Back in the 90s Swiss Bank and First Chicago used NeXT for trading apps, and Swiss Bank had Symbolics machines here and there.

In any case the same bank with Blockchain and big data lakes will also be working with mainframes and COBOL, so generalisations about technology aren't particularly useful when it comes to organisations that are so large.

You're a carpenter. You nail boards together to serve the business interests of the company. Even if the boards are SQL queries or ReactJS or whatever.

Companies need tech. You can bring value by making everyone's jobs better with your technology - sand off those rough edges on everyone's workflows. Demonstrate your value.

Carpenters build houses, woodworkers build furniture. IT people reinstall operating systems, fix printers and networking issues and software engineers write software. They have a different education, different job description and different pay scales. A woodworker wouldn't make a good carpenter nor a software engineer a good IT person or vice versa.

There is absolutely nothing wrong in being an IT person or a carpenter, they're reputable jobs that put food on the table. But if your trade is being a woodworker or a software engineer you should be slightly worried if you end up being put in a carpentry or IT. Or vice versa.

Disclaimer: I'm biased because I'm a software engineer and a woodworker. I'm good at my job but I can't fix networking issues or build houses.

It's actually at the smaller companies (like startups) where you'll be expected to do that. I worked at a company with <20 people total in the entire "IT department" (encompassing all computer-related things). Even though my job title was security analyst, I was in Active Directory, I was configuring Cisco gear, I had the on-call phone for the entire department, my phone was in the helpdesk rotation, I'd be dispatched to satellite locations to troubleshoot their wireless.

In my current job as a consultant, I've worked with startups where their engineers are answering support emails and replacing their own hard drives because they don't have a helpdesk or a desktop support team.

'exDM69, I'm not arguing with/against you, just piggybacking off your distinctions to help the conversation. If you're afraid that moving from a tech company to any other enterprise will have you putting on many different hats, it's probably not true. Unless you move to a tiny company, which is true for tech companies as well. Any real enterprise company will have dedicated IT support teams and you will be reprimanded for trying to perform your own IT maintenance since that's not your job.

Today? At 20... "what will I be doing for a living? Hm, I did some html and copy pasted js, I WILL BE A DEVELOPER and be RICH". Went to college, learned to develop. But I don't have any foundation, web and sql is all I know, and I am sleeping with Programming patterns book under my pillow and looking at latest programming hype (silently laughing at year of nosql databases and year of blockchain, now AI, and eagerly waiting for the next silver bullet that will solve ALL our problems :D)

IT is not a different field, but the level of today knowledge IS, also the attitude.

A friend of mine is having a successful software company and he said to me once: "If I get a guy with the attitude and background we had, I will hire him even if I wont be hiring at that moment. They became so rare, that it is worth having him on a bench, just to be there when you need him".

Honestly, people who actually know sql enough to build a decent table design are super rare these days.

As far as everything else, you're pretty spot on.

But joke aside, what is the issue, do you disagree?

The scales I work at are more about Big O than anything. If I make a mistake that is N^2 vs Log N then I wait a week for a job to finish verses 1 hour. That is an issue. If I add on 10 min because I inefficiently use swap space it doesn't matter. I need to pay attention to the higher abstraction rather than the minute details. Sure I can fix a computer but if I do that rather than stopping a job from doing puts across regions it will cost the company 12000 dollars for each hour I am removing malware.

And, like, literally everyone since Adam Smith and his pins.

Assessing how good people are at skill A by trying to determine how good they are at ever-so-slightly-related skill B is what led google and the rest of the valley down the ridiculous problem solving interview quest of the aughts. Take your manhole covers and suck on them!

Abstraction is a skill, one that’s difficult to assess in an hour-long interview, but one which allows me to say “I’m great at C# but I’ll call someone when the printer is broken” - because there are only so many hours in the day.

Rather, we manage peoples computers, and the environment that allows them to function. The misconception that IT is only there to fix, is because we're invisible to you when everything works as expected.

I worked in a tech startup, where everyone did everything, and where doing everything was considered high-status: it meant you were competent at everything. Or perhaps the other way round: trying to avoid any computer-related task, for whatever reason, was perceived as an admission of incompetence, therefore low-status.

(I didn't agree with that philosophy. I am humble enough to admit that I am not an expert at something, e.g. setting up printers; and lazy enough that I want to avoid such work if I can.)

I also worked in a non-tech company with sufficiently large internal software development department, where as a programmer I focused on developing software; and if any part of the technical infrastructure stopped working, I just called the internal tech support.

In my current (non-IT/software dev) workplace, the CEO and the manager pride themselves on how all our staff can do everything. We're all sold on it with the line that "..all your future employers will be amazed at how much you can do!" Unfortunately, everything we produce is second rate junk as a result of this, as we are "all responsible for quality control," and the customers pay appropriately.

It's not that it doesn't work, clearly it does for some businesses, it's just that someone has to be responsible for making sure that the product is fit to be presented to the customer, and if everyone's running around doing everything, nobody's really doing anything.

There is always something you don't know, no matter how "senior full-stack" whatever you are. And when that happens, and the company culture does not allow you to admit it, the only solution is to use google, stack exchange, download a book or two, and perhaps ask a friend -- but neither of that makes you an expert overnight (and sometimes "overnight" is literally as much time as the agile process used in your company will give you; just because someone else, who actually is an expert in that stuff, could do that in a day).

The more I know about the things I specialize at, the more I am aware that you can't reach that depth of knowledge and experience by giving three smart questions to the search engine, and reading the three resulting articles. And by analogy, I assume the same is true about some of the things I don't specialize at.

But I have kids to feed, so sometimes I just bite my tongue and produce whatever is possible within given constraints.

This company culture also leads to playing games where everyone claims to believe that of course anyone can easily do anything -- but there are tasks that everyone is trying very hard to avoid: "It's not that I couldn't do that, I am just very busy now working on some other high-priority stuff that only I can do. Perhaps John would like to take this nice and simple task?" "Uhm, I am also in the middle of, uhm, something. Perhaps Joe could do this?" Joe doesn't have a plausible excuse ready (or is not present at the moment), so he is assigned the task. The meeting ends. If anything goes wrong, it's all Joe's fault.

In long term this reinforces the status ladder within the company, because the high-status guys are in the best position to refuse the tasks outside of their field of competence (by claiming they have more important stuff to do); the low-status guys get stuck with the tasks, produce mediocre results, and that is taken as a proof that they really deserved the low status. (If they are inexperienced 20-somethings, they will quite often buy it, and feel guilty about their incompetence. Then some moment later they change job, and realize it was all actually about the company culture.)

Laptops, printers, email, document storage and so on is part of the software development team's responsibility -- so we outsource all of it, and spend a little time on it roughly every 6 months for a new system or similar.

"Hey, I can't print". "Here's the helpdesk number for the people we pay for printers". (Some people were annoyed at first, but understood when they saw the developers' salaries compared to what we paid for the "boring" services.)

0. https://www.forbes.com/sites/jwebb/2017/05/29/british-airway...

IT is by far more lucrative in the long run. It's just the structure of RSUs and stock options that gives start-ups the illusion of relatively larger comp gains.

We all know they are following business procedure, but there will always be some unconcious tension with departments that hinder a solution (I see marketing and legal butt heads all day).

In an ideal world, IT and Devs would be on the same page - after all who will be first contact when an end user encounters an issue?

The separation of development and support makes sense from a budgeting point of view, but operationally should be intertwined (IMO).

It's entirely reasonable for a carpenter not to want a job where they just nail pieces of wood together. Not really building anything, not really using skill. Just nailing a few boards together all day.

IT runs the network, phones, issues and fixes laptops, maybe provides servers, often is in charge of information security. May own the financial and business intelligence technologies. Unless it's a very enlightened org, this is often the "cost center" team.

Digital talks to the world in a modern way--runs the websites, blogs, social media channels, paid digital ads, etc. Often housed within a larger communications and/or marketing division. Technically a cost center but the visibility makes up for it in the eyes of executives.

Product builds the technology that makes money. This would be like the e-commerce platform, ad network, mobile apps, etc. Executives value things that make money.

Often, all three groups need developers. The tools and roles may differ, but you can be a developer in a major company without feeling "stuck in IT."

The second (making a bottom-line impact) is probably a non-issue. If it's not a tech company, that means they are likely failing to use tech fully, in places that really could benefit from it. Automate stuff that needs it, and quantify the time saved as:

(time it took before - time it takes now) * number of times each person has to do it per week * number of people * what those people get paid / what you get paid = time T you saved in a week, in terms of your own hours.

Each time you do something, add its T value to a running total. Likely an hour here, an hour there. Eventually it hits 40 and you and the managers can clearly see that your employment is paying for itself. Keep going and you're making them money.

Only by beancounters, and if you take it away and go back to paper, they'll quickly change their mind.

Good developers cost a lot no matter where they hang their hat.

Depends on the company. Where I am, IT is in charge of maintaining the computers and networks so that the software developers can develop software in and for other departments.

When you compare a non-tech company to a big tech company like Google, the benefits and comp arguments switch to the favor of the big tech company along with the respect and job security.

The only advantage to non-tech companies when comparing across big ones is the simpler interview.

Ford is a public company. That's an exit. An exit is whatever makes your stock liquid, not the end of the company.

The several hundred other auto makers in Detroit did, they went bankrupt or sold out for peanuts right before going bankrupt.

Google, Microsoft, Amazon, Netflix, Apple, Facebook, Cisco, Oracle, Intuit, Adobe, PayPal, nVidia, Intel, etc. don't have exit strategies either.

For the vast majority of businesses, you're either going bankrupt, or you're going to eventually sell as an exit. One in a million businesses turn into the next Ford scenario.

It depends on the company. MOST non tech companies imho treat all tech workers like IT, with the exception of embedded data/analytics people IF the company is even forward thinking enough to have that.

You compared the best examples of corporate with the worst examples of tech.

Yes, bad english can be detrimental: starts wars, malpractice, etc... We just take it for granted.

If code is treated like math, then we can talk about absolutes and good code.

But 90% of us talk about it in the language context, hence why we call it a programming language....

OP seems to be referring specifically to tech startups with dubious financial situations but then goes on to say that all tech companies are bad to work for

I very heavily disagree.

I've literally seen someone who did firmware for the space shuttle grind for 45 minutes on fizz buzz without making progress. Like, I'd they struggle for ten minutes or so, I take a step back and say "Ok, screw syntax, let's just vaguely talk about what needs to happen and mock up some pseudo code.". Even then, grinding for another half hour with no progress.

But I totally failed a technical screen.

It’s been a week of reflection as a result. I nearly canceled the interview to begin with because the entire process felt like a cattle call - totally cold, the company had shared no information about themselves or the role. There were ten minutes of rapid fire (“you have one minute to answer this question.”) followed by the proclamation that the next 45 minutes would be spent on “as many coding problems as we can get through.”

Within the first few minutes I was able to describe a general solution to the problem, but over the next 40 I totally struggled to produce a working solution. Now, sitting here I could likely write it in 5 minutes. The problem was:

--I was completely frustrated by the experience from the beginning

--I was in a code editor that I wasn’t familiar with

--I had limited access to documentation

--An interviewer looking over my shoulder harassing me

--I realized that while the problem was simple, there were things I’d just never needed in that particular language before, so didn’t have a complete understanding of what was available to me.

--I focus on design before implementation, where the interviewer just wanted me to jump in and bang out code.

--I realized that the last time I wrote this particular bit of code was 20+ years ago, as a college freshman, and certainly not in the language I was using today.

So I agree with the other commenters: we should all check our premises before we disregard another experienced programmer as as hopeless hack.

I wrote a long blog article this week about what I think the interview process should be, will be posting it soon. There are ways to fix this process.

Depends on the job.

I'm currently hiring and the live coding exercise is a must for the position because I want to see how the person problem solves while under stress.

Because stuff happens. My team works on mission critical systems that can have issues that we sometimes must resolve quickly which is very stressful.

If you can't handle the stress of me watching over your shoulder while you code then you can't handle the stress of getting a critical bug fixed immediately. Maybe that's not true for everyone but I haven't heard of a better filter.

Not every position is like this. But that's the big thing I think people miss. Different software positions require different skillets beyond just tech stacks. And the interview process should measure for the particular software engineer skills needed for that position.

I've also hired people who if you just reviewed their code after the exercise you'd think they were terrible. But I'm not testing whether they are good at coding exercises, the test is a tool to see their ability to problem solve under pressure and to see their level of experience with the particularly tech stack.

Those are two very different kinds of stress.

In one situation you're stressed because you feel like your every action and step is being judged. Every moment you spend floundering you feel is being docked against you, you can't help but worry about how the person breathing down your neck is expecting you to approach the problem.

In the other situation you are a part of a team, you have each others backs and trust each other to make sound judgement calls. You're working together for a common goal rather than judging each others every movement.

Your hiring method sounds like hazing, you're putting interviewees though unnecessary stress to see if they crack. Stress that isn't the same as they would feel on the job, at least I hope you don't also treat your employees the same way.

To echo your point, fixing a bug with someone you just met standing over your shoulder clock ticking, is nothing like fixing a bug at your regular place of work.

In an interview, if you don't perform the task well, you can fuck off back to the street where you came from. In your job, you get to ask colleagues, consult previous project code, refer to in-house or external documentation, and calmly analyse to figure it out under your own "in the zone" steam.

Sounds like a great place to work...

This doesn't sound like something a new hire should be responsible for and more someone who would eventually, after proven themselves able to, participate in.

Interviews are already stressful; you don't need to add to that by putting candidates into even more stressful situations just for kicks.

To flip it around, would you be willing to let the candidate review the details on all technical employees exit interviews and then ask you about them? Maybe review some completed financial audits from previous years? so they can see how the company reacts under pressure?

It doesn't.

> I'm currently hiring and the live coding exercise is a must for the position

It's not.

> because I want to see how the person problem solves while under stress

Why, it's a totally bullshit proposition. The stress of not having memorized some algorithm is not the same kind of stress as a live system going down.

You do it this way because you aren't able to come up with anything better.

Remember, interviews go both ways.

Otherwuse these exercises would just paint a broad stroke that handling stress is common & generalized, when in fact it's unique and case by case in most situations.

tl;dr: If you're a stress factory there's no way on earth I'd be willing to work for you in the first place.

This is why advice for passing the Google/etc. interview usually boils down to: Quit your job for a month and do competitive coding, and you will pass with ease.

In the end, I scored a job with a FAANG company literally because I didn't want to work there. A friend warned me away before the interview for work-life reasons, but I decided to go ahead with the interview anyway as practice and I nailed it. There's no reason to stress if you don't want the job. Another friend who worked there later convinced me to take the offer.

What bothers me is: you're basically the same coder both before and after competitive coding practice. You're only more marketable with the same skills.

Yup. You keep keep measuring that thing..I don't think you're measuring what you think you're measuring.

I don't care if they can write the code but I want to see some level of engagement with the problem and some understanding.

Given the negative response we've had in the past about take home assignments for senior devs (their time is pretty valuable, so I try spend the same time they do), I'm not sure what else to do to accommodate.

(Being forced to use someone else's machine is a developer hell with so many dimensions.)

For instance, I nearly avoided very early carpal tunnel issues in graduate school by entirely relearning to touch-type on the Colemak keyboard layout. Sure it only takes a few minutes to switch to the layout on Linux and macOS these days, when I remember where the keyboard preferences are, but it still takes Administrator access and a software install in Windows.

Even "easy", that's still a cognitive load distracting from whatever the actual question was and starting into the actual problem. More importantly, at this point in my career, it's something that I'm going to see this as an immediate sign that employee ergonomics may not be a concern for the person giving such a test, which may speak to other aspects of the work environment.

It sounds to me like you’ve done some careful thinking about this, and it doesn’t sound unreasonable. One of my beefs really gets down to the interview process turning into a one-way grilling, dehumanizing the candidate into a “code monkey.” It sounds to me like you are trying really hard to evaluate their technical skills, but in a way that is collaborative.

Bingo.

A hiring process that attempts to convert the multidimensionality of humans to a handful of numeric variables is essentially trying to hire the best drone out there, not the best human fit for the job.

I learn more about candidates from the types of questions they ask me, and their reply to open-ended questions I ask them, than from any technical grilling test.

So I would take writing software for fun as a plus, but would not take not writing software for fun as a minus.

This gives me a pretty deep insight into how they approach a problem, but also how they interact with others. There's no adversarial element, and it gives them the chance to see me screw up to give them the mental space not to sorry about stupid errors.

The one worry I have about this is that it's more vulnerable to my own biases than a more disinterested process would be, but if I'm consciously aware of how that can play out, I'm in a better place to counter them.

Count me in that group. I have no desire to go through that BS. Seems like the bozos have taken over and ruined development work.

I really hope that's true. Every solution I've heard so far is unrealistic at best, like using take home assignments, as if no one would cheat or complain about those.

Not sure what happened inside my brain, but I simply froze and couldn't solve a fairly trivial coding problem.

That only thing that makes me feel better is that it was a one-time problem.

Turned out good enough, went onsite. Failed. Oh well.

Tried again a while later. Failed FB phone screen, got told Google wanted a second. That was the point I said fuck it and cancelled.

shrug

I have 20 years of industry experience. Everything on my resume is the truth. I've worked on serious code, for serious projects, at serious companies. At work, my performance reviews have been stellar.

When I do live coding interviews, I'm being tested with tasks that are utterly remedial relative to what I've done professionally over long periods of time. Yet I flub these remedial tasks. It could be because I'm nervous. Could be because the interviewer keeps interrupting me mid-line, so I can't think. Could be they are too terse, and I can't drag enough information out of them. Could be the problem is slightly more complex than I can accomplish under any circumstances in a live performance, but that I could complete correctly in a closed room.

These interviews are degrading, disrespectful, and they tell lies to the misguided interviewer. What do they think they're testing the candidate for? Why does it matter whether you can code something remedial, live? Is live performance part of the job function? Do other professions do this? We should end this practice.

Or... large companies, particularly defense, excel at hiding mediocrity in their ranks, and it's easy for someone who produces no or negative work to be handed around rather than fired.

What's the success rate for startups?

The reality here is that everyone is supposing their particular bias explains what happened.

No one seems to have asked what actually went wrong in the interview. Was the interviewee truly incompetent? Were they nervous? Were they fine at code but terrible at interviews? Was the language or environment unfamiliar? Had they just got off a plane after zero hours of sleep?

Without data, opinions are worthless. And generally, there's too little data about the relationship between interview performance and job performance, and too much unthinking mimicry: "We do this because everyone else does."

> What's the success rate for startups?

While there are certainly mediocre coders in many many startups, let's put the blame for most startup failures firmly where it lies:

"It was a turd of an idea and no-one told the founder/the founder didn't believe it."

not

"It was an amazing revolutionary concept that was only sabotaged by dimwits who couldn't fizzbuzz."

Going through a series of technical filters is not a problem in and of itself. The problem is that each company has its own set of filters, many times with skills that don't necessarily transfer to other interviews.

With the "bar exam" approach, you only need to pass 1 exam for N number of companies, leverage that to fast-track through a company interview. With the current approach, you need to take N exams for N companies, and return to square one if you fail. There is no extra layer of validation that lets you keep a "ahead" placement in these interviews. Company specific interviews should focus on basic soft skills, and if they mesh well with the team.

I'm an experienced programmer- not yet considered senior level, but have worked at several companies -and having a hell of a time going through my latest job hunt.

I have been applying for jobs for 3 years straight now, and it's telling that the only offers I've gotten were three short term contract gigs- one from a past employer who's already familiar with my work, and two from small studios with a very informal process where they just looked at my resume and Github projects and with that, they were very convinced that I'm the man for their job. I took these jobs mainly to add more skills and to fill up the gaping time hole in my resume.

But for the "regular" full-time jobs at businesses, big or small, local or on the west coast (I'm a midwesterner), I have not gotten an offer. I've been through many tests and live coding going through a lot of things. Triplebyte expects you to be a speed demon, but at least they give detailed feedback on what you did wrong.

So what is with the saturation of applicants and tendency to make the hiring process slower and slower? That's what these coding tests and interviews do, they make the process slower.

It's not 2009 anymore- unemployment is reasonably low, so this current phenomena of rigorous testing shouldn't happen. More programmers need to discover and embrace the power of collective bargaining.

Literally every other profession has this challenge! Programmers are unique only in their seeming inability to realize that they are not unique.

Accountants are not asked to solve double-entry accounting whiteboard problems. Finance professionals are not given take-home banking projects. Only programmers seem to be unable to be reasonable interviewers.

One major proctored exam scales a lot better than every company for themselves reinventing an almost proctored exam.

https://engineers.texas.gov/downloads/ncees_PESoftware_2013....

Certainly what I see in the PE today seems like a good starting base. Having some idea of Big O complexity can be a great place to start when working with algorithms, and certainly from my perspective I'd rather have an engineer with a solid idea of Big O complexity trade-off issues than a bunch of rote memorized implementations of classic algorithms.

Also, don't forget that a lot of discrete math and algorithms bubbled up into the Fundamentals of Engineering test that is the prerequisite of the PE test:

https://ncees.org/wp-content/uploads/FE-Ele-CBT-specs.pdf

Which isn't to say that the PE can't be improved for Software Engineering to better meet industry needs, but certainly the current PE still stands as a good starting point that the industry could try to hone to a better tool if they wanted.

No, this is a made-up difficulty, caused by the fact that programmers think there’s a silver bullet solution to evaluating competency in an “objective” manner.

My girlfriend has just graduated college with an Accounting degree.

> There's nothing like it for programmers.

What exactly is the difference between a BA (Accounting), and a BSc (Computing) in terms of validation?

Now if you want to talk CPA? Sure, but the equivalent of that would be a Software Engineering (similar to PE/CE/ME).

Apples and oranges.

Getting the right team is one of, if not THE key to startup success.

Yet you consider it not worth a senior engineer's time to evaluate the candidates for the next hire, and the presumably with whom they will need to work - productively?

Check your org's runway and be sure to have your resume ready when it gets close to the end. I wouldn't expect take-off.

I wish you luck

These folks have real data on lots of interviews, and have done some analysis on them:

http://blog.interviewing.io/you-cant-fix-diversity-in-tech-w...

The takeaway that's relevant to you is the section titled "Interview outcomes are kind of arbitrary". Specifically, things like:

As you can see, roughly 25% of interviewees are consistent in their performance, but the rest are all over the place. And over a third of people with a high mean (>=3) technical performance bombed at least one interview.

If you set up a typical tech-company interview process, and if you equate "didn't pass this" with "complete impostor and utterly incapable of coding in any capacity" (as most people with your approach do), well, congratulations. You're almost certainly rejecting a bunch of qualified people, simply because you're terrible at interviewing them and can't actually tell from your process whether or not they're qualified.

The most generous thing I can say is that it's not entirely your fault. You adopted ideas and approaches from people who seemed authoritative but turned out to be the actual impostors in this situation. But now you have a choice: you can reject that, now you know the problems, or you can double down. I suggest not doubling down.

The question is how can you test for experience in writing code that is maintainable, readable, 'instrumentable' and contributes to a better system. How often does a candidate refer and defer to a decent third party library instead of feeling they need to (re)implement a well known data structure or algorithm? What have they done to help automate things so they can free themselves and their peers from minutae (aka how willing are they to put more work on machines?). What more do they think they can do. How well do they mentor or are ready to be mentored? Given a sample project, how would they go about running the technical side of things. If they focus on code, you should try to motivate them to expand to other areas (without telling them what they are). How cognizant are they of the ecosystem; or does their vision end at coding + unit test.

Lots of intangibles that cannot be measured with a github profile or a white board interview but probably contribute more to picking out better candidates.

Like literally can't do a basic loop. I'm not looking for 'my solution', I'm looking for any solution.

> I think it's fair to say that if you get a senior Dev in that can't even write out an if-else statement checking for 3 and 5 you have a problem.

And yet, I can tell you from experience that there's someone out there who (at least was on the team that) wrote firmware for the space shuttle that literally can't if-else with modulus despite having a great looking resume. And they are far from alone.

You need to ask for those, not just prior companies. My resume has a "References available upon request" at the bottom and I'd happily give them. Is that no longer practiced? It used to be a requirement.

Yeah, right. Personal references aren't worth squat because nobody gives references that are going to badmouth them.

The worst hire I've ever seen had a highly positive reference from a previous job.

Here's my FizzBuzz:

https://github.com/ubernostrum/interviewer-hell/blob/master/...

My code for "detect if a number is a perfect square", though, is O(sqrt(n)) time and O(1) space and uses no floating point operations. Which isn't quite Newton's method, but also saves me having to memorize an implementation of Newton's method and appropriately causes confusion. Here it is in Python, with obfuscation help from itertools:

https://github.com/ubernostrum/interviewer-hell/blob/master/...

And slightly less obfuscated C:

https://github.com/ubernostrum/interviewer-hell/blob/master/...

I dont need to hit the book to write fizzbuzz, and i could probably code up dfs and bfs without prep but i dont walk around ready to retake my undergrad algoriths midterm. Especially when i really dont even know what the topic will be.

Im aware that the question i posed isnt terribly difficult and perhaps it does say somethingabout me that i need a bit more time to refresh my data structure to do this at a whiteboard.

But i do want to be clear that fizzbuzz is not representative of the 5+ hour whiteboard grilling ive gone through at nany of these interviews.

Who cares if this person can't solve fizz-buzz on the whiteboard? That's probably not even a relevant skill to the job opening you're filling, or a skill they have ever needed to hone or practice. It's like determining a marathon runner's worth by timing their 100 yard dash.

If I ever need to do another coding interview again, I'm gonna troll the person asking the question by pulling out my phone, googling their question, and consulting the stack overflow post in the search results to solve the problem. And why not, this is how I (and the vast majority of people) will actually get the job done in a real situation.

A marathon runner doesn't need a stellar 100 yard dash time, but they should at least be able to jog 100 yards.

If you're working on the shuttle, those small tasks generally won't be surprises. They will have been planned out well in advance.

> Who cares if this person can't solve fizz-buzz on the whiteboard? That's probably not even a relevant skill to the job opening you're filling, or a skill they have ever needed to hone or practice.

Thing is, shuttle-style development is also probably not even a relevant skill to the job opening he's filling. Odds are, that job requires something more akin to FizzBuzz ('I want to do something. How do I do it?') than to shuttle-firmware.

Also, another thing to consider is how this kind of interview encounter negatively affects diversity and the experience of candidates from different cultural backgrounds. If we treat this form of interview a sort of hazing experience that doesn't really inform on their aptitude on the job, what kind of traits does this process _actually_ select for? Would be an interesting study.

And even if it's paid, it's still a not-insignificant time investment for the applicant. They're probably applying for several gigs and take home assignments would quickly turn into a full time job, and filing the tax paperwork could take more time than the coding.

And finally, assigning a job that would actually get used at a company pushes up the complexity level, the need to understand the context. This would also make me very suspicious about the motives of the company.

In my company, we give a "fizzbuzz" level assignment on the whiteboard (or their own laptop if they prefer). The purpose is to weed out the applicants who can't code at all (makes a surprisingly large portion of applicants). Additionally, we've noticed that the ones who are good programmers will ace these tests.

I don't think that whiteboard assignments or takehome work is a good way to assess how good a programmer is. A 15-30 minute smoke test with a binary result (the applicant can or can not code at all) is good to filter out bad applicants but not to distinguish good from excellent.

It also shows the company is semi interested and not just meeting the consideration requirements before selecting an already chosen candidate.

I'd prefer to do a lot of that at home personally.

What happens instead is that you just don't ever hear back from candidate.

There are plenty of people telling you the same thing, you just don't want to hear it. Here's a data point. I would never do it unless I was absolutely desperate. I mean about to lose the house desperate. There are just too many other companies around.

I mean if you are trying to pay junior rates and maybe pull a decent mid-level guy, it may be a good tactic. If you are at all interested in top talent, you'll turn many if not most of them away. Unless your company offers something no other company in the area offers, tops generally have no time or patience for that, especially if they just handed you a loaded resume with tons of references.

If you're just a boring ole company like all the other companies, believe me, you're turning top people away.

I've never applied to Google and I never will, because it would be nearly impossible for me to perform in one of their interviews.

But I did get the job.

No expectations? No stress!

It sounds to me that an assumption is being made because they didnt meet the expectations within a fixed time period. The danger with this is that this is not a real world scenerio of how two people would approach a task or problem. It’s also important to recognize that everyone is different with regards to how they process information. Stress has a real biological effect on how the brain processes information, and who doesnt feel stressed during an interview.

I’m somewhat autistic and struggle to process verbal information. But I try not to share that with people because I choose not to be labeled by it. It’s unfortunate that in our society that we have to conceal things like that.

All of us could be better at trying to understand people around us and accepting them for who they are instead of scrutinizing them for what they are not.

The funny thing is an artificial examination style setup totally freezes me up. I'm a valued contributor and write original technically non-trivial code day in and day out.

The last time I did an interview a few years ago my brain completely locked up. The interviewer was very polite, and it could have not have been any less stressful situation. Yet, somehow my brain knew I was in an interview, and it was time to lock up all that valuable technical information ... somewhere where my conscious mind could not access it.

Which is really weird. Usually at work the occasional unexpected stress put's my brain on turbo-charge, and ... it's so beautiful to experience it, everything has perfect clarity, I know what needs to be done and I just do it so much faster than regularly.

My "on-interview" brain is complete opposite of my "million-euros-are-at-a-risk" brain at work. I have no idea why.

Not if the fixed time period is 45 minutes with an interviewer looking over your shoulder.

Yes, and they're troubleshooted by people who are already intimately familiar with the systems they're troubleshooting. Nobody in the real world writes an app for a requirement they've never seen before from scratch in 45 minutes.

So you're asserting interviewees shouldn't already be familiar with simple problems like reversing a list? Come on, give me a break.

> Nobody in the real world writes an app for a requirement they've never seen before from scratch in 45 minutes.

Being asked to reverse a list in 15 minutes isn't even close to "writing an app from scratch". It's not even theoretical - just look at all the people who make it past these interviews. I doubt they would call it "writing an app from scratch". Could you try any harder to misrepresent things here?

Though it is clearly a simple problem, I've not had to reverse a list in any of the code I've written in the past 20 years. So I am not 'familiar' with the problem. I think I'd be able to solve it pretty quickly under normal work circumstances (even crises), but as many have said here already, working on something you've never done before with three strangers looking over your shoulder is a whole other dimension.

Many here and elsewhere have related the 'brain lockup' effect. Take me as another data point. It's real and it totally wrecks the interview for the interviewee and the interviewers, who lose out on a potentially good employee.

What's your point? You just want to repeat what everyone else has already said? And how low do you think the bar should be? What would be reasonable questions that actually still separate people who can code from people who can't, since reversing a list is too hard according to you?

> It's real and it totally wrecks the interview for the interviewee and the interviewers, who lose out on a potentially good employee.

Or they hire someone else who might actually be just as good or better. It's not like companies have an unlimited number of open positions.

I'm not saying anybody should lower any bars. Just don't immediately fail somebody who struggles with a simple problem. Don't just automatically declare them incompetent. Help the candidate be the best version of themselves. It's in your best interest as an employer. Try to figure out ways to make your interview atmosphere as realistic as possible. Some of these people who choke on trivial problems may have aced the same test on a better day.

It also isn't even close to "solving a real-world problem". Wow, look, I reversed this list and the conversion rate on our sign-up page went up 200%!

> Could you try any harder to misrepresent things here?

It looks to me like you are the one misrepresenting things.

It's not supposed to be the same thing. It's supposed to test your coding and problem solving abilities, in the limited time you have. What better alternative can you come up with? It's easy to just complain...

> It looks to me like you are the one misrepresenting things.

Hah, yeah right. If it makes you feel better, sure.

The second group universally cannot perform under production pressure.

Of course, you have a limited amount of time to interview people. Please let me know when you figure out how to give someone an infinite amount of time to answer questions during a 1 hour interview.

> The danger with this is that this is not a real world scenerio of how two people would approach a task or problem.

That doesn't mean it's not a reasonable way to test basic skills. It's even too easy to test that by itself. What good alternative do you have?

> All of us could be better at trying to understand people around us and accepting them for who they are instead of scrutinizing them for what they are not.

How exactly would you structure a 1 hour interview so that it's not, "scrutinizing them for what they are not"? Or are you just having fun being preachy here?

Here’s the thing though, you are “leaving money on the table” when your interview process deselects great programmers because of a mistaken belief that Test A is a good proxy for developer talent. When HN developers are telling that Test A is a bad proxy for developer competence, perhaps, just perhaps, you might consider trying to improve it with the advice given.

The upside of being able to accomodate developers who “lock up” in stressful interviews, is that you now have access to great developer that are (according to your competitors) “impossible to find”.

> you are “leaving money on the table” when your interview process deselects great programmers because of a mistaken belief that Test A is a good proxy for developer talent.

That's true for any non-perfect interview process at any job. The problem isn't that people don't know this, it's that it's hard to accurately measure who's good.

> you might consider trying to improve it with the advice given

Hah, as if the advice is something amazing! Which of these pieces of advice could we use that wouldn't make things worse in some way and also have a chance of being accepted by existing coworkers and managers? There's some great pie in the sky ideas, but nothing without serious issues.

> Pete Holiday, an Engineering Manager at CallRail in Atlanta, used to use homework as part of job interviews before realizing that he was ruling out good candidates. Some told him they didn’t have time for homework. Others may have never gotten to that point. “It’s way more inclusive to just have someone come to the office and talk to them,” Holiday said. “You’re not counting on them having time, or a computer at home. We have candidates with sick family member, single parents. Without the homework we can cast a wider net.”

So is homework worse than whiteboarding onsite? Who do we believe, some article or the crackpots here?

Think of ways you can de-stress the candidate while extracting useful information. Ideas:

1. Have them bring something they wrote with them and describe it in the interview. A lot of developers will “come out of their shell” when they start explaining something that they worked on.

2. Show them some code and have them explain it to you. I had a manager open a C book once and had me explain some code.

3. Pair program on a problem that the interviewer doesn’t know the answer to. This situation is a lot more like a true work situation.

That's what people do, or should be doing, along with the whiteboarding. I don't think anyone just has them do fizzbuzz and that's it, like you seem to be implying. That won't even fill an entire interview slot.

> it seems like it is much more enlightening to hear about how they organize a schedule...

Sure, and that's also something you ask about, but that doesn't weed out the people who can talk the talk but can't really program, who do exist.

> But even as I type this, I'm wondering if the ability to read people is why this so hard for software interviewers...or maybe it's for lack of that simple skill that our industry has resorted to silly proxies like fizz buzz, etc.

I think it's because people want real evidence of skill, which is pretty easy to detect via whiteboard in most cases, not just the interviewer's gut feeling.

Sounds like the interviewer didn't bother checking references.

College buddies will tell more lies than the candidate will.

Either there are a lot of companies which employ unskilled developers who cannot even code fizzbuzz, or interviewing is not a great way to understand specific types of people.

This is one of the biggest things I try to guard against. Some people just interview better than a lot of other people, but that doesn't mean they do anything other than interview well.

And yet, you have to really wonder ... what did that person do writing firmware for the space shuttle? Did they really do that? Or did they somehow lose their mind after they left and now couldn't do a simple set of modulus operations on a FizzBuzz test? How can that happen? Even reading this kind of thing makes me totally scratch my head.

Plus the pressure of someone staring at you.

Then you feel stupid for not answering straight away.

The you get self conscious and start doubting yourself.

What was the question again?

I don't think there is anything especially unusual about it at all.

I worked in a different contractor in NASA/Clear Lake at the time but even before I read those papers the organization responsible for the shuttle firmware was held in the highest regard.

Whenever I've suggested it a usually more junior guy has scoffed at how trivial it is... I'm yet to then have one supply a complete and flawless solution. These are from people I work with, respect and happily rely on to be able to code. Their recognition that the problem isn't so trivial for themselves is the only thing I've got out of it - I'm no closer to understanding if it's just a poor test or not.

There first time I came across the problem was as a candidate and I screwed up the upper bound of my for loop just because I was slightly thrown by starting from 1 instead of the almost obligatory zero. Naming things, caches and off by one errors.

My worst candidate experience was only a couple of years ago when they wanted me to reason about booking cinema tickets over the phone (like it's the 90s?!) I've never booked cinema tickets and I think they thought I was joking, but they went at me for at least half an hour on what users would need to supply other than location, film title, date and maybe time, to begin the process of booking tickets. Why they didn't just tell me what attribute they were after I'll never know - eventually they just wrapped it up.

Number of seats?

For a person with that background, simply sharing a relatively small private room with a total stranger can be overwhelming. It doesn't matter what trivial test you're giving them, if they're not able to think. The test is failing to actually determine if the person can do the technical part of the job, instead it's testing how the person performs in close quarters shared with unfamiliar people.

The whole giving homework for technical vetting is a great way to get around this class of problems.

If, in addition to what seems to be a technically competent individual, you find they don't perform well in-person, then you take that data and weigh it against where your priorities lie for the position.

There's a huge difference in knowing "technically great, performs poorly with an audience" vs. "technically poor, but we only tested them with an audience".

Furthermore, it's not uncommon for people who experience anxiety during the in-person to loosen up as they acclimate to the office environment and their peers. These people can actually be some of the best contributors, and it can be a very costly mistake to misjudge them. This personality type tends to be quite loyal and averse to changing positions, because the whole process of interviewing and acclimating to a new environment is so stressful to them.

You seem to have a chip on your shoulder in this discussion, are you having a bad day?

He wasn't going to come to any works nights out or even lunches and like you said certain accomodations have to be made, e.g. access to a private quiet room for him at certain times... Able to work from home when he had to etc.

His father had to go to his interview with him, luckily the company allowed this. We have since gone our seperate ways but wherever he is working now got a great developer. I'd happily work with him again.

But people are already crying over take-home tests being like working for free for the company, and then there's no way to prove they aren't cheating, which is a showstopper. That by itself is definitely not a "better suggestion for filtering out people who can't code".

> all of these options will make the interview process more appealing for everyone.

No for people who can competently handle an onsite interview and don't want hours of extra work at home.

> And if the justification for angry/combative/aggressive interviewing is "well, that's how our culture is", I would say the company has a bigger problem to fix.

Maybe you being so disingenuous makes you feel better, but interviews aren't "angry/combative/aggressive" just because someone asks to see some code on a whiteboard.

In my experience, the whole process goes a lot smoother when there's a take-home exercise. It turns the in-person interview portion into a technical discussion about a recent mini-project unencumbered by NDAs and trade secrets.

If you can't quickly determine if an applicant "cheated" on the take-home exercise through a simple discussion, then you may want to recuse yourself from performing interviews.

If an applicant can't make enough time for an appropriately scoped exercise, I think it's likely they're unqualified or they don't value the opportunity enough to make time. Those are undesirable qualities the recruiting/interview process is intended to filter out.

I hope to never work with you.

If the industry wasn't so full of lying incompetents, it wouldn't be an issue.

I've been rejected enough to eventually learn all these. Then finally when I got hired, questions were the very basic define static, inheritance etc.

I knew it was a matter of numbers and should not mind the devastating feeling of rejection. But damn, you can never know how it feels experiencing tons of rejection until you do.

Here's the thing tho': my CV is honest and my track record is pretty good: some small companies and some name-brand, well respected in their industries, known for probing interviews, over about 20 years. There may be some bad actors in the global candidate pool. But seriously, asking me these questions is like tearing my CV up in front of me and calling me a liar to my face.

I am not in the market right now and hope not to be for a good while, but I dream of being asked a stupid whiteboard question, solving it, then throwing the board eraser at the interviewer's head and walking out...

Given how Da Vinchi had a resume its amazing we still use them. (His was better thoigh, it had his name and address, dates he worked for people and their names and address)

I wouldn't go that far. It still weeds out the honest-but-unqualified with minimal effort - it's basically a good early filter. This actually works for the candidate too - how much would it suck to 6 hours of interviews and then get told you don't have the right degree or some such?

Just skip them and ask interesting and difficult ones.

If a company cannot be flexible and reasonable enough to skip basic questions it's a bit of a red flag.

I've been having to give some interviews lately (though unfortunately they have to be within 'process') and my basic question is to write some code (with a computer) that outputs the endpoints of a line segment which bisects a plane between two input control points. (I give all the equations needed and the code is done within an application already set up.) It's still managed to trip up some people with experience who seemingly don't have the concept of representing a line mathematically (BS or MS in Physics, how?). We also tested it on intern candidates under shorter time constraints and a couple internal people, they did much better, I think all but one actually got the basic line done within half an hour even if edge cases remained. If we're given longer time constraints the problem and application framework scales to more interesting subjects like generating n-point voronoi diagrams and their applications, but we haven't gotten there with anyone yet...

I've interviewed many candidates. It happens to find people that cannot code at all.

Yet, one does not propose trivial coding challenges like FizzBuzz. Very little is gained from finding out that a senior developer can do FizzBuzz and then fails at any more complex coding. You simply go for more complex questions straight away.

I mean if you were at a party and some guy came up to you chatting, claiming to be a senior whatever at BigTechCo, you'd start chatting him up and you could tell if he was full of BS pretty quickly.

Hire using NN days contract-to-perm. Make the permanent offers after NN days.

For candidates with many years of experience, obviously they can and have been writing software effectively, so for me it mostly comes down to whether they could work well on a team, interact with clients successfully, and be capable of mentoring juniors.

This despite that my best known essay is titled "Object Oriented Programming Is An Expensive Disaster Which Must End" a fact the interviewer should know if they'd looked at my resume or spent 10 seconds looking up my name on Google. Wikipedia now lists me as one of the critics of OOP -- https://en.wikipedia.org/wiki/Object-oriented_programming

I'm lucky in that my position is comfortable, so I can laugh off stuff like that, and either educate the person I'm talking to, or end things quickly by explaining that there is probably some kind of cultural mismatch.

But it shows a remarkable laziness on the part of the people who, in theory, want to learn more about me.

The question is, can you whiteboard? They will be testing that. If you can, then all is golden and you probably didn't need to waste those 4-6 years getting that PhD because what you will be working on will have nothing to do with your topic of research (unless it was AI/ML).

If you can demonstrate that you understand programming concepts and can learn, then it's not much more to assume you can write code. If you need someone who can hit the ground running with some specific technology, then you might need to go deep into it, but not to find out if someone can program.

I think you're overthinking the feedback you got.

If it was at one of the big names, they have the luxury of being picky. They can't hire every qualified candidate, so they have to reject most of them. As the interviewer, the company policy likely dictates the interviewer give a reason. Which puts the interviewer in a bind because it implies that there was a good reason for rejecting you. So they'll put canned statements like what you got.

I recently got rejected. And one of the reasons given was something that 3 of the 5 interviewers had explicitly told me they don't care about. I recognized it for what it was - they feel obligated to give some reason, so they nitpick after the fact even though they told you they were not going to nitpick.

When I was younger, I often wondered how it was that New Senior Guy was totally incapable of actually programming, but very good at handwaving and bullshitting, and being patronizing. Now I know how those people got hired. Thanks.

You might as well have said, "Well, you know, when I was a young girl I once had a crush on an older man, and when he rebuffed me I badmouthed him on Insta and all this talk of older men coercing young women in employment is probably just schoolgirl crushes, broken hearts and vindictiveness."

It's true that young people can be cocky and arrogant. But there are unscrupulous people who use this meme to maintain their position, usually to the detriment of the young people. If your interview system is unable to identify such people then you will create a hostile environment. Hopefully, your good people will leave. Unfortunately, many will stay and blame or doubt themselves. I was very lucky in two cases to be at a start-up with a strong CEO who wanted to see results (which I could produce, but which the bullshitter could not).

I was also lucky that in those two cases, the CEO correctly interpreted my emotional expression, which ran the gamut of anger, isolation, helplessness, victimhood, righteousness, denial, negotiation, not as a lunatic but as someone in a fundamentally awful position, and why.

So in one specific case I'm thinking of, the senior guy in question tanked two consecutive projects and lost a major client, while in another, the CEO eventually called him out by asking to demonstrate doing himself what he claimed he was mentoring his team on, and firing him when he failed (the guy handwaved, boasted, and prevaricated but couldn't actually do what was asked). That CEO was fucking great.

I wish that were true, it'd make hiring so much easier.

1. Expectation of long work hours (Frequent and short deadlines due to agile)

2. Micromanagment being the standard (agile)

3. Terrible environments (open desk/office)

4. Removal of vacation time (unlimited PTO means you have no vacation days)

2 week sprint deadlines are entirely too short. say there's a larger project, it takes a lot of overhead to split everything up into neat 2-week releasable pieces. After the slicing and dicing, the big picture gets lost and garbled, adding more stress to developers.

Third, and most importantly, it offloads responsibility and ownership from management (especially upper management) onto lower level employees. Why should managers do their job if agile teams are "self organizing" and "self managing"?

On top of this, I'm not convinced product or business types are better able to design a good product than most developers are.

That's just not universally true at all. Using my current employer as an example, they have been very good about encouraging employees to take advantage of unlimited PTO.

Managers take PTO and encourage people that haven't taken it in a while to do so. Even the CEO goes in front of the company at all hands every once in a while and tells people "I just came back from a week vacation, you guys should too, remember to take time to recharge". It's something you have to get right in the company culture early on, granted.

I personally am so spoiled by this that the thought of having a set number of vacation days gives me anxiety. I don't want to count vacation days. It's not that I take a ton of vacation, I'm not a big traveler. But I like knowing that I can go to my manager and say "I'm taking friday off cause I'm going on a road trip this weekend" and he can just say "cool, just put it on the calendar" without worrying about counting days.

That said, I know this is really dependent on the company and have been in the opposite position at a company where PTO wasn't counted but was culturally discouraged, so I get where people are coming from. But I wouldn't just flat out dismiss the idea like so many on HN do.

> I personally am so spoiled by this

I had the standard six weeks of vacation per year at my first real job. How many weeks of vacation do you use per year?

I know, I was trying to add some outside perspective. Where I'm from, 5 weeks is the legal minimum, and everyone has the legal right to get 4 consecutive weeks off in the summer. Consequently, since everyone does this, and expects this, companies adjust for it, and most importantly: No-one bitches about it. There's no masochist culture around not taking vacation.

The problem with "unlimited" vacation is that it's of course not unlimited. There is a limit, it's just not written down on paper, it's not part of your employment contract. It's arbitrary. At one point, either your boss or your boss's boss is going to say no.

And if you get told no, you have no legal recourse! If you get fired for taking "too much", you can't sue for wrongful termination!

Fixed vacation time protects you as an employee. Why doesn't your company just give everyone five weeks of vacation and have that written down in the employment contract?

It's exactly like bonuses vs. salary. A bonus can always be withdrawn for any reason or no reason, but it's very difficult to lower someone's salary.

If it's written, it means that you have the minimum legal number of days in your jurisdiction and you are being screwed severely.

Then you're not doing a very good walkthrough. I can generally spot someone who didn't write the code they are presenting almost immediately. Occasionally, someone might fool you, but it's pretty rare.

As one of my interviewers said many moons ago: "Yes, his claims and credentials sound overblown. But after reviewing his stuff and interviewing him, he either is exactly what he claims, or he's the best damn liar I've ever seen. Either way we should hire him--the only question is whether for engineering or marketing." :)

I now have two steps before an in-office interview: an online programming test, followed by a screen-share coding test. When I just did the screen-share test, I can't tell you how many people claimed to be java programmers and their IDE was eclipse, and then they didn't know how to start coding or run a program. "I know junit", ok, write a junit test and run it in eclipse: deer in headlights. Such a huge waste of my time. So now we do an online programming test, and many applicants fail to write code that compiles, let alone passes the test.

There are good applicants out there. It seems like they are vastly outnumbered by frauds. I have no other way to describe these people that cannot program, and just show up with a bullshit resume hoping for a paycheck. Before I was responsible for hiring, a man was hired on our team who could not program, despite a resume showing years of java work. Now he gets to go to the next place with our company on his resume. These frauds are hindering us finding the genuinely talented.

Less automated / efficient hiring practices could also contribute to higher developer salaries, which would in a roundabout way, provide some compensation for what seems like "uncompensated" time spent intensively interviewing.

Does this fully replace the onsite? If I'm fully employed, interviewing with three or four places, and expected to take a day off and visit each of them, adding another full day of work on top of each is a big hurdle.

To keep going with the devil's advocate: If one of your competitors says "ok based on your initial chat with the director, we're gonna bring you straight to onsite" and you say "do this ten hour problem" guess which I'm going to favor? A hiring manager confident in his ability (probably learned through trial and error) to sniff out bullshit is a positive signal to me, the candidate. Intense homework tells me one of two things: they have way too many candidates for the role and there isn't enough data to screen by hand (this makes sense for seasonal stuff like entry-level, not so much elsewhere IMO), or they don't really have a solid picture of how to interview. And in the latter case, that probably means if someone else on the team or in the company suggests a bad but speciously-attractive technical design, they're also going to be unable to call that out.

One of the most mind-boggling interviewing processes I've been through went like this:

1. Write a program that satisfies the given requirements. Be sure to use the specified design pattern they explicitly requested. Include a suite of unit tests and instructions for building and running the program. Do this within one week.

2. Phone call with the team to discuss your program. Explain why you did certain things in a certain way. Discuss the design patterns you used, especially the one they requested.

3. A "coffee meeting" with some of the team members to discuss the cultural fit. They described their culture and the environment, and also talked about what I looked for in a job, my motivations and what I would do in certain hypothetical situations.

4. Full day of on-site interviews.

The reason I call it mind-boggling is because this process wasn't outlined beforehand, so that last step came as a total surprise; at that point, I had assumed they had enough information to decide. When I explained that I couldn't accommodate them within a week at least due to my current job, their proposed solution was to instead do two half-day interview rounds after normal working hours. This is where I decided to politely drop them, not so much because they wanted to make me go through an interview loop after a full day's work, but because they were going to make their employees do that, too. I was already concerned about the adversarial nature of their work culture -- anyone can nominate anyone else to be fired because "they don't belong there" -- and this just convinced me that I wouldn't fit in there.

The moral of the story is: your interview practices send a very strong message about your company. Be careful what that message is.

Wow. Reality show style office management, anyone?

If you keep hiring duds, you shouldn't be allowed to hire people. In spite of what the headhunter firms and cookie-cutter websites would have you believe, interviewing and hiring is a skill, not a punchlist.

>If a 10 hour project-specific coding task reduces mis-hires by 50%+, isn't it better for both parties?

Only if you pay me for my ten hours. Otherwise, you've already indicated that you and your company don't value me or my time.

> Only if you pay me for my ten hours. Otherwise, you've already indicated that you and your company don't value me or my time.

My favorite way to hire is short term consulting project into full time position. Not every candidate is willing or able to do this, but it has produced the highest success rate in terms of hiring signals. By the way, this underscores that it's not a money problem - hiring the wrong person is a lot more expensive than paying five candidates to produce something meaningful (and find the best one of the five).

Some of them were former coworkers who leaned very heavily on algorithm problems and whiteboarding because they were terrified of people who couldn't code at all (though wouldn't that be the easiest kind to let go?). But they still missed sometimes. Both on people who'd studied purely for algorithm questions and got through, despite having little practical ability; and on people who could knock out a task but had no ability to reason about its place in a larger system, so created more work for others than they contributed themselves.

In theory, yes, and that's why they're popular. But you're missing that:

1) The candidate has to do this for each job they apply for.

2) There's no investment on your end, and I have no idea whether you're just going to ignore it after I'm done.

Working for nothing __is__ obnoxious.

Not to belittle anyone but...a plumber is licensed. An electrician is licensed. Even a hair stylist is licensed. Perhaps licensing a programmer / developer / engineer would be over doing it. (Read: Yes, it would be. But the examples do help.) That said, can't there be a formal certification(s)?

If the time from these "take home test" was invested in a more universal certification process, wouldn't that be to everyone's benefit? A recruiter with value add, if you will

The employee gets a clear picture (read: context) of where his/her skill set stands, or doesn't.

The employers get to mitigate risk and fear.

All parties gets to reduce friction and time.

Clearly, no one is happy with the status quo. That's a problem. It's also an opportunity. Hint. Hint. ;)

Shitty plumbers are licensed. Shitty electricians are licensed. Shitty hair stylists are licensed. A license says nothing about current competence. It says the person demonstrated some minimal level of competence at one point, fills out their paperwork every year, and hasn't fucked up royally enough yet to have it revoked.

Every time this subject comes up someone inevitably points to licensure as some sort of panacea. Licensure does not replace skills or competency assessments.

Because a license/certification test is the exact definition of "skills/competency assessment". If the licensing test doesn't meet those needs, that's not the fault of licenses in general, that's a fault in the test and can be fixed.

That is not at all what I said. I was addressing how licensure does very little to prove competence for the three trades specified in the post.

> Couldn't it just be that a "programming license" has regular testing and re-certification?

How many licenses require recertification? Why do you think a programming one would? Continuing education requirements do not count for this, as they are mere completion measures.

> Because a license/certification test is the exact definition of "skills/competency assessment".

Yes, and this test needs to be passed once. The longer ago it was, the less it says about the person now.

Because it doesn’t exist yet, and my hypothetical is just as good as yours.

It's also why I pivoted to certification.

There is no panacea, nor is the status quo sustainable. So where's the disruption? Where's the innovation?

https://en.wikipedia.org/wiki/Dietitian#United_States

--edit: I think you might be talking about a nutritionist (https://en.wikipedia.org/wiki/Nutritionist) which is not regulated in any way and is not a medical job. These are the people who will talk to you about essential oils and homeopathy and Herbalife.

That's 4+ years of study right there, that we did to prove that we could do the job, but no, fuck that, some of those people freeze up during an interview and a handful of those people we brought couldn't demonstrate their programming skill, so we decided we can't trust that for ANYONE.

Sorry, go invent some new way to certify yourself. How about 2-4 years of intense study and a new test, like a bar exam that lawyers take! Or just get your PhD! Just study for half your life, go waaaaay into debt, and take the exact same salaries we are offering now, because we don't reeeaaaaally want to pay you as much as we're paying now, so we're sure as hell not going to offer to pay more for that extra effort.

If you thought a day long test was too annoying, then your only alternative is spend even more time and get something we're just going to ignore again the instant we make a bad hire with someone with that license!

(For the record, if I could take a single certification test and skip all this interview bullshit for the rest of my career, I would have done that years ago. I hate going through the technical interview gauntlet, and I'm one of the good programmers, at least once I'm on the job).

How often do you hire some one based on certificates?

Also, in the United States, you could fire someone easily if they were really incompetent. Considering how much time and money people spend per candidate to interview, it's probably much cheaper and more efficient to hire faster and fire faster. Some companies are spending tens of thousands of dollars per candidate they interview!

Hiring is a skill, and an overly long or drawn out process is a sign of bad hiring, not good hiring. The second part of the equation is to train people up and mentor them. Hiring is not enough. The second big part of good management is to actually get the most out of people and to help them learn and grow.

Now if it were only the tech industry that had long, ridiculous hiring processes, maybe we could say that it is necessary, but many companies and many fields have similar processes. I believe that many people have mistaken length of interview process and time spent with rigor.

I'm not hiring people who can talk and not code. I'm hiring people who can code (and, ideally, talk). The only way to verify that they can code is to witness it happening.

Reality is otherwise. Lots of paperwork involved (for both hiring and firing). And leads to a not-too-great work culture.

There is very little paperwork required to fire someone.

If the employee is still on contract (ala contract-to-perm) just collect their badge and be done with it.

If they are a W-2 employee with benefits, you hand them a few benefits notice forms and send them on their way.

If they apply for unemployment, the company will get a notice that the former employee has applied for benefits.

Plus there's the added risk of hiring "duds" that are also minorities. And letting too many of them go will make it look like formal discrimination. Which is a much, much more expensive mess.

And then there's this issue of finding the duds. Easy for the people on the ground to spot, but less so for management and HR, which will require some form of reasonably accurate performance evaluations.

The Glassdoor reviews on Netflix suggest otherwise.

Check out interviews and jobs section on pilot forum for comparison with our field: https://www.pprune.org/interviews-jobs-sponsorship-104/

The best interview I had from a technical perspective was when I was asked to bring in my laptop with some of my code. , talk a bit about it and add a quick feature. No pressure as I knew the code and the framework. I felt like I could show off what I was good at. It would have likely caught out impostors as well.

This is true. Often the types of things that folks look for though are nuances and style that come through with what someone writes. Do they have comments in their code? What standards are they following? Do they have test cases? How well do they handle exceptions? Etc.

The structure and accoutrement that comes along with code / work product can be quite telling.

The above being said I'd say what you did in the "best interview" was very appropriate as well. What I've generally seen out there is a "homework assignment" is often a one size fits all as an attempt to eliminate qualitative bias ...

Actually "open source contributions" isn't just about having some code dumps on GitHub.

First of all you've got the stream of commits, which is very gradual and shows you how the project evolved and since when. And you also have the issues, the pull requests, the interactions with other people. Those show you how the candidate communicated and collaborated with others.

You know if the code is his own or not because it's usually all there, everything that's needed ;-)

The industry's hiring practices aren't broken. What is broken is our ego.

I've also seen people that can ostensibly get the job done, but will write code that is so byzantine, so incredibly cryptic and opaque that no one else can understand it. I'm not talking about code that is incredibly clever, although that can be a problem, but code that is simply orders of magnitude more complex than it needs to be. From management's point of view, they've accomplished the task, at least in the short term, but to the people who have to deal with their code, it can require more work to make fixes or improvements that it would take to rewrite it all from scratch.

The real reason that it's so hard to hire a good developer, IMO, is that there are very few good developers, but a huge number of bad developers that have managed to convince their bosses that they are good, or at least competent, because there are also a not a lot of good development managers.

Can we really say that software development, as an industry, is really any better than it was back in the days of "The Mythical Man-Month"? Sure, the tools are lot more sophisticated and powerful, and the hardware has exceeded any reasonable expectations, and even imagination in some cases, but I don't think our ability to develop software has really improved all that much.

The solution? Sure, come in, do a shift. See how you like the kitchen and the environment. We'll just give you some cash for your time.

Interestingly this goes away at a certain level of seniority, but I always liked it as a simple way to get a feel for a potential hire.

And it's enough for someone with good social skills to get a great recommendation without skills.

But this tends to be rare in practice, of course, because the pool of potential people being hired is very large.

Unfortunately there are about 1000 competing bodies trying to be this association. It seems that the tech crowd would rather in-fight than work together to be treated seriously.

Passing off someone else's open source as yours would be a hard lie to keep under wraps, an easy lie to uncover and I've never heard of anybody doing it to score a job.

Have you ever heard of this happening? Even once?

Many participants in the game unfortunately insist on hiring and marketing by three-letter acronyms.

- People starring your GitHub repository.

- Someone following you on Twitter.

- Someone linking to a blog post you wrote.

- Someone recommending you to someone else because you did a great job on a project.

These are all examples of informal networks of trust.

I fail to see how that’s a bad thing.

I have 0 stars on Github. Don't use twitter. Don't have a blog. Only a few coworkers I even talk to.

I spend my time writing code and interacting with my family, not trying to win popularity contests. Now if you're looking to hire celebrities instead of programmers, you're maybe onto something. I'm not a self-promotion artist. If I were, I would work in advertising.

That kind of aversion towards self-promotion might be a reason why we arrived at absurd phenomena like homework assignments for interviewing processes in the first place.

With no way to draw upon previous work results or third party trust how else is someone supposed to assess a candidate’s skills?

If I come across or meet a new person from this industry and that person has a Twitter account I routinely check the follower count.

A somewhat large number says to me: “Many people seem to think that person has something relevant to say.”

I don’t think we can magically solve inequality by trying to fix the interviewing process or by denying there are social networks.

http://www.abc.net.au/news/2017-06-30/bilnd-recruitment-tria...

”Professor Michael Hiscox, a Harvard academic who oversaw the trial, said he was shocked by the results and has urged caution.

"We anticipated this would have a positive impact on diversity — making it more likely that female candidates and those from ethnic minorities are selected for the shortlist," he said.

"We found the opposite, that de-identifying candidates reduced the likelihood of women being selected for the shortlist." The trial found assigning a male name to a candidate made them 3.2 per cent less likely to get a job interview.

Adding a woman's name to a CV made the candidate 2.9 per cent more likely to get a foot in the door.

"We should hit pause and be very cautious about introducing this as a way of improving diversity, as it can have the opposite effect," Professor Hiscox said.”

Is there racial or gender-based inequality? Yes, unfortunately there is.

Should we therefore resign and stop trusting each other altogether? No, we shouldn’t.

We should rather try and extend our trust to others.

Inequality isn’t caused by trust but by a lack of it.

>Should we therefore resign and stop trusting each other altogether?

This is a strawman, that was not suggested. What was suggested was to have an interview process which doesn't involve informal/subjective trust. The best programmers don't have huge twitter networks or github stars - some might, but not all. That's no criteria for filtering.

Don't be silly. GPDR is going to save the world, solve all of the internet's problems and bake you nice warm croissants in the morning.

GitHub and code samples can be useful, but not every candidate will have shared code on GitHub (in fact, most don’t) and retaining copies of code they’ve written for a previous employer is a major red flag.

The biggest issue with using prior experience is that it’s hard to compare the ability of programmers who work in different languages and different domains, it can be like comparing apples and oranges.

I believe it's actually easier. If everyone is given part of the whole and 4 out of 5 people get theirs done properly and 1 is flailing, everyone, and I mean everyone on that team knows it.

How do hospitals make sure that their surgeons can do surgery without having them do surgery? Do they have some magic eightball?

Or what about non-technical middle management? Or HR?

However, CS is close to something else: Economics. People spend 4+ years learning about economics, but don't know shit about how it really works. They found a solution for that: business schools.

CS at a University versus CS at a technical college.

If you are going to devote 40~50 hours a week for a company thats going to pay you 6 figures and you are not willing to work a day or two, you have your priorities crooked.

And yes, just having a resume is not enough to figure out the good from the bad ones. If we knew that perfectly , there would not be any need for any interviews of any kind.

We do, it's called the probationary period. 30 or 60 days, or even a bit more. If the person isn't working out, or is not a good "fit" you can say goodbye. And it goes both ways. Candidates might find that the actual work or work environment is not what was portrayed in the recruitment process. If they don't like your company, they can leave.

There are times it makes sense to do the high-risk ones: devs that are unproven, without great academic and work backgrounds, looking to get a foot in the door. Companies that are not well funded looking to find diamonds in the rough, since they can't attract people who already have proven themselves. I've been that dev myself, based just on a strong sense of how the CEO and myself were on the same page based on our conversations.

But it's definitely not a risk I'd take again from where I am now. At a more established place with people I know who vouch for the folks involved, there's a much lower chance of a new FTE getting canned within a few months for anything short of egregious behavior.

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