Hacker News new | comments | ask | show | jobs | submit login
The latest trend for tech interviews: Days of unpaid homework (qz.com)
659 points by draven 10 months ago | hide | past | web | favorite | 997 comments



Our industry's hiring practices are absolutely obnoxious. In an ideal world, you could trust someone's resume. e.g. "I've written large production programs in C." Ok, great, so then clearly this person knows C so there should be no need to dissect code or run them thru some linked list algorithm and see if they know how to use pointers correctly.

Yet, we do. Ok, then what about open source contributions (if they have them)? Well, sure, but we don't really know, for sure, if that code is their own or if they indeed truly wrote it, can we? So we can't count on it. It helps but it can't be an automatic "this person passes the technical" signaler.

So maybe the person shares actual code and walks us through it that they wrote, even if not open source? Again, we can't know for certain it is their own code and not some friend who wrote it for them 2 years ago that they claim is their own. Or was a teammate's, or what-have-you. So we can't count on that either.

Apart from getting a candidate to actually pump out some code, even trivially, we don't really have a way to de-facto verify that the person says they can do what they say they can do, short of a personal reference from someone, say, in the company already that knows and has worked with the person in the past.

I absolutely hate this practice of having to constantly "re-prove" to the next employer that someone knows how to write software. It's extremely redundant and yet we keep on doing it, with no real hope of actually making it better.


> Our industry's hiring practices are absolutely obnoxious.

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.


Real talk? I'd be concerned that, at a non-tech company, I'd be seen as a IT rather than a software engineer. And the conventional wisdom goes that IT is a cost center.

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.


The best "work environment" tech job I ever had was at an investment bank. Didn't disrupt anything (quite the opposite) but got great experience with databases, unix, C, scripting, working with internal clients, determining requirements, managing projects, etc.

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'm gonna second this. Started my career as a software dev at a commodities exchange. Pay was excellent for the area I lived in and my experience level, 9-5 was 100% standard and enforced by the team culture, on-call was nonexistent as dedicated support people handled that, bonus was better than the ones I got while working at Microsoft, and got to work with some of the best software engineers I've ever met. Incredible job security, no one got let go or put on any kind of PIP as everyone was pretty self motivated--even if they weren't the best. All in all, I would highly recommend this as a good career path.

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.


There's a very strong correlation "you have to dress like an adult", and "you will be treated like an adult".

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.


In other countries, it's very common for boys to wear a shirt and tie to school. Even here it's part of the uniform at many private schools and some charter schools, and it's the norm for children at formal events. It's not 'grown-up' attire, it's 'serious' attire.


I wore a tie to school every day in high school. Then I did it again at a well know startup. In both instances someone pulled me aside to tell me "keep dressing like that and you're going to stand out."

Yes.


I attended catholic high school in nyc from 1965 to 69 and we wore a sport coat and tie with dress slacks. Hair length inspections were conducted. It didn't kill anyone as far as I know.


The way I've always seen it, if you insist on being able to dress the way you want as a means of self-expression, then you really don't have anything worth expressing.

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.


"If you insist on being able to dress the way you want as a means of self expression then you really dont have anything worth expressing."

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.


Well if you think about it in terms of the man-hours that must have been wasted doing "hair length inspections", it's probably equivalent to at least one person dying young :P


The zeitgeist in tech and in culture generally is a moving target. Look at dandyism in the 19th century, no one would argue that is how grown-ups dress today.


Well, there is Connecticut.


I wore a blazer, shirt and tie for every year of school from 11 to 18 years old, everyone did. In fact the last two years we a full tweed jacket that spelt like wet dog when it go wet and was nigh on indestructible.


> got great experience...

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.


Interesting! How would you recommend someone transition from a startup-y job to one of those? Anything they look for in terms of qualifications?


Apply. I would like nothing more than a flow of applications from smart software engineers with BSs over scientists exiting of postdocing and MCFs.

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.


They're large companies recruiting pretty much in all area of technologies. If you have experience in something, you should be able to get an introduction through a recruiter or find an existing employee to reference you.

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


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


That might be the difference between "investment bank" and "bank" because I've heard stories about near-unhirable people who've been toiling away with Java 1.5 (as late as 2016) at (German) banks. They hated it, wanted to get out, but they'd lost touch with current tech unless they managed to sneak in some off-work hours with non-ancient stuff :/


Working at a (German) investment bank still using Java 6 and Perl 5 extensively in 2018, I can assure you it's not just retail banks. Legacy technology mires are everywhere in the enterprise world and often the premia to work in those places is precisely for dealing with this kind of old technology and decades of technical debt.

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.


Real talk? There is nothing wrong with being in IT. Imagine if someone said "I would be concerned I'd be seen as a carpenter and not a woodworking artisan".

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.


> Imagine if someone said "I would be concerned I'd be seen as a carpenter and not a woodworking artisan".

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.


At any decently sized company, there is no overlap between IT (helpdesk and desktop support) and engineering jobs. I worked at a regional company with six people on the security/compliance team and not once was I ever asked to fix a printer or troubleshoot a laptop. We had dedicated people for that.

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.


Unless you're George Lucas, and then you hire a team of cabinet makers to build your deck.


IT fixes peoples computers. Software Developers don't do that. We aren't Network Admins, we don't know how to set up or fix AD and we don't manage hardware. IT is a different field. I write software to process data and mostly I don't interact with hardware or troubleshooting arbitrary software directly. If I am offering support I am a level above IT. I understand that IT needs to be done but it is a very different job and should be treated that way.


... and that is wrong with the software development today. Our generations of developers started with playing games, using computer, reinstalling, configuring computers, then we started to mess with computers, os, hardware, network, routers, programing came in somewhere in the middle (we wanted to make a game, demo scene, ), cleaning malware, then we started automating the computer tasks, learned multiple programing languages with a clear vision - "I want to learn C, coz then I can do anything" :D, switches multiple computers, security started to become an issue (winnuke (tm) :D), riding the irc splits, taking over irc channels for fun, started to study networks at low level, got first data loss, learned to rescue data, switching controllers on hard disk, studying prolog as it was hilarious, got first job, ... when we started to develop commercial software we had accumulated decade of knowledge from multiple platforms and OSs (I have wrote my first program in simons basic on c64 at age of 11, put together my first 386 from components). We have tinkered with anything coming under our hands, software development was just another skill and we use our knowledge from IT in development and vice versa.

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


>web and sql is all I know

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.


Hop off your high horse, gatekeeper.


Why, I have a good view from here :) And I can take great photos of scenery, now I do understand what the photos are showing is not something that everyone would love but still, those are photos, you can shoot the one making them but the scenery is not going to change by that, or we would just shoot all war journalists and there would be no more wars.

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


I started on other peoples computers personally. I poked around and played with linux and some networking and when I went to school for it I realized that it was too late to learn it from the ground up. If you are still trying to figure out how a driver is written in C then you aren't up to date on any current programming paradigm. While I get that 20 years ago you needed to care exactly how memory was handled to properly optimize your code, now I am writing data processing jobs that take 10-15 TB of memory spread across 30 computers. If I fuck up 1 MB of ram per computer it really doesn't matter and it is way more efficient to just add another machine rather than pay me for two months of work to fiddle it down to perfect.

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.


I would argue that demand has increased dramatically, but the supply of natural-born developers (eg. those tinkering since childhood, not just following the money) has not.


In my experience, Software Developers that can't configure/diagnose/fix hardware/networking issues are usually pretty mediocre at development as well. And vice versa for "IT" guys that can't program. Specialization is for insects.


> specialisation is for insects

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.


IT fixes peoples computers.

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.


That definition morphs by time and company. At the last place I worked the IT department was the devs, dbas, net admins, and help desk.


This is the case at every non-tech company I've worked at. It's (mostly) the tech companies that segregate IT as a lower-status function.


It can happen either way.

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.


> where everyone did everything, and where doing everything was considered high-status: it meant you were competent at everything.

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.


I feel your pain. That is exactly where this kind of reasoning goes.

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


I'm at a "tech" place, but we're very small (8 developers).

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


I think I've made myself misunderstood. I'm not intending to put down IT work or the people who do it. But from a career perspective, if I want job security and a higher salary, I think it'd be a mistake, in the long term, to be seen as IT. IT is seen as a cost center, which leads to corner-cutting and outsourcing--even when it ends up costing way more in the long run.[0]

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


Tell that to $250 hr SAP and Salesforce Architects/Developers, or to Baby Boomer COBOL programmers who are given ever increasing incentives to post-pone retirement.

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.


No idea what a 'salesforce architect or developer' is, but how would a COBOL programmer be considered IT staff? (In the context of this thread where IT staff == support staff)


I think where the IT/development issues meet is that software development departments can also be outsourced, just like IT admin and support.


Many non-tech employees view IT people as basically “computer janitors with bad attitudes”. Heck, I’ve worked in tech for a decade and I can count the number of people who have a positive view of their IT department in one hand.


Doing ops at megacorp meant that we got treated like code janitors by our own management.


To be fair, In my (admittedly limited) experience contracting at BigCorp - the IT department's procedures are often a bottleneck in a workflow or solutions.

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 my experience they're also critically understaffed.


Right, but putting a face to a blocker in a project is hard to remove mentally.

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


> Imagine if someone said "I would be concerned I'd be seen as a carpenter and not a woodworking artisan".

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.


Nailing boards together is building something. Carpenters aren't pissed off that they didn't grow the trees themselves and and chop them and haul them and plane them.


I think that sort of work is actually given to a "hammer hand" or a "builder" in New Zealand. I think a carpenter is a step above those.


Framers and cabinet-makers are both carpenters, but they're very different jobs.


For $350k/year i would change a light bulb



Many companies these days make a distinction between IT, digital, and product.

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


This isn’t true any more with software eating the world. I work in movie distribution for instance, which was traditionally sending reels of film, but is now all RSA, certificates, HSMs, remote device management, logistics, Analytics, ticketing, databases and distributed computing. The software team gets pretty much the same treatment as everyone else, but everyone knows it’s the future of the company and sets a pretty high bar.


Speaking of which, our interview process is to ask you to solve a challenge on Github, but you’re free to keep it open source as an indicator of your skills. And it’s not work for us, these are obviously toy / proof of concept problems that we solved ages ago.


The solution to the first point is to go to a place that already has an IT department.

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.


Most larger companies have clearly defined boundaries between IT and software development. And with the push towards automation and security at every layer of the stack, even IT has a growing role for software architecture and development skills.


I've worked at a non-tech company as a software developer. At that place the department (we were rolled in with IT) was viewed as just another cost center. It's not great.


>And the conventional wisdom goes that IT is a cost center.

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


Yea, they don't generally "go back to paper", they outsource overseas...


Hah, in my experience with companies using cheap developers overseas, going back to paper might be better.

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


> I'd be concerned that, at a non-tech company, I'd be seen as a IT rather than a software engineer.

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.


No, that's nearly every company. But if there's 10 software engineers working with 50 MBA's who drive the business, none of them can tell the difference and treat you as such, which happens more often than not outside of a tech company. They are the ones making the company money, and you are the programmer doing that "easy programming stuff for IT nerds". It's not that rare of a situation


Yeah, NEVER be overhead if you can avoid it.


You're not just comparing a tech company to a non-tech company. You're comparing a startup to a non-tech company.

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.


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

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


Ford didn't go public until ~10 years after Henry Ford died.


> Henry Ford didn't have an "exit strategy"

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.


I've done both.

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.


The problem is that no one gives a shit about code quality at such companies.


If code IS supposed to be treated like a language, ya'll are being equivalent to English snobs.

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


I would be very interested in learning what this entails, actually.


[flagged]


Pivotal and Amazon would not meet the rate and benefits that my current real company was paying, let alone the one that just poached me for a 15% raise. She's spot on.


What company do you work for so I can point out 20 different tech companies with significantly better benefits?


Have you considered that you might both be talking about different sectors of tech, and different countries? The EU / UK / US / etc. tech markets vary wildly in these things.


Of course he could be talking about Europe but there are very few European "tech" companies. Tech is a horrible descriptor of course, he could be talking about 1000 different things.

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


> there are very few European "tech" companies.

I very heavily disagree.


I used to hate it, but have now performed enough interviews of supposedly senior devs with decades of experience.

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.


I’m going to show some vulnerability… this happened to me this week. I’m probably like a lot of you here: professional software developer for 20 years, have shipped countless products in multiple languages / technologies. Work has appeared on tv and print media multiple times. Have generated millions and millions in cost savings and revenue for employers and clients.

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.


There's no shame in it. Same thing happened to me last week, and I was furious about it. I've resolved not to take any more live coding interviews, on the grounds it is uninformative, degrading hazing. We're composers, but we're being tested as if we're live concert pianists. Then companies complain that there's a talent shortage! This hurts everybody, and it needs to stop. For my part, I will refuse to participate any further.


> I've resolved not to take any more live coding interviews, on the grounds it is uninformative, degrading hazing.

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.


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

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.


Exactly. The previous poster doesn't seem to grasp the nature of stress and its variants relative to the social or work situation.

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.


Soo...when a mission critical system at your team goes down, you get the newly hired guy with no previous knowledge of your code, put him in front of a dev environment he doesn't know and keep pestering him over the shoulder while he tries to get the system back up?

Sounds like a great place to work...


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

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?


> Depends on the job.

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.


Would you be OK with interviewees giving the interviewers a quick coding test? You know, to make sure they won’t be working with people who can’t carry their weight?

Remember, interviews go both ways.


Right? I wouldn't feel comfortable working with colleagues who couldn't instantly come up with a novel sorting algorithm to some bizarre scenario I thought of to stump people. So maybe I should "counter" each coding question with my own. It'd be like a shootout. This isn't a dysfunctional culture, right?


Yes depends on the job, but if it's a stressful environment, you need to train for it. OTJ. That's a management issue, not a coding issue.

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.


And when you make fire drill in company someone has to die because that what happens in real fire situation. Sorry Bob it is your turn this time :)


You appear to view stress as a good thing, or, at the very least, an unavoidable part of the job. It seems likely to me that you deliberately manufacture stress by deploying mission-critical systems that have issues. Seems there might be deficiencies in your pre-deployment testing regime -- a stress factory for sure.

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.


I agree this point is valid, but I think it's much more exceptional than whiteboard interviews are. I've personally never applied for such a job, since I typically work on consumer products at BigCos with a glacial development pace.


People have already hammered you for this, but a Merciless Judge actively looking over shoulder while you're working is a completely different kind of stress than trying to get a fix out the door ASAP.


Only way to code under pressure like that is with practice. I turn into an idiot non-coder in these situations, but I've gotten much better over time, to where I always pass a live coding session. In the real world, I spend a fair amount of time thinking and teasing a problem apart before I actually start coding. This is hard to do in an interview - even if the interviewer says "think about it for a few minutes", they will inevitably step in and offer a suggestion after 30s of silence. It's like you have to code by pure instinct. Which is doable with practice. But it's hugely skewed towards people who have the time or desire to practice such things.

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.


This. I noticed that I have gone for over fifteen years through some pretty tough jobs, but never needed to write any Leetcode binary tree problem from scratch in thirty minutes in my work while being questioned. I normally freeze up because I worry about current best practices every step of the way.

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.


>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 am sympathetic to this but I have dealt with very senior candidates that could not demonstrate any coherent thought about a given problem over a whole interview. Others don't get code done but at least they can express a clear understanding of the problem and have an intelligent conversation.

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.


So a little more on the interview. I've got a laptop setup with eclipse, all rigged up with an integration test and filled out function signatures. I show the interviewee what to press to compile, and the subsequent failing tests. The code builds in it's initial state, but the tests fail. I also show them on the desktop that the original source is squirreled away in case they fat finger and erase everything (I've totally done that too, lol. Source control is a beautiful thing in the real world). Then I peace out for a few minutes to give them space (I know I'm close to an order of magnitude worse at typing when someone is looking over my shoulder).

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.


Luckily, no one ever customizes their IDE, source control aliases, has wars over emacs versus vim, or uses an alternate keyboard layout.~

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


I think this profession tends to attract obsessive and neurotic personalities by its nature.


It's not entirely obsession/neurosis either. Several of those things are valid training/familiarity needs and/or safety/ergonomics/self-care needs.

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.


Todd, is that you? Sounds a lot like the process used by someone I worked with years ago.

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.


> dehumanizing the candidate into a “code monkey.”

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.


A dev manager I work with insists that one of the best indicators, along with all the usual things you try to suss out about a software development candidate is whether or not he does any software development in his spare time. Not everyone who's good does, but there's a good correlation between people who would be good at writing software, and people who do it for fun.

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


Haha, nope, not Todd.


Nice try, Todd ;)


Pair. I do this. I drive, with my machine, on my setup that I'm comfortable with. They navigate, and tell me what to do.

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.


I find trying to describe what I want another person on a computer to do an incredibly frustrating experience. I can't imagine how awful it would be under interview conditions!


It happens to a lot of us and sometimes fear that is just how the industry is. I have heard senior engineers just stop interviewing and often switch jobs via their network/friends.


>I have heard senior engineers just stop interviewing and often switch jobs via their network/friends.

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.


Failing a high-stress technical screen and being unable to write fizz-buzz in pseudo-code are two very different things though.


What you experienced is called hazing. Illegal in many contexts but for some reason it still thrives in tech land.


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

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.


Similar thing happened to me in a Google phone screen with coding exercise.

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.


I did phone screens with google and facebook. Felt like Facebook went kinda bad.

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


Perhaps it's because you insist on testing their ability to live code on the spot as a performance piece, and misinterpreting that as testing their ability to code. If you're turning down someone who wrote space shuttle firmware, because they "can't do fizzbuzz", then you are administering a terrible test and getting a false negative.

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.


> If you're turning down someone who wrote space shuttle firmware, because they "can't do fizzbuzz", then you are administering a terrible test and getting a false negative.

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.


Small companies also excel at hiding mediocrity.

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


> Small companies also excel at hiding mediocrity.

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


Or not


The equivalent would be asking a math professor to do integration by hand. They can do it, but that's probably not the job they want anyway.


That is why I advocate for a hypothetical "bar exam" for the software programming profession. I also posted a question concerning that: https://news.ycombinator.com/item?id=16702389

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.


I've been advocating for the same thing except I call it a "Software Engineering License".


I'm intrigued by the on the spot performance aspect, so I wonder if anyone has performed a skit at an interview. It's a tempting idea. Some people are intrigued by live performance, especially the kind with constraints like this, people like Frank Abagnale for example.


Probably, most likely on the Ali G show. If you know enough inside details on the typical interview pattern at a company this would be easy to do, and you would probably get the job.


Then the other option is to do a small take home test. Are you ok with that?


The other option is to check references, do credential checks, and simple bullshit screens during interviews, like every other professional interview.

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.


Every accountant attending an interview can produce a certificate from an accredited national group saying that they have taken an in-person, proctored exam on double-entry accounting, which is the 'credentials check' you refer to. There's nothing like it for programmers.


There are plenty of options. Programmers only just have to pick one, or create a new one for all that it matters. For instance, NCEES that runs the Professional Engineering accreditation that every other Engineering discipline utilizes, has a Software Engineering PE. Tomorrow we could grandfather in every Senior Dev with 5+ years experience as a PE and then start requiring it, and encouraging kids to train for it and acquire that accreditation.

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


Have you seen the Software PE? In contrast to the other PE exams, it manages to cover everything except actual programming.

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


That is because it is an actual __Engineering__ exam, not a programming one. Testing for programming skills in an SE exam is like testing a mechanical engineer's CAD skills. I would argue that the majority of "SE" jobs do not actually entail engineering but software development (or construction), which is only a small subset of SE.


The computer engineering exam has tons of the underpinnings covered, with a whole section on relevant math. Where as the software one pretty much only covers process. The one algorithms or discrete math question they have boils down to just 'what is big o complexity'.


I guess the question is what is the necessary "base set" that shows proficiency enough in learning that you could throw someone at a problem and expect them to solve it. Keep in mind that to keep a PE active there are also lifelong learning requirements.

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.


And? You think that a certification exam provides more evidence than a university degree? (which, let’s face it, most programmers have).

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.


You mean a CPA.

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.


I don't see how that is actually doable all the time. In my short career I have moved from embedded c / c++ game engine / full stack / DBA / backend. All at different jobs with the previous manager not knowing I actually knew how to do the next job, if they were asked anything other than generic questions I would have sounded like a fraud.


This is not to take away from your point, since I agree with you, but both accountants and finance professionals have stringent licensing requirements which (in theory) could provide a baseline expectation of competence.


That is the reason they get away with not testing them, because they have a universal test they can look to. Software jobs are pretty fluid, so unless we have a massive standard test that cover anything from embedded c to FE with react, it seems that kind of test is out of reach for software people.


Civil Engineering has a huge gamut in specializations and in the last century has seen quite a lot of technological change; programming isn't as special as it thinks it is here. A credential test doesn't have to cover everything, it just has to cover the foundations and get some sense that a person is capable of life-long learning and improvement.


What about jobs like "business analyst"?


Yes. I told the interviewer he could call any of my past managers, knowing they would take the call, and knowing they’d give a glowing report. He laughed!


Well...fuck that guy. There is really no better measure, assuming you have the basic social skills to see through a con job/scam. I mean yah, you could always be tricked into calling someone's buddy or something, but with any depth or tactful questions that is rarely going to fool anyone.


The other, other option is just refuse to do either. I get all my work from friends I've worked with in the last 20 or so years. I mean if a company insists on these hiring practices, and they continue to get bad applications because of it, the probably aren't going to be around for long anyway.


Ok so you are out of the running for this, this is obviously for testing people you have never met before.


Yes. I strongly prefer an offline test, if it realistically wouldn't take more than a few hours.


Yeah we try to have a limit of 4 hours for this kinda thing. We understand that it is the interviewee's free time but when you need to screen 12 people for a job it is not worth a Senior Engineers time for a small startup.


WHAT?!?

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.


Sorry I assumed that the word 'screen' was universal. This is the first step, it is a waste of a senior engineers time with a candidate that is not even close to ready for the job.


Yes, I suppose 'screen' is a bit ambiguous. Doesn't seem like a pool of a dozen is the first step. I'd want the Sr Devs involved at least out past the final half-dozen if not dozen -- not for 4 hours each, but at least a chat about what they've done, problem-solving approaches, etc.

I wish you luck


I always end up linking this piece in response to people like you, and here I am again.

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.


Agreeing with and expanding on the interview studies... In most cases, the job that one ends up doing has very little to do with what you were tested for in an interview. Languages usually have some sort of approved/well know implementation of common data structures and algorithms. When you are asked to do some BFS/DFS/binary tree work in 45min or less you are unlikely to do that for the job. Someone has already provided an implementation. I venture, you are most likely to see it bought up in your next interview (whenever that is).

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.


I'm amused at the idea that because I pass on senior devs who literally can't do FizzBuzz, that I must have a terrible interview process.


Sure. But, of course there is a difference between having a conversation about the overall trends of a practice versus a small subset of personal experiences. It's also important to define what you mean by "can't do FizzBuzz". Like they can't even do a basic loop or they don't get it perfect, in the exact way you think it should be? Because those are very different as well. 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.


> It's also important to define what you mean by "can't do FizzBuzz". Like they can't even do a basic loop or they don't get it perfect, in the exact way you think it should be?

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.


Why didn't you check references? I mean wouldn't you consider it a failure that you got a candidate to the interview table that was so bad? Assuming you aren't making it up, the guy was obviously lying on his resume, that could have easily been solved by checking his references.


Most places that firmware devs come from around here have a policy of only verifying dates of employment. That doesn't tell you much.


References would be personal references - someone with a cell number and call the college he attended; they should also verify enrollment and completion. You don't want to be calling the HR department. Also, a secret is if the reference (not HR) only verifies employment, that's a negative review. They are concerned about liability. If it was a good employee, the references have no qualms about saying so; it's the negative aspects that carry legal liability.

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.


> References would be personal references - someone with a cell number and call the college he attended; they should also verify enrollment and completion.

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.


It certainly isn't perfect. You have to interview the reference a little too, not just "how was he?"


Most companies, period, will have a policy of only verifying dates of employment. They don't want to get sued from telling the truth about the candidate and costing him the job offer.


FWIW my FizzBuzz solution involves no 'for' loops, and in fact involves no control-flow keywords at all.


Haha, I'd love to see it if that's true. I love cool approaches to computation. FWIW as long as you can back it up with knowledge of what the relevant tradeoffs are (and don't scoff at a more KISS attitude for doing actual work), you're pretty much guaranteed to get a thumbs up from me if you give an answer off the beaten path.


I dislike traditional phone screens enough that I hone unusual solutions for them. And when they get evil enough, I put them in a public repository.

Here's my FizzBuzz:

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


How is that not iterating (admittedly within the stdlib methods)? They are not literally for loops, but the same concept of iteration.


That's awesome! I'd probably follow up that, since I generally interview for real time, firmware jobs, we try to clearly bound execution time, and therefore frown against more functional techniques like that. But you clearly know how to program well and would most likely get a thumbs up. : )


Admittedly most of my phone-screen solutions aren't tuned for performance; they're tuned to make people scratch their heads.

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


To me the problem usnt fizzbuzz, its “find all matching subtrees in a binary tree” in 45 min at a whiteboard.

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.


The problem with the BFS/DFS questions is that you're playing a forced game of knifey spoony: They expect you to write it in the recursive fashion and then try to stump you with "oh but how does that do on large structures?!" .. Stackoverflow. Then they'll try to force you to do tail recursion.


I agree, may be it’s just the places I’ve applied in the past but ive never been asked anything near as straightforward fizzbuz.


Said space shuttle firmware engineer probably never had to solve a pop-quiz problem on a whiteboard. It's much more likely that he/she deliberated for weeks about a simple change with the rest of their team, and perhaps even with the person/astronaut they might kill if the change had a bad bug.

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.


Developing software requires high level/architecture type decisions that you mention in your first paragraph. It also requires solving many small fizz-buzz size subtasks, which are necessary and demonstrate competency.

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


"It also requires solving many small fizz-buzz size subtasks"

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


> Said space shuttle firmware engineer probably never had to solve a pop-quiz problem on a whiteboard. It's much more likely that he/she deliberated for weeks about a simple change with the rest of their team, and perhaps even with the person/astronaut they might kill if the change had a bad bug.

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


The point I'm trying to make is that solving a fizz-buzz-like pop quiz on the board is a very different skill from sitting at a desk with internet access and collaborating with team members to solve an engineering problem, even if they reduce to fizz-buzz-like solutions. For this reason, the whiteboard pop-quizzes are not really useful in evaluating how well the candidate will perform on the job. I've worked with terrible team members that have aced their interviews / exams, and I've worked with amazing engineers who crashed and burned spectacularly in their interviews and do so regularly.

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.


That sounds to me like fight or flight response. Happens to me sometimes, and when it does I can’t code worth a damn, in spite of having a decade and a half of experience on the top projects at some of the top companies in the industry. This, in fact, happened to me the first time I interviewed with Google: I bombed that pretty spectacularly. The second time I applied I already had a couple of very generous offers elsewhere, so I didn’t care as much and was less nervous during my interviews, so I passed.


Hence the take home interview. At least at the last company I worked at we began doing these because we could tell that the stress was filtering out some otherwise decent candidates. At least that was one of the reasons, it also gave us a chance to talk about technical solutions the candidate produced in a more stress-free way.


So you decided to filter out good candidates in a new way; the take home test.


I don't think this assertion that the technical interview is inherently filtering out great candidates is being very honest (you responded similarly to another comment of mine the same way). One quality being tested is "can you try to do the thing that we're asking for?" That's a measurement in competence and the willingness to get something done. If said candidate is saying "this test is ridiculous and a waste of my time!" then my common sense instinct will say that they're probably not a great fit even if they're the greatest programmer in the world. At least on the take homes I've issued they shouldn't be taking more than a few hours. These stories about creating applications that take 3 days are certainly problems and recruiters need to lighten up a little, but I don't think the take home is inherently flawed just by its existence.


Most senior devs have a family, value work/life balance, and currently have another job. I don't expect them to take their work home past 5 while they're working with me, so why should I expect them to do that before I'm even paying them?


Finding a new job isn't part of your current job. It is over and above. If you aren't willing to put in a few hours after work for something not related to your job, why are you even bothering to go looking for a new job anyway? Are you job hunting on your current employer's time?


Almost too obvious solution: do an initial phone chat to filter qualified candidates into a small pool and then pay your final round of candidates a nice rate to complete a take home project. Bonus points if you can make it something that you can actually use at your company.


This is a terrible solution at many levels. Paying someone who isn't on your payroll (yet) needs a lot of bureacracy on both sides (e.g. taxes).

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.


I don't see how paying them for their time fixes the work/life balance and already have another job combo?


For one, a potential employee may find it worthwhile to take an unpaid personal day to complete the challenge of they are compensated.

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


The take home exam is quite a bit more of an efficient filter than a blanket phone screen. Anything less than a 20 minute call isn't going to tell me much.


Personally I think it'd be fine to e-mail back and say "sorry I don't have time to work on this with my current schedule, could I do an in-person interview instead?" That's me though, I would hope the rest of the industry is willing to work with people. Even just the response to the e-mail would tell me that they're competent enough to know their time management and that they have limited bandwidth. At some point you need to make a sacrifice of time though. Even if your hotel and plane ticket are being paid for to fly out to the place of business, you need to take that time off to go in for the interview.

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


> Personally I think it'd be fine to e-mail back and say "sorry I don't have time to work on this with my current schedule, could I do an in-person interview instead?"

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


Sure, but there's only so much responsibility one can take for this stuff. Presumably there are other candidates willing to respond.


>I don't think this assertion that the technical interview is inherently filtering out great candidates is being very honest

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.


at least the take home test is similiar to a real world issue. Tons of issues with it but it's better than the live code remotely (live coding on paper somehow clicks well for me)


Yeah, I’d vastly prefer that, but it should take no more than a couple of hours, not days. In fact we use a 1-hour take home to screen candidates, with great results. The assignment is pretty simple, but you can’t find a solution on the internet. We have found this to be way more effective than a phone screen (which we also do, to let the candidate also ask questions early on).


I take a small dose of a benzodiazepine before interviewing. It helps filter out the noise/stress to let me concentrate when I'm under the gun.


Agreed. I suffer from Generalized Anxiety Disorder, and the environment of the technical interview immediately throws me into a fight-or-flight state.

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.


When I interviewed at Google it was 2006 and they had a reputation for rejecting nearly everyone. I was still a student! So I rocked up to the interviews calm as calm could be because I didn't believe for even a second that I'd actually get the job and really, the whole thing seemed like an entertaining and potentially interesting mistake.

But I did get the job.

No expectations? No stress!


I did that with the google phone screen. It didn't help that the interview really took a "well that's interesting" approach and basically killed the interview.


Check your premise.

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.


Solving a problem within a fixed time period is the best real world scenario for programmers. No project has an unlimited budget, so no one gets unlimited time in the real world.


"Solving a problem within a fixed time period is the best real world scenario for programmers"

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.


"Plan to throw one away." This was one of the major thesis statements of The Mythical Man Month, by Fred Brooks. It's one of the hallmark texts on software development. I don't disagree with what you are saying - that we need to be cognizant of time and money - but there is a scary shift happening in software where more emphasis is put on time-to-market above all else, where we are boiling the frog of consumer expectations. Millions of people lose their personal financial information in a hack, and the entire population just shrugs their shoulders. I'm left wondering if this would be the case if we put less emphasis on continuous production deployment, and more on the care and quality of our processes and systems.


> Solving a problem within a fixed time period is the best real world scenario for programmers.

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


Lots of real world problems are troubleshooted in less than that time, under more pressure, and have far more variables to consider/are far more difficult, like build failures. The scenario here sounds like it's as relaxed and simple as you can get without it being so easy it tests nothing. Are you assuming the interviewer always yells like he's Sam Kinison?


> Lots of real world problems are troubleshooted in less than that time, under more pressure, and have far more variables to consider/are far more difficult, like build failures.

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.


> Yes, and they're troubleshooted by people who are already intimately familiar with the systems they're troubleshooting.

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?


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

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.


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

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.


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

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.


I was responding to the words I quoted from your post. I was not aware that somebody had already made the point that even apparently simple problems may not be 'familiar' to all candidates.


It doesn't have to be 'familiar'. A fair bit of the point is to judge your problem solving skills, not your memorization skills.


For sure. I never said all interview questions have to be 'familiar'. I'm not the same guy you were talking to earlier.


> Being asked to reverse a list in 15 minutes isn't even close to "writing an app from scratch".

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 also isn't even close to "solving a real-world problem".

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.


I worked with people who were hired with "can you do the job?" test and with people who were hired by "everything is wonderful, you are a special candidate that we just talk with" test.

The second group universally cannot perform under production pressure.


No projects are budgeted to 45 minutes. The real world scenario for such limited time is debugging in production issues. It is a completely different scenario. The people who jump in are mostly those who are familiar with the services or application that are showing issues, those who have a clear understand of the architecture of the company, those who have skills on their tech stacks and know where to look at and how to analyze, etc.


> It sounds to me that an assumption is being made because they didnt meet the expectations within a fixed time period.

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?


I realize that you’re doing the best that you know how given the time pressures you have as an interviewer. There is no perfect answer to this problem.

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


A lot of that's true or might be true, but how do we improve things?

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


I wasn’t referring to the in-office vs. take-home aspect, just the “stress test” nature of the white boarding test. (And I was admittedly unclear about that in my post and I’m sorry.)

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.


One thing I would say is just talk through problems with candidates as simple as that sounds. Try to grok how they think through software problems. Nothing mind-blowing there, but what I'm saying is how someone codes fizz-buzz tells very little...or to me this is like hiring a driver by taking them out to a parking lot and doing doughnuts. If you can fathom the idea that they can drive a car (at all) it seems like it is much more enlightening to hear about how they organize a schedule, clients they have picked up, problems they have solved...how they react and comment to situations you pose to them,etc. I guess the key here is to do this conversationally, and not like you're grilling them. Or you have to be a good question asker and a good listener..but if you are, or can become one, I 100% believe you can get the information you need in a humane and efficient manner. 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.


> One thing I would say is just talk through problems with candidates as simple as that sounds. Try to grok how they think through software problems. Nothing mind-blowing there, but what I'm saying is how someone codes fizz-buzz tells very little...or to me this is like hiring a driver by taking them out to a parking lot and doing doughnuts.

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.


For the most part, we can read someone's fizzbuzz solution easier than we can read people.


The amount of times I've heard interviewers go "Oh I had this super experienced guy who but in the interview he couldn't even do some simple programming problem". To me that is a failure in the interview process. I've seen this when I've interviewed people. If people don't do well when their resume implies that they should, I'll discuss it with them and say we want to get some kind of confidence in their abilities. Then work out a way to do that. This has worked out really well in my experience. I've ended up with devs who are quite different from me, one person of note (who we employed), was much slower at solving problems but far far more methodical and exhaustive in approaching problems and often notices very subtle details (which is a good thing in firmware development!).


The only way I could see that scenario could ever occur is if the candidate outright lied on his resume. A quick solution is to check references (call the school said person graduated from, call references, call references via their company line, etc).

Sounds like the interviewer didn't bother checking references.


The majority of shops that firmware devs come from (and particularly defense) have a policy of only verifying the dates of employment and nothing else.


References would be personal references - someone with a cell number and call the college he attended; they should also verify enrollment and completion. You don't want to be calling the HR department. Also, a secret is if the reference (not HR) only verifies employment, that's a negative review. They are concerned about liability. If it was a good employee, the references have no qualms about saying so; it's the negative aspects that carry legal liability. 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.


It's corporate policy with most of the companies in the field for any of their employees to not confirm more. And it's enforced. It's a defense thing.

College buddies will tell more lies than the candidate will.


In my experience, candidates who have experience in dev work but could not pass our interview tests always end up in a dev role somewhere else shortly afterwards. Even some of them go on to find much more success.

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.


We have to separate whether or not someone doesn't know how to do a job from whether someone doesn't know how to interview.

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.


Oh totally. Fizz Buzz shouldn't take you the whole 45 minutes, so the remainder is just a conversation where I dig down in their experience on a hunt for bullshit.


I think FizzBuzz is about as hard as I would make a technical interview. Maybe some basic questions about database design; what's an index; what's an array, etc. The dig down and hunt for bullshit is the most effective way for a tech person to interview another tech person in my opinion.


This is always my approach too. Pick a few elementary questions about a technology and ask a developer how to do them. Simple stuff, like how to build an array with integers 0-5, or iterate over a map.


I agree w/ you here. And I think a lot of people have some personal experiences encountering this kind of situation. It seems baffling, right?

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.


Brain freeze under interview conditions? One thing that I have noticed is that taking in an interview seems to engage a different part of your mind from coding. I get quite into the flow of chatting, then have to jump into code. Its quite a context switch.

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.


Off the top of my head the space shuttle firmware was written by a team that adherred to a very systemic process to ensure it met the spec/reduce the number of bugs, it was often cited in old software engineering papers/books in the time period as the best organization in the world, IIRC in terms of software engineering measurements like defects per lines of code. It would be important to know if someone came from that at the beginning of the space shuttle program when they were creating the standards for work, starting out or if they came on later after the process had been perfected.

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.


I avoid doing interviews, but I've suggested fizz buzz a few times to people I've worked with because it's so simple but once outside the environment of your usual IDE seems surprisingly simple to screw up.

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.


" Why they didn't just tell me what attribute they were after I'll never know"

Number of seats?


Possibly. Ha.


Which may have proven nothing more than this person was too nervous to function.


[flagged]


Historically, and if we're talking about someone with 30 years programming experience, this history is very relevant - programming has been a popular field for smart but antisocial/unsocialized nerds who had very few if any friends growing up and have spent much of their life alone at a computer.

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.


But what if you're looking to hire people who go outside sometimes and can talk to people and can write code too? Or should that be illegal?


It's not like you forego the in-person interview and don't learn what you can from that. The point is, by including a take-home portion of the technical interview you can get a better sense of the individual's technical abilities.

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?


Not at all, I'm enjoying myself and the debate (while finding it kafkaesque that people are finding ways to defend failing fizzbuzz on an interview). How are you doing today? That might be the only legitimate point I've read in this chain so far - if you hire people too socially impaired to write fizzbuzz, they'll be less likely to job hop.


Now we're tacking on an additional aspect of the job that we didn't know about before. If the job requires a social interaction with people outside of the company then, of course, it becomes a factor. Let's not be silly in an effort to just be right and prove someone else wrong.


[flagged]


They should if they want those people, if not then don't. But if you don't, you shouldn't also complain there's a shortage of skilled people.


So hire everyone who can't function during the interview?


I know several really, really good programmers with pretty intense anxiety. Automatically ruling them out because of a poorly-formatted interview process would be a big mistake.


Could be like Richard Hendricks in Season1 huh?


What is working with them like?


I mean, they're people. I'm still close friends with a few of them, and I didn't like some of them. It's no different than working with anybody with a disability or an illness (or kids, or elderly parents, or any of the million other human things that can make you a less-than-full-functionality worker bot) - you make the necessary accommodations, work around issues when they arise, and live with it. Specifically, it involved toning down a bro-y, combative work environment (which was a change that I really appreciated).


I worked with a guy who had pretty bad autism and social issues. He was a great guy to work with, incredibly smart and a really nice guy.

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.


[flagged]


You could extend your attitude to any sort of disability couldn't you. Why hire someone in a wheelchair, when there is someone who could walk up the stairs in half the time?


Can the person in the wheelchair code fizzbuzz in an interview?


"Can they code it on the job" is the relevant question.

aje403 10 months ago [flagged]

You can take the guy who starts frothing at the mouth when you ask him to code fizzbuzz, I’ll take the wheelchair guy who can code fizzbuzz during the interview. Deal?


When did anyone start frothing at the mouth?


Does it bother you that you don't know the answer?


[flagged]


Communicating in the office is quite different than communicating in an interview setting.


In your head and the head of those with extreme anxiety it is quite different. You're meet people who might be nice or not and chat a bit, you answer some questions, maybe there's a free lunch involved, you either get a job offer or you don't and you continue your search, and your life continues on without the sky collapsing


You could say that for almost any job, but somehow you don't see the same hyperbolic whinging in all of those fields, do you? And your claim isn't even true. It's very similar to the kind of code discussion you might have on the job. "How would you solve this?" "What if I try X, Y, and Z?"


This whole thing reminds me of a shitty superhero spoof movie from the 90’s - Mystery Men - one of the characters’ superpower is that he can turn invisible when nobody else is looking and he is naked


Not if you can find others who are just as good. And what's your better suggestion for filtering out people who can't code and not filtering out the good ones with anxiety?


Take-home tests. Lower-stress environments for coding tests - working on their own hardware, working remotely, no panel interviews, no actively combative/aggressive interviews. Also, cool aspect of that: all of these options will make the interview process more appealing for everyone. 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.


> Take-home tests.

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.


I've participated in a lot of interviews on both sides of the process.

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 can't believe I just read this.

I hope to never work with you.


Thanks for adding nothing here. I'm glad I'll never have to work with you, too.


I think you should consider that most interviewees expect to be asked any question from their entire work history which doesn't leave much room for anything else. It's probably worth separating the problem-solving interview and the techno-archaeological trivia game into separate days.


How did he do the firmware of the space shuttle without knowing such basic coding?


I think he probably didn't really, he was just dead weight on his team.


The hiring process is a response to the fact that employers cannot trust a single word candidates say about their experience. This isn't paranoia. Literally, most candidates we see cannot code, even when they supposed have a decade or more of industry experience.

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


Others have definitely mentioned this experience. For me, I have encountered this very rarely. More common, IME, has been people who seem like they have a TON of deep experience in something but then, when pressed or inquired, only have shallow experience. So, in short, I don't run into people who claim to code but can't as often as I do people who can code at least a little bit but quickly are unable to deal with more complex technical problems, or more expansive knowledge of the language they prefer or use most.


I'm in that group you interviewed. Didn't know what perm-gen is although I've seen it in errors when java used up all memory. Next question was about Hibernate's different caching levels.

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.


The hiring process is a response to the fact that employers cannot trust a single word candidates say about their experience. This isn't paranoia

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


I see on this board more than any other where people will agree that taking time to hire correctly is by and far more cost efficient than hiring quickly, but incorrectly. I've definitely gone through a lot of experiences now where someone looks like a rock star on paper, have a great cultural interview, and we don't give them a ton of technical exercises, only to find out that they can't hack it or, even worse, are dragging down the rest of the team. I really wanna trust people on this stuff, my instincts are to appeal to the greater good in people, but I've been burned enough to not trust it anymore.


The problem is that a lying liar will also have a resumé like yours. How can I — who have never met you, and have no-one I trust recommending you to me — differentiate between gaius the awesome developer and gaius-prime the lying liar? I've got to administer some sort of test to distinguish the two, and the likeliest sort seems to me to be one which attempts to discern whether one knows the sort of stuff gaius would know, and gaius-prime wouldn't.


Which makes asking for a resume, rather pointless. There would likely be a lot more acceptance of fizzbuzz take home tests and so on; if that was instead of writing up resumes (replace one time suck with another instead of adding a second one in). However that makes it hard to justify paying recruiters.

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)


>Which makes asking for a resume, rather pointless.

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?


I can tell within 10 minutes if someone is genuine or not just by talking through real, representative scenarios. If the job really involved implementing red-black trees from scratch, then and only then bring it up!


It's so funny, people who support that garbage just aren't hearing it. This forum probably has some of the best developers in the world chatting, and these guys just refuse to change their ways, regardless of how many people tell them it's a bad idea.


Spot on. It's rude to ask very basic questions to anyone with seniority.

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.


It's a bit rude but until senior-level-role-interviewing candidates can stop falling over on the basic questions why waste time with harder ones? The "candidate with an MS degree in CS and x years at SomeCo, can't do FizzBuzz" isn't a myth, it really happens to people giving interviews.

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


> "candidate with an MS degree in CS and x years at SomeCo, can't do FizzBuzz" isn't a myth

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.


If you can't tell in a ten-minute casual conversation whether or not someone is grossly lying on their resume, you probably shouldn't be an interviewer.


They can: with FizzBuzz. That's the whole point.


No--a ten-minute conversation with no coding, not a pop-quiz.


That's not realistic. You and I are complete strangers; we can have a talk for 10 minutes where not a single word that comes out of my mouth is true and you'd be none the wiser.


If you are a programmer, you can tell; just ask them about their previous projects. Dig into their answers and ask follow up questions. What data structure did you use to do this part? What in the database was designed poorly and why? (Every database has a design issue).

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.


Exactly.


Well just fire the frauds.

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


Onboarding an employee is a huge time suck, and constantly hiring and firing people doesn’t create a great environment for existing employees.


Yes but you can tell the difference without a whiteboard or take home test, right?


I think so, I personally prefer the "look at this already written code, what does it do and can we find any bugs or issues?", less stressful and more collaborative, but good luck getting any non-startup size company to let you do it.


I do something reasonably similar all the time at Google for iOS interviews, few hundred lines of obj-c with some issues in them (actual issues, not typos)


I think this is an excellent idea. Most of your job will be working on already existing code (even if it's written by your former self).


As someone who does a lot of interviewing, I tone down the technical stuff as the experience and responsibility level increases. I think a lot of the annoyances you mention still make sense for an entry level position, because there are a lot of folks who actually can't write code who apply for those jobs.

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.


I have a PhD in Computer Science and 10 years in the industry, and I've never not been asked to do some trivial programming task in an interview. Thanks for showing some common sense, but most interviewers are just lazy. One time I couldn't implement a skiplist, and the feedback I got was "we were concerned about your problem solving skills".


Even recently, I've gone to job interview type situations and the interviewer has literally asked me "Do you understand what Object Oriented Programming is? Can you write good quality Object Oriented code?"

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.


I was exposed to this essay really early on in my career and it completely changed how I thought about programming. Thank you so much for writing that; I still link people to it today.


Thanks for this, I added this essay to my reading list. Breaking people out of the OOP worldview is currently one of my biggest professional challenges.


Maybe it is your essay why he asked you if you understand OOP.


That would be easily countered with "So... I read your essay and it intrigued me. As a baseline, to understand where you're coming from... can you...?"


As it should have been. The fact that you have a PhD means nothing to Google, Facebook, and the like (except possibly a slightly higher base salary than a new grad w/ only a BS)

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


I didn't have to answer any hackneyed technical questions or take any tests to get a job. The most technical thing I did was explain how a data structure I wrote works, which came up naturally in a conversation about what kind of programming I have done.

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.


Google does not hire people by simply assuming the candidate can code. You do not get the benefit of the doubt, and in fact, you must prove otherwise. They want to see you write code on the whiteboard and solve the technical challenge given.


And as we all plainly know: what Google does is what we all should do. That's probably the one company that's never done something unnecessary or wasteful.


Me and my colleagues never asked this trivial question when interviewing for Amazon, just like you don't ask a driver what a brake is.


I assumed OP was referring to white board coding questions when he said "trivial programming task", which Amazon indeed does ask you to do throughout the interview process.


>One time I couldn't implement a skiplist, and the feedback I got was "we were concerned about your problem solving skills".

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.


>For candidates with many years of experience

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.


When I was younger, I, too, thought I knew everything and that the senior guys were full of it. As I grew professionally, I developed a degree of humility and EQ and understood how little I actually knew.


Sure. It's a common meme. It certainly happens. Consider though, that the fact that it happens sometimes means that genuine frauds are able to trot out this meme, as you have just done, and immediately dismiss the complaints of the junior.

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.


That's a fair criticism. The approach does need to require a finely tuned BS detector.


> For candidates with many years of experience, obviously they can and have been writing software effectively

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


I'm not sure its just the recruiting side. We're seeing some concerning positions in the market:

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)


I'll use this as an opportunity to vent about agile. It promises developers a larger voice, but in my experience, it heavily favors management and product management types, since they are usually the ones in control of the ticketing/tracking systems. They aren't under the sprint deadlines that developers are, so they are able to better organize and build their cases for what gets done. Even if developers can build a case, it often gets sent to the bottom of the backlog. Developers are forced to take on technical debt due to the short-term product oriented thinking. Is this because of the design of agile, or just the misapplication? Considering it's a cargo-cult management technique, I think it is part of the design.

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.


The deadlines are completely unrealistic because they are so divorced from the actual planning and design of the feature being delivered.


My favorite is when I take the time to break something management puts tasks 4, 6, and 10 into the sprint because the hours fit. Disregarding any dependencies or natural order.


Yes, that happens to me often.


I think the real problem is that we, as a society, have lost the ability to manage. Agile being associated with these problems is a symptom, not the cause. It won't fix bad developers and it won't fix bad management. But if the developers and management are good, then it can work fine.


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

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.


How many days of vacation per year does the average employee take?

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


6 weeks is not standard in the US. I'm used to seeing 15 days of flexible pto/sick time and 6 holidays. Also, due to how the pto time would accumulate per each pay period, it can take many months to save up a whole week. I'm much happier with unlimited pto, as I now take 4-5 weeks spread out however I prefer.


> 6 weeks is not standard in the US.

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.


The number of holidays is always written in the contract. A company would never write that you have unlimited holidays, that's just plain stupid.

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


The legal minimum in most of the US is 0 days, right?


You'd need to check with your local jurisdiction. I highly doubt that it is zero.


Which in your case is nice. But you never know when it's going to end, or they're going to start evaluating you on how much vacation you take.


Technically it's scrum that causes that, not Agile. Scrum is a way for people to make money off Agile via consulting. Srcum is rigid, Agile is the opposite.


This discussion takes me way back - it reminds me of people in the Eastern Bloc talking about communism. A widespread meme was that communism was allegedly good "in theory", it was just the practice that somehow got derailed.


> So maybe the person shares actual code and walks us through it that they wrote, even if not open source? Again, we can't know for certain it is their own code and not some friend who wrote it for them 2 years ago that they claim is their own. Or was a teammate's, or what-have-you. So we can't count on that either.

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 remember working with someone like that. He went on to be an amazing salesperson.


Our vigorous interview culture also allows us to not be as credentialist & elitist about what school you've went to. As a result, someone can get a job a google without having to have gone to a top ten comp sci school, like you would have to with law or business.


Yea I was trying to think of a way of putting this that didn't sound too trite, but I think you've nailed it. This process is decent way to combat nepotism or BS'ing your way up. There's a bit of elitism to "if you can't hack the technical interview, you can't hack the job", but this is why some of these alternate ideas have been tried like the take home exam.


Supporting anecdote: Awhile ago I interned at Google and my engineering manager - who was quite high level - did not have a high school degree.


I'm confused. On the one hand you say that the hiring practices are obnoxious, but then you agree that the only way to verify someone can code is to have them "actually pump out some code".

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.


Let me play devil's advocate for a second. Knowing how to write code isn't binary, of course; there's a wide range of skill even among those who have contributed to large production systems. If I hire someone who seems great on paper and turns out to be a dud, then I immediately let them go. It's bad for me, and bad for them. If a 10 hour project-specific coding task reduces mis-hires by 50%+, isn't it better for both parties?

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.


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

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.


I cannot agree enough. I'm okay with most of the interviewing practices out there, but there has to be some kind of balance between the company's needs and mine.

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.


It sounds like their signalling on culture achieved the right thing for everyone involved. I wouldn’t want to go anywhere near that company.


"anyone can nominate anyone else to be fired because "they don't belong there""

Wow. Reality show style office management, anyone?


Wow, there are so many red flags there. You made the right decision to drop out.


Interviews should be an hour tops on site and 30 mins tops on the phone.


>If I hire someone who seems great on paper and turns out to be a dud, then I immediately let them go.

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.


I've hired about 50 full-time w2 on-site developers over the last decade and maybe 3 or 4 of them were total duds (due to extreme mis-representation of technical skills) once employed. I'm not sure how this ratio compares to others but it certainly seems to be an issue that the industry talks about, so I'd be surprised if it were ultra rare.

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


That's pretty good, I know people who've had worse results.

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.


I agree with your approach. As a junior developer I got my big break by agreeing to join as an hourly contractor while I proved myself, with the hope of being brought on full time should my performance be sufficient. Lucky for me, the company was not lying and they brought me on and the rest is history. We all have heard those horror stories about companies who claim to do the contract-to-hire thing but have no intention to make good on the promise, so this is a risky path for the candidate.


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

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.


> Our industry's hiring practices are absolutely obnoxious. In an ideal world, you could trust someone's resume.

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


> Not to belittle anyone but...a plumber is licensed. An electrician is licensed. Even a hair stylist is licensed.

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.


Fizzbuzz and other interview coding tests are being used to test minimal competence. If a license proves minimal competence it solves this particular problem. Sure, the licensed may be shitty at their job but at least they can do the job.


I highly doubt "Our industry's hiring practices are absolutely obnoxious" refers to tests of basic competence.


So because some licenses don't have ongoing re-certification requirements, that means all license are bad? Couldn't it just be that a "programming license" has regular testing and re-certification?

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.


> So because some licenses don't have ongoing re-certification requirements, that means all license are bad?

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.


>Why do you think a programming one would?

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


Yes. The point was other professions have a "process", and many of them have real (publuc) health related impact.

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?


Indeed: you can become a "licensed dietitian" in a day or two.


Is that true? Wikipedia says (at least in the USA) you need 1200 hours of supervised and practical experience and you have to have a bachelor's degree. Following their source link, it looks like you have to apply for the licensing test 12 months before actually taking it, too.

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.


And yet you see plenty of people that don't give any weight to certifications, and clearly just about no one sees a degree as any sort of indicator, beyond a simple line item that must exist for HR to pass the resume along.

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


> Not to belittle anyone but...a plumber is licensed. An electrician is licensed. Even a hair stylist is licensed.

How often do you hire some one based on certificates?


Um. Does today matter? This is simply an idea for going forward. Doing nothing is not an option. Is it?


You can tell if someone knows what they are doing by talking to them and having them walk you through what they have worked on.

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.


You really can't. There are some people who have a skill for talking about what they've seen others do, and for memorizing what others said. If that person has sat in a post-mortem for some failure, they'll be able to tell you all the things that went wrong, how "they" fixed them, and why. And yet they can't code.

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.


Well, in that case, what you definitely want to do is optimize your entire interview process around the 1% of people who can pull this off, instead of just firing them when they can't execute on the job.


>it's probably much cheaper and more efficient to hire faster and fire faster.

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


Firing duds is the best moral booster there is.

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.


I agree with you, but in reality, a large enough company could face (and lose) a wrongful termination lawsuit if they do this too often. The burden of proof for this is surprisingly low and engineering pays well enough that many of them can afford good lawyers.

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.


>Firing duds is the best moral booster there is.

The Glassdoor reviews on Netflix suggest otherwise.


Couple days ago I watched youtube and stumbled onto airline pilot channel. Every company does extensive tests, psychological and technical and most of time simulator flight even if you had thousands hours under your belt. They can kick you out of interview because you are not dressed well enough, like wrong tie to wrong shirt...

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


I think if they can talk you through some code its more relevant than if it was written by them or not. Maintenance of other peoples code is usually more difficult than understanding what you wrote yourself.

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.


"Maintenance of other peoples code is usually more difficult than understanding what you wrote yourself."

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


I'm a lot more minamalist about comments, documentation, and unit tests with personal projects at home than I am at work. The stuff I work on at home are for my own enjoyment, and usually the projects are small enough and my time to work on them short enough that I don't put extra time making sure everything is ironclad. Good descriptive function and variable names and decent structure is about all you can expect with that code.


> Yet, we do. Ok, then what about open source contributions (if they have them)? Well, sure, but we don't really know, for sure, if that code is their own or if they indeed truly wrote it, can we? So we can't count on it. It helps but it can't be an automatic "this person passes the technical" signaler.

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.


The reason we have to do is that you will find time and again that despite having a good resume and even interviewing well, that you will find that you've hired a person who literally has no idea what he's doing. I've seen it too many times to ignore.

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.


I used to work as a chef, and the problems really aren't that different. People describe their experience on a resume but knowing whether the guy will be able to do their prep efficiently etc is just impossible without seeing them work.

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.


In other professions like law or medicine there's a professional organization that requires members to take a difficult test to become certified to practice. In those fields nobody with 20 years of experience is asked if they can FizzBuzz on an interview. I wish we could get the algorithm whiteboarding out of the way one time after graduation and then have every company trust in the certification from then on and instead focus on experience and real-world skills.


I'm curious if theres an industry that you think has figured out hiring, at least from a lying on resume standpoint I'm not sure which that would be.


> Apart from getting a candidate to actually pump out some code, even trivially, we don't really have a way to de-facto verify that the person says they can do what they say they can do, short of a personal reference from someone, say, in the company already that knows and has worked with the person in the past.

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


True, yes. Although in this case, I am referring to perhaps a software engineer (who you already know to be good since he is there and in the company and on the team) who would personally vouch for someone else's skills. At least in a case like that, I have trust that their vouching for someone else is legit.

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


I've hired and it is astounding the number of people with CS degrees and years of experience that can barely program. Until there is some sort of professional IT association like the BAR for lawyers this type of treatment will continue.

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.


And the number of coding schools that have popped up in the recent years and the fact that every econ major and their mom is trying to become a developer now isn't helping either.


You greatly underestimate the mapping of a law license to competency.


>Well, sure, but we don't really know, for sure, if that code is their own or if they indeed truly wrote it, can we?

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?


So hire someone on a probation, and give them the boot if they don't live up to expectations in the first weeks?


That's the answer, and lots of companies do it. If you're going to fire, fire quickly. One problem with that is the high cost of onboarding, which is (IMO) caused by HR making their own job security by pushing for long hiring processes. If you just spent 3 months searching for candidates and getting them at a desk, you don't want to spend another 3 months if that didn't work out. So you have to cut your hiring lead time to a more reasonable level first.


What would you prefer? Some sort of rating or ranking system based off of objective standards?


An informal network of trust (which in fact already exists, it's just that many companies and many engineers don't use it), i.e. personal references, referrals, open source contributions, a project portfolio.

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


And then people that aren't part of that network of trust (like minorities or women) can't get work.


And likewise, we get cliques of bullshit artists. Literally this guy just proposed "It's not what you know, its who you know" as the solution.


No, he didn’t. I said ‘network of trust’, not ‘cronyism’.

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


Fuck that would be awful.

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.


Twitter and blogs would be an excellent approach for hiring marketers/growth hackers


Being trusted by your peers is different from trying to win shallow popularity contests.

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 people did previous work, you should look at it. There's a way to do that. Now, if you can't because of the industry's propensity for using the law to hide information, then it seems that may be the cause of the industry's inability to find relevant information about potential employees.


Number of Twitter followers is now an indication of third party trust?


For the software industry ( for other industries or use cases that might certainly be different) I think it is. It’s just one possible indicator but an indicator it is.

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


More realistically, a somewhat large number (>1000) says to me "this person spends time and energy on self-promotion". Some of the smartest people I know have Twitter accounts with just 100-300 followers because they don't aggressively blog or anything.


Bingo. You end up becoming like all the other industries dominated by white men at positions of power (Law e.g.)


Even if that were the case, which I don’t think it is because the underlying problem is something else, the current predominant interviewing process does little to alleviate that problem as well.

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


Actually there are historical examples of where changing the interviewing process solved inequality. All it took was a curtain. You see there where few women in orchestras and it was said that this was because they didn't have the talent so couldn't get expirence, rather than being unable to get expirence due to prejudice. Then blind auditions started, interviewers would sit in front of a curtain, candidate would come in behind and play their music. Suddenly when the interviews could only judge on performance the same women that they said didn't have the talent where the ones they were choosing and that inequality was fixed. Now there might not work if the underlying cause is something else but it has worked.


It is great that it worked for musicians but I was surprised that it doesn’t necessarily work for resumes.

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


That’s whataboutism.

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.


That's not whataboutism, that's valid criticism of a flaw in your idea.

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


Well, perhaps. I don't want to suggest "licensing" because that's kind of a naughty word around here but man, it sure would be nice if something like that could take the extreme repetition and time wasting of "technical screens" out of the interview process completely.


The problem is that the license test can be gamed just like the technical interviews they are designed to replace.


licensing might not be a bad route, similar to a carpenter's license or a bar exam


Licensing probably could work in this industry but it would be a tough nut to implement. For starters, as others have mentioned, with so much change happening, re-licensing would probably be needed, and of course that's a huge cost, a pain, and overhead as well. But then again, as I think about potential solutions, I am kind of coming up dry. Really need to mull on this some more.


It can just be a general aptitude test done in several popular languages of your choice with some level of customization based on what sort of programmer you want to be.


For all the change that happens, though, the fundamentals are still the same.


plenty of garbage lawyers passing bar exams, and law firms don't just check that you've passed the bar and hire you.


So, like certifications? Last I heard those are frowned upon in our industry.


Only because they are too easy, or for profit, or focused on using a given product or unimportant concepts.


We won't get an agreement about the scope of the certification or even what answers are right. Too much change, too much opinions, too little rigor/science.


the article itself mentions a solution which isn't terrible, it's just the issue is a matter of trust


I'm sure there's a blockchain solution out there somewhere (half-joking)


>I'm sure there's a blockchain solution out there somewhere

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.


Most programming happens in a team environment. It can be difficult to separate the impact of a good programmer from a substandard programmer in a good team.

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.


>It can be difficult to separate the impact of a good programmer from a substandard programmer in a good team.

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.


> Apart from getting a candidate to actually pump out some code, even trivially, we don't really have a way to de-facto verify that the person says they can do what they say they can do, short of a personal reference from someone, say, in the company already that knows and has worked with the person in the past.

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


How do salespeople get interviewed? If one claims "I sold X million dollars worth of widgets more than the rest of the sales staff combined" I doubt you'd be able to confirm that easily.

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


If it's anything like white boarding, then they would bring in a game of operation and have the surgeons pull out all the pieces. If the buzzer goes off, well they just aren't good surgeons.


Very apt. But I'd really like to know why a medical degree means "can perform real medical work" while we're OK with a CS degree meaning "well, she has successfully completed the degree requirements, but hey, actual software development is not part of it".


Surgeons do different things.

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.


Unless things have changed drastically in the last 20+ years, CS degrees involve plenty of software development. I remember having to build a calculator in Pascal using queues in CS1. We'd have to code all the classic algorithms (Merge sorts, traveling salesman, shortest path, etc).


I much rather have homework tests than intensive, arbitrary and stress producing full day interviews.

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.


Why not to have a 1 hour technical conversation and figure out if the person knows what you are talking about? Talk about data structures/algorithms/design patterns/OOP 10 minutes for each, plus language specific points if you want and it should be enough.


Because its a good practice in this industry to get rid of sub-par employees as potato-torpedos for the comeptition to hire- by praising them in the highest register?


How does it work for other jobs? How do you trust a painter or a plumber? How do you proove that his/her work was good and can do it?


> we don't really have a way to de-facto verify that the person can do what they say they can do

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.


Scenario: you have two offers on hand. One offer is for a full time position. The other is for "let's see how the next one to two months goes and then we'll decide if you still have a job or not." Which do you pick? All things being equal, the first offer carries significantly less risk as an employee and is clearly the better choice. If you're an employer who really wants to hire engineers, why would you give an offer that will automatically filter out a large portion of qualified candidates?


If I had the choice between a full time position with 3 days free coding prior, or "let's see how the next 1-2 months go" with no free prior coding, I'd chose the latter.


Those options both suck; I'd turn them both down. There are plenty of other places to work that will treat you like a professional.


But the reality is in many (most? all?) US states, employers can fire you for any reason. Sure you can nominally fire back with a wrongful termination suit, but the reality is you have little recourse. So really there is no difference in those two offers, other than one is being more explicit about their personnel practices.


What do I do when I quit my current job, move across the country, and then get fired 30 days later? I would likely never accept an offer at a company that tells me up front there is a good chance I will be let go in 30 or 60 days.


There is only a good chance if you misrepresented your abilities and aren't able to get up to speed in 30-90 days. If that is the case, you deserve to be let go.


Is it, though? There are so many other ways that someone might not be a good "fit." Maybe you found another, slightly better candidate who is willing to accept a lower offer. Maybe a manager or individual contributor feels that their position is threatened by the candidate. Maybe they don't attend weekly happy hour.


I can’t imagine firing a competent employee for any of those reasons. Hiring (and firing) an employee involves a lot of work and is a big onvestment. You don’t throw that all away to roll the dice on someone who might be incrementally better.


Yes but being a FTE doesn't shield you from that sort of thing either.


You run that risk with any assignment that's at will, whether it's explicitly stated or not.


The size of the chances varies wildly.

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.


Bingo. This is how it was done before. 30 minute interview with some quick test questions (what's an array or linked list or what does ++ do), then if it sounded good, hire them. If they didn't work out, fire them. Simple and effective.


Of course I don't disagree. So true. I meant in the context of the interview / hiring process, short of hiring them on and thinking about it through the lens of a probationary period.


Are programmers more dishonest than say artists? I imagine an artist could easily fake their portfolio too (especially if they were a digital artist). Maybe the artist would be found out much easier than a programmer. I think the fact that programmers have to re-prove themselves is more a symptom of non-technical people having no earthly idea of what it is that programmers actually do. For a programmer, its the same with other professions. Programmers can't differentiate between the skill levels required to perform a protein assay in a BSL-2 facility, to operate a fermentor in a class 10 facility, to work on tissue culture vaccines. However most people can somewhat differentiate between a nurse, a doctor, and a surgeon. Seems like the more specialized your skill, the less ordinary people can appreciate your skills.


I personally know a designer that had an applicant try to pass off _his_ work as her own.


You are 100% right. In design work roles, people like to look at and review people's portfolios. They do it all the time. I suppose that maybe at least in that case, it's easier to verify that their work is their own? I don't know. I definitely do not think that programmers are any more or any less dishonest than most other professions.


I had the same question about how photography differs and received a pretty thorough reply:

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

More

Applications are open for YC Summer 2019

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

Search: