Hacker News new | past | comments | ask | show | jobs | submit login

I sometimes think there's a built in pomposity in the whole attitude of hiring, looking for someone "good enough to qualify." Instead, I like to think of it as, we are looking for someone to help us, someone who has different experience and knowledge, someone who could tell us how we can improve. Then instead of this adversarial situation of selecting a new ingroup member, it's a solicitation for assistance with a built in humility.



"...we are looking for someone to help us,..."

This is exactly what I look for when I interview for a new job. It's inclusive, shows humility and a willingness to learn through others' experience. Any other attitude belies an employer that's arrogant at best, and at worst nurtures a narcissistic blame culture.


Appreciate the humanization of both job candidates and employers inherent in the shift you advocate.

I have done a bit of hiring and it was very hard to walk the line between effective use of my time and being open to people with all kinds of experience. (It was a junior position and I talked to some very junior candidates.)

But it is always important to remember that there is a human being on both sides of the table.


Could you expand on how you ended up walking that line? Did you feel you wasted your time on under-qualified people? Did you end up hiring anyone who initially didn't seem like a textbook candidate? If so, how did they turn out?

The reason I ask is that I've always been nervous about applying for jobs when I don't have every skill listed on the ad.

The advice I've been given is usually something like "Apply anyway. The job advert is a wish list, not a minimum."

But I'm still terrified of an interviewer opening my CV and asking how the hell I slipped through the screening process. Or even worse, being too polite to be so blunt and awkwardly going through the motions of an interview.

It would be awesome to get the perspective of an interviewer.


Hi.

I definitely wasted time interviewing underqualified people. But I wasted time interviewing some overqualified people too (because of salary/location expectations that should have been communicated up front). Actually, all of interviewing feels like wasted time (you have this burning need, and you want to fill it yesterday, or better yet a month ago, and yet you have to go through this process and learn about all these strangers, while the building feels like it is on fire).

Note that I said feels like wasted time, not is wasted time. It's a bit like learning a new programming language--you end up going down lots of blind alleys before you find the way you really want to go.

(All we could afford was non textbook candidates, and out of 3 hires, 2 worked out.)

As far as walking the line, as I got more comfortable interviewing, I always worked off a rubric, and set things up so that I could ease out of a phone interview early if it was clear that they didn't live up to their resume. Ended up doing the same thing with the in person interviews as well. Definitely screened by resume.

> I've always been nervous about applying for jobs when I don't have every skill listed on the ad.

This is a hard problem because some institutions write wish lists in their job reqs, and some write hard and fast requirements. And you don't know before applying. (And sometimes the goal posts in the organization move when their "requirements" meet the labor market.)

Personally, I'd apply if you have half of the requirements and feel like you can speak to the way you learn.

If you're interested in the company, I'd also take the extra step and do some work around it, whether that's writing a pain letter ( http://www.forbes.com/sites/lizryan/2015/03/01/how-to-write-... ) or writing a simple client against someone's external API or creeping^Hscanning LinkedIn, Twitter and Github profiles and finding out about the team and company.

Good luck!


>But I wasted time interviewing some overqualified people too (because of salary/location expectations that should have been communicated up front).

Well that's your own fault as the job advertiser, and when I say "you", I mean almost all companies that advertise jobs. You almost never state the salaries to be paid, so tons of peoples' time gets wasted by pointless interviewing which gets followed up with insultingly low salary offers.

If you're a cheap-ass and want to pay a pathetic salary, you should state this in your job ad, so that non-deadwood people don't bother to apply to your job.

>This is a hard problem because some institutions write wish lists in their job reqs, and some write hard and fast requirements.

It's not that hard to tell the difference. When the word "required" is used, that sounds like a requirement to me. When a separate list is preceded by "nice to have", "plusses", etc., those are obviously skills that the company would like to have in a candidate, but are not hard-and-fast requirements. If the company is so stupid they can't write a simple job advertisement this way, and they use the word "requirements" or "required" when they really meant "nice to have", then they don't deserve any employees at all.


Why should the company lead with what they are willing to pay? Why is it on the company and not the possible employee? Why shouldn't every phone screen begin with the possible employee saying "this is my salary range" and politely exiting the call if the screener won't validate that the salary offered is within that range?

When I buy a car, the person selling the car sets the price. I can take it or leave it.

When I rent a house, the landlord sets the price. I can take it or leave it.

When I'm selling my labor as an employee, why am I not the person setting the price that the company takes or leaves?

I'll tell you why, because the first party to state a number in any negotiation is at a disadvantage, because the counter party suddenly has more information.

Now, there's a valid case that the employer/employee relationship is asymmetrical enough as it is (one employer -> many employees) that the company should give up that negotiating point, but if I ran a company, I'd want to justify that. (There's also a case to be made that, especially with knowledge work, the employee has an asymmetrical advantage because they know how hard they are working, and it's hard for the employer to know.)

That said, when I enter into a new engagement to sell my labor, aka an interview, I do my best to make sure they want to buy my time before I set a price. It's negotiation.

Edit: I love the parent comment even though we disagree, upvoted.


>Now, there's a valid case that the employer/employee relationship is asymmetrical enough as it is (one employer -> many employees) that the company should give up that negotiating point

That's exactly why I think the employer should give up that negotiating point.

The other reason is that employers are constantly whining about how they don't have enough engineers, can't find qualified people, etc., and then lobbying Congress to do something about it. Employees don't have this kind of political power.

Finally, I wouldn't mind if negotiation were simply eliminated with job salaries. You don't negotiate with the cashier at Walmart about how much you're going to pay for some vegetables or a TV. The price is the price, take it or leave it. It'd be better if everything were that way, so that consumers could compare things more accurately. There are many nations where the posted price is not the actual price, and haggling is expected and normal, even on something as mundane as groceries. Without exception, these nations are backwards and economic disasters. There's a reason for that.


There are many nations where the posted price is not the actual price, and haggling is expected and normal, even on something as mundane as groceries. Without exception, these nations are backwards and economic disasters. There's a reason for that

That's a big claim that you make very authoritatively. You should back it up, or change your wording to better express that you're making a hypothesis without much evidence.


Do you have any counterexamples? Haggling is very common in countries like India and various Middle Eastern countries. To say any of these countries have world-leading economies would be quite simply false. India's getting better, but it's basically adopting western culture.


Well as for some prominent examples haggling is considered bad form for small transactions in the nordic countries and they do kind of well. All the places I go to that have a culture of haggling seems to be way worse off.

I guess others can provide more data points that points in this direction but I'd also appreciate counterexamples.


You've identified a correlation.

What solipsism is objecting to ("big claim"/"hypothesis") is the statement "There's a reason for that", which implies that there's a causal relationship between the prevalence of haggling and countries being "backwards and economic disasters" (for which there's been no evidence provided).


Only the company knows how well they will be able to turn work into the money that they can use to pay the worker.

The candidate can show the ability to do whatever work the company may require, but if that work does not increase revenues in some way, it will not be able to keep the worker employed indefinitely. Obviously, there's a lot of room for speculation here.

The worker has a general idea of the average amount that many other companies might expect to value the work of similar workers. So the prospective employer has to signal that it can monetize the work more effectively than the median company to attract better than the median quality of candidate.

If your company is building yet another CRUD business app, you do not need above-median skills, nor could you afford them. If your company is building a new, Wall-Street-killing trading platform, you need the 99th percentile of skilled workers, and should therefore be offering 99th percentile pay, because the work will eventually be worth billions of dollars.

The candidate knows how much their labor is worth on the open market. If the prospective employer does not know how much the open position's work will be worth to the company, it really shouldn't be trying to fill it until it does know. If you want to reach the higher-quality candidates, you have to send a clear signal that they will not be rejected for wanting too much money, which happens all too often with companies that need to pinch their pennies or extend their runway.

There are companies out there that will hang up the phone if you say $100k. And there are also companies out there that will struggle to hold their poker face at being offered such a great discount on an employee. You won't necessarily be able to determine which is which before you apply.

When the company does not say up front, it is implicitly saying "we will pay you exactly what you are worth, as determined by negotiation, with no predetermined limits." If they wait until halfway through the second phone screen to bring it up, and then say, "that's more than we can pay", they are wasting the candidates' time.

That is why the company should lead with their salary maximum.

The analogy is not a fixed price on fungible goods in commerce. The candidate has a unique artwork, to be sold at auction. The auction house would very much like to establish that potential bidders have at least enough money on hand to meet the prospective employee's reserve price before giving any of them paddles, especially when the bidding procedure can last several weeks per bid. The candidate does not want the reserve to be known, as they would prefer to get a higher price. Likewise, the prospective employers do not want their maximum bids to be known to their competition. But as they can only complete the purchase by making the highest bid anyway, their wishes do not matter one little bit. You have no business bidding on a Van Gogh painting with only $5k in your pocket, looking for something nice to hang up in a hotel room.

The employer is the one that makes the offer. They are selling the pile of cash, and the employee either buys it with their labor, or leaves the offer on the table.


Actual salaries don't correlate to ability nearly as closely as you imply.


Salaries are often just a function of negotiating skill.


Are you the Grishnakh from RoD?


I have no idea what "RoD" is.

I'm the Grishnakh who used to be an orc captain but was stepped on by an Ent.


Don't let the downvotes get to you. You're right on.


You must be a joy to interview.


Actually, this is exactly the type of person I like to interview. One that's already thought ahead and read the posting and decided if it was even close to a fit lifestyle-wise for them, and technically.


Thank you. When I look for a job, I'm not looking for the very top salary (usually those go to the very top performers, which I'm not, I'm good but not top 1%, or are companies which expect too much time), but there are a good number of companies out there trying to get good people for bottom-of-the-barrel salaries. I don't want to waste my time on those places. They usually have other big problems in addition to poor pay too.

Honestly, I wish every job posting included the following: - salary range (and an honest one too, not one where they post a mediocre low and a great high, but then never actually offer the high number to anyone and just offer the low number by default) - work location - sometimes it's not that easy to figure out where a company's office is located, or they have multiple locations. The address is important, because it determines my commute time. - office environment - is it open-plan, cubicles, offices, shared offices, etc. Some photos would be good. - computing environment - do you use Windows (7, 8, 10), MacOSX, Linux (Debian, Ubuntu, RHEL, etc.)? A combination? (RH in a VM for development, Windows for email/Office). What version control do you use? (git, SVN, or (ugh) ClearCase) - standard benefits package: insurance company and regular single-guy premium, number of days off/year, etc. - a fairly detailed explanation of the actual work involved in this position: what technologies you'll likely use, what the project is, etc. - number of people in team, how team works together (Scrum/Agile, waterfall, etc.)

If companies would just post all this info with their job requisitions, it'd save everyone a lot of time. I see posting filled with paragraphs and paragraphs of flowery crap about how wonderful their "collaborative team environment" is or their corporate philosophy or whatever, but the things I listed above are what are important to me in a job and what will determine if I'm happy in that job. Spare me the flowery prose about how wonderful your company is; I'll make that determination on my own.


I interview tons of candidates. The resume tells me nearly nothing, just what you've worked on before. Not how much, out how well that went. So in terms of some "textbook" model fit, the question is a little silly.

Generally few people are really good. And their spread out unpredictably across the landscape, so you have to just interview lots of people to find them.


Well, and I always make sure to run a quick Voight-Kampff just to screen out the replicants before the real interview.


That approach makes a lot of sense to me. If you can actually manage people, filtering for "not dumb" is usually sufficient to get the desired result.

Most companies demonstrate this with H1 contractor hiring. They usually don't bother with the cool kids club screening in those situations. One of the smartest people I ever worked with had a degree in Chemical Engineering from some mid-tier university in India that I never heard of. That guy would never get hired as a FTE at that company, because he didn't drink and didn't have the cultural "fit" nonsense.


> I sometimes think there's a built in pomposity in the whole attitude of hiring...

Of course there is. At a basic level, that's what hiring is.

With this now-popular attitude that "1 bad hire is worse then 100 good ones" or something like that, how could it be anything else?

Imagine the pressure that puts on the hiring teams.


    > "1 bad hire is worse then 100 good ones"
I don't think that's quite right!

(Or at least, it's so obviously right that it can't possibly be the "now-popular attitude" you mean.)


I think cubano is referring to the mindset that "it's better to skip over 100 good people than to hire one bad apple" which is very silly but a common attitude in certain kinds of organisation.


It really depends on what 1 bad apple is, that it is someone that is not the most productive but is still productive and don't completely harm whatever they work is seems too much but often that is the meaning in use.


I've had this problem when it's time to adjust headcount (smaller, or trying to swap people out to get more done).

I'll keep the Eeyore person that self selects tasks and issues that are of low complexity (say, 2 on a 5 scale) than the self confident idiot who keeps asking for 4/5 stories when they're really only good at 3/5 on a good day.

That jerk is creating 5/5 stories that I have to burn myself out on (they are either notably quiet or loudly in denial when this happens). I don't care how much project management or the marketing guys like him, even an empty desk would be better. At least an empty desk is predictable.


Ah, I see, sort of "1 bad hire is worse than 100 good ones can make up for".


There is not a hiring team out there that even bats 90% let alone 99. The problem is that they significantly hinder their ability to get stuff done when they spend too much of their time in vetting/hiring mode. I've been there and it's no fun at all.


But this is required for the hiring staff to give the appearance of being important and needed within the company. If managers really understood how effectively non-management engineers can find and hire acceptable candidates when you remove the bullshit from the process, they would be confronted with the cognitive dissonance of their choice to staff up an army of HR and recruiters and talk all day about "ZOMG how hard it is to hire a good engineer!" and "look out for the toxic worker" and other such drivel.


When I interview candidates, the make or break question for me is does the person possess critical thinking skills?

Various things may point one way or another for this, but it is a mistake to assume [insert working at a particular company] is an indication that someone has to have the skills, as well as to assume someone not having [insert pet qualification] is an indication that someone does not have these skills.

Sadly, there is a severe lack of this skill applied in our profession, and it is probably the costliest common mistake I see.


Any pointers on assessing critical thinking skills during an interview, e.g. with or without technically focused questions?


I would be interested to know how you're assessing for "critical thinking skills".


instead of asking them stupid, verbatim-recall questions, i give them a problem and ask them how they would solve it.

i.e., "a customer reports his website is running too slow. describe how you would identify and solve the problem."

it's a good sign when they start asking you follow-up questions, like "is it load balanced? is there a database?". it's a bad sign when they say, "just restart the server".


I got asked "what happens when you hit return in the browser?" After I had traced from the keyboard driver through libraries and runtimes to the browser event system, then back down thru the network layers to sockets, then thru IP events to land a packet on the remote router, they called a halt. Apparently nobody had actually answered the question before.

IMO Its a good exercise for problem-solving, and plumbs experience and terminology. I'm not so sure you learn anything about the subject's actual programming skills?


I think that both this question, and beachstartup's question about speeding up a website, are totally decent interview questions, for a intermediate-to-senior web developer.

But if anyone thinks that either of these questions is testing "critical thinking skills", or "problem solving", then I would like to hear in what way. Both of those seem to me to be pretty much archetypal "verbatim-recall questions".

Experience and exposure and education and ability to brute-force recall all of the above is valuable. But it's pretty much the exact opposite of what beachstartup said (s)he was testing, and there is zero "problem solving" in the "what happens when you hit return in a browser" question.

I'm a little bewildered how anyone could confuse these diametrically opposed aptitudes.


True. It takes all kinds of questions to get a good impression.

But I'd just like to protest, my answer was not 'brute-force recall'. It was simple experience. See, I've written code at all of those levels. None of it was booklearning.


I'll start by noting that this sequence of comments is just nit-picking, and if that bores anyone, stop reading. That disclaimer disclaimed...

I don't honestly care if it was booklearning or not, and I don't see what it has to do with my kvetch. I'm happy to believe you that it was learned from experience.

What does "brute-force recall" mean to you? To me it means that you are only repeating things that you knew before the question was asked, as opposed to dynamically generating new knowledge during the time that you answer. Whether you originally got that knowledge from books, or from experience, or from Mr Spock doing a mind meld, it's still memory, as distinct from problem-solving or critical thinking or perhaps more generically we might name "wit" as the counterpart of memory.

Again, I'm absolutely not knocking this form of knowledge; memory without wit is perhaps inflexible, but wit without memory is impotent. Memory is a good thing. Memory makes up the much greater half of expertise; this is why seniors get paid more than juniors (would you rather hire an IQ180 noob who knows nothing about the problem, or an IQ120 worker with 20 years of relevant experience?).

But I'm getting pedantically wound up about this minor nit: both you and beachstartup gave examples of interview questions that are tests of memory, and framed them as tests of problem-solving. If problem-solving is the thing you want to test, those are terrible interview questions for that particular purpose.


Never! Mine was just an anecdote, with no claims one way or the other. Probably out of context I agree.


well yeah, it's just one question. programming and devops proof is in the pudding. we just ask for code samples and a walkthrough, and go with our gut. maybe a few technical procedure questions.

in my experience it's the other things that will make or break an employee, like whether or not they have an actual work ethic, or is a closet drug addict, or gets too drunk and touches women inappropriately at company events.

these are things you can't test for in an interview or background check, and i find it strange that nobody ever mentions this kind of stuff because personal problems are the most common kind we run into. it's rare to hire someone totally incompetent if you yourself have extensive experience in the work you're hiring them for.


If you have personal problems with people - check references. People will rarely state that such a person who causes problems is a "joy" to work with.


yeah, we do that too.


I think that's actually a really good question. It shows deep knowledge and understanding of everything that is happening during a user interaction which is essential knowledge for a webdev. Plenty of "front end developers" have no clue what an HTTP request is.


Web developers don't need to know how a keyboard works. Nothing much more complex than key press down/up anyway.


Nobody was discussing how a keyboard works, but how the web works after you press return on the keyboard. And it's sad that too many web developers in general[1] seem to have the weakest understanding of such basic principles.

[1] super-anecdotal self-selected data points from hiring and conversations


The parents parent comment discusses keyboard drivers. They wouldn't operate very well without them.


If any front-end developers do want to learn more about Internet/browser networking, I'd highly recommend the book High Performance Browser Networking by Ilya Gregorik. It looks like there's even a free version now available online:

http://chimera.labs.oreilly.com/books/1230000000545


I would have a hard time not to say "what's return doing in the browser? Last I looked it was on the keyboard".

I guess that's why I get hired by sarcastic people a lot.


Yeah, definitely. I never felt more like the Mike of the story than I did interviewing at Airbnb. Every interviewer was fresh out of school, very smart, fashionable and attractive and definitely wanted to prove something. Despite doing rather well and scoring exceptionally well on personality, I was still passed on, and it's hard to shake the feeling that maybe it was because I wasn't a hipster. They just had this air of superiority the whole time.


>it's a solicitation for assistance with a built in humility.

Thank you for bringing this up. No matter how good or bad a candidate is, that person is your social equal and deserves basic respect.

I feel strongly about this ever since the humiliation I faced at AirBnb,

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

This could happen to anyone.


Wow I had a similarly perplexing and bad experience interviewing there.

It was for a UI Engineer position. I did very well on all of my technical coding challenges, with the exception of an algorithm question, which I still managed to complete once the interviewer pointed me in the right direction.

I was later told that while everyone really liked my culture fit for the company one of the interviewers with whom I sailed through the challenge thought I did mediocre, and the algo question asked said I "really struggled". It was pretty devastating but I just chocked it up to me needing to dig in and study harder.


I just read that. Dam.


When I interview, I start with a description of the couple of team members they'll be working most closely with, for, or leading. After that, I like to ask "With your limited understanding of where we're strong right now, what do you think your biggest contribution to our team will be? what will we learn from you?"

I've not done any validation studies on the answer, but it's certainly the question that has led to the best conversation.


That makes sense, after all, you're going to be paying them, not giving them an award.




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

Search: