22 ms·

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

by speby 9y ago

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.

pwthornton 8y ago
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.
- lowbloodsugar 8y ago
  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.
  - mratzloff 8y ago
    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.
- deleted 8y ago
  [deleted]
- BeetleB 8y ago
  >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.
  - pnw_hazor 8y ago
    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.
    - mywittyname 8y ago
      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.
monksy 8y ago
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)
- gnarcoregrizz 8y ago
  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.
  - monksy 8y ago
    The deadlines are completely unrealistic because they are so divorced from the actual planning and design of the feature being delivered.
  - darrylb42 8y ago
    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.
colordrops 9y ago
What would you prefer? Some sort of rating or ranking system based off of objective standards?
- speby 8y ago
  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.
  - pathseeker 8y ago
    The problem is that the license test can be gamed just like the technical interviews they are designed to replace.
- mylons 9y ago
  licensing might not be a bad route, similar to a carpenter's license or a bar exam
  - cakebrewery 9y ago
    So, like certifications? Last I heard those are frowned upon in our industry.
    - eeZah7Ux 8y ago
      Only because they are too easy, or for profit, or focused on using a given product or unimportant concepts.
  - praptak 9y ago
    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.
  - sigstoat 9y ago
nugget 9y ago
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.
- majormajor 9y ago
  > 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.
  - CodeMage 8y ago
    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.
waylandsmithers 9y ago
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.
- monocasa 9y ago
  > 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.
- ModernMech 9y ago
  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".
  - lkrubner 8y ago
    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 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.
stupidcar 9y ago
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.
- speby 8y ago
  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.
  - profalseidol 8y ago
    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.
- Clubber 8y ago
  Yes but you can tell the difference without a whiteboard or take home test, right?
  - carlosdp 8y ago
    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.
monocasa 9y ago
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.
- speby 8y ago
  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.
  - collyw 8y ago
    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.
  - stevenwoo 8y ago
    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.
reaperducer 9y ago
> 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.
- teachrdan 9y ago
  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.
  - Clubber 8y ago
    >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.
    - carlosdp 8y ago
      Yea, they don't generally "go back to paper", they outsource overseas...
      - Clubber 8y ago
        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.
ams6110 9y ago
> 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.
- speby 8y ago
  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.
- Clubber 9y ago
  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.
- bearforcenine 8y ago
  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.
  - Clubber 8y ago
    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.
    - bearforcenine 8y ago
      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.
ksk 9y ago
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.
- travisjungroth 8y ago
  I personally know a designer that had an applicant try to pass off _his_ work as her own.
- speby 8y ago
  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.
- SilasX 8y ago
  I had the same question about how photography differs and received a pretty thorough reply: https://news.ycombinator.com/item?id=11878012 https://news.ycombinator.com/item?id=11878012
deviationblue 8y ago
> 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.
- speby 8y ago
  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.
crdoconnor 8y ago
>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?
tachudda 8y ago
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.
woolvalley 8y ago
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.
- seccess 8y ago
  Supporting anecdote: Awhile ago I interned at Google and my engineering manager - who was quite high level - did not have a high school degree.
- TheGRS 8y ago
  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.
lowbloodsugar 8y ago
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.
bsder 8y ago
> 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." :)
- ryandrake 8y ago
  I remember working with someone like that. He went on to be an amazing salesperson.
collyw 8y ago
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.
- ironchef 8y ago
  "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 ...
  - cableshaft 8y ago
    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.
chiefalchemist 8y ago
> 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. ;)
- vonmoltke 8y ago
  > 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.
  - tastyfreeze 8y ago
    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.
    - vonmoltke 8y ago
      I highly doubt "Our industry's hiring practices are absolutely obnoxious" refers to tests of basic competence.
vpmpaul 8y ago
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.
- toephu2 8y ago
  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.
- pnw_hazor 8y ago
  You greatly underestimate the mapping of a law license to competency.
underwater 8y ago
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.
- Clubber 8y ago
  >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.
wan23 8y ago
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.
Ntrails 8y ago
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.
bad_user 8y ago
> 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.
Arn_Thor 8y ago
So hire someone on a probation, and give them the boot if they don't live up to expectations in the first weeks?
- freehunter 8y ago
  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.
_pmf_ 8y ago
> 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?
- Clubber 8y ago
  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.
  - _pmf_ 8y ago
    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".
    - Clubber 8y ago
      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).
    - around_here 8y ago
      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.
- jonhendry18 8y ago
  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?
ozim 8y ago
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/ https://www.pprune.org/interviews-jobs-sponsorship-104/
kerberos84 8y ago
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.
ConceptJunkie 8y ago
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.
LifeLiverTransp 8y ago
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?
conanbatt 8y ago
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.
IloveHN84 8y ago
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?

by speby 9y ago

pwthornton 8y ago

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.

lowbloodsugar 8y ago
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.
- mratzloff 8y ago
  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.
deleted 8y ago
[deleted]
BeetleB 8y ago
>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.
- pnw_hazor 8y ago
  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.
  - mywittyname 8y ago
    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.

monksy 8y ago

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)

gnarcoregrizz 8y ago
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.
- monksy 8y ago
  The deadlines are completely unrealistic because they are so divorced from the actual planning and design of the feature being delivered.
- darrylb42 8y ago
  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.

colordrops 9y ago

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

speby 8y ago
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.
- pathseeker 8y ago
  The problem is that the license test can be gamed just like the technical interviews they are designed to replace.
mylons 9y ago
licensing might not be a bad route, similar to a carpenter's license or a bar exam
- cakebrewery 9y ago
  So, like certifications? Last I heard those are frowned upon in our industry.
  - eeZah7Ux 8y ago
    Only because they are too easy, or for profit, or focused on using a given product or unimportant concepts.
- praptak 9y ago
  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.
- sigstoat 9y ago

nugget 9y ago

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.

majormajor 9y ago
> 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.
- CodeMage 8y ago
  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.

waylandsmithers 9y ago

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.

monocasa 9y ago
> 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.
ModernMech 9y ago
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".
- lkrubner 8y ago
  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 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.

stupidcar 9y ago

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.

speby 8y ago
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.
- profalseidol 8y ago
  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.
Clubber 8y ago
Yes but you can tell the difference without a whiteboard or take home test, right?
- carlosdp 8y ago
  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.

monocasa 9y ago

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.

speby 8y ago
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.
- collyw 8y ago
  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.
- stevenwoo 8y ago
  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.

reaperducer 9y ago

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

teachrdan 9y ago
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.
- Clubber 8y ago
  >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.
  - carlosdp 8y ago
    Yea, they don't generally "go back to paper", they outsource overseas...
    - Clubber 8y ago
      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.

ams6110 9y ago

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

speby 8y ago
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.
Clubber 9y ago
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.
bearforcenine 8y ago
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.
- Clubber 8y ago
  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.
  - bearforcenine 8y ago
    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.

ksk 9y ago

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.

travisjungroth 8y ago
I personally know a designer that had an applicant try to pass off _his_ work as her own.
speby 8y ago
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.
SilasX 8y ago
I had the same question about how photography differs and received a pretty thorough reply: https://news.ycombinator.com/item?id=11878012 https://news.ycombinator.com/item?id=11878012

deviationblue 8y ago

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

speby 8y ago
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.

crdoconnor 8y ago

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

tachudda 8y ago

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.

woolvalley 8y ago

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.

seccess 8y ago
Supporting anecdote: Awhile ago I interned at Google and my engineering manager - who was quite high level - did not have a high school degree.
TheGRS 8y ago
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.

lowbloodsugar 8y ago

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.

bsder 8y ago

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

ryandrake 8y ago
I remember working with someone like that. He went on to be an amazing salesperson.

collyw 8y ago

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.

ironchef 8y ago
"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 ...
- cableshaft 8y ago
  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.

chiefalchemist 8y ago

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

vonmoltke 8y ago
> 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.
- tastyfreeze 8y ago
  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.
  - vonmoltke 8y ago
    I highly doubt "Our industry's hiring practices are absolutely obnoxious" refers to tests of basic competence.

vpmpaul 8y ago

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.

toephu2 8y ago
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.
pnw_hazor 8y ago
You greatly underestimate the mapping of a law license to competency.

underwater 8y ago

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.

Clubber 8y ago
>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.

wan23 8y ago

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.

Ntrails 8y ago

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.

bad_user 8y ago

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

Arn_Thor 8y ago

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

freehunter 8y ago
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.

_pmf_ 8y ago

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

Clubber 8y ago
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.
- _pmf_ 8y ago
  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".
  - Clubber 8y ago
    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).
  - around_here 8y ago
    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.
jonhendry18 8y ago
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?

ozim 8y ago

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/ https://www.pprune.org/interviews-jobs-sponsorship-104/

kerberos84 8y ago

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.

ConceptJunkie 8y ago

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.

LifeLiverTransp 8y ago

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?

conanbatt 8y ago

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.

IloveHN84 8y ago

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?