921–930 of 1001 posts
Earlier quoted context omitted.
Not if you can find others who are just as good. And what's your better suggestion for filtering out people who can't code and not filtering out the good ones with anxiety?
I can't believe I just read this. I hope to never work with you.
Earlier quoted context omitted.
Why didn't you check references? I mean wouldn't you consider it a failure that you got a candidate to the interview table that was so bad? Assuming you aren't making it up, the guy was obviously lying on his resume, that could have easily been solved by checking his references.
Most places that firmware devs come from around here have a policy of only verifying dates of employment. That doesn't tell you much.
Earlier quoted context omitted.
I'm not sure its just the recruiting side. We're seeing some concerning positions in the market: 1. Expectation of long work hours (Frequent and short deadlines due to agile) 2. Micromanagment being the standard (agile) 3. Terrible environments (open desk/office) 4. Removal of vacation time (unlimited PTO means you have no vacation days)
I'll use this as an opportunity to vent about agile. It promises developers a larger voice, but in my experience, it heavily favors management and product management types, since they are usually the ones in control of the ticketing/tracking systems. They aren't under the sprint deadlines that developers are, so they are able to better organize and build their cases for what gets done. Even if developers can build a…
Assignment was to develop an application which tested the candidate's skills to access web api, browse through documentation, do proper authentication, parse api results and finally the most important skill to design an algorithm to compute desired output depending on the question asked. It was doable within 3 hrs for experienced engineer. Not many succeeded in this task but those who were able to do it were real good developers.
Earlier quoted context omitted.
Said space shuttle firmware engineer probably never had to solve a pop-quiz problem on a whiteboard. It's much more likely that he/she deliberated for weeks about a simple change with the rest of their team, and perhaps even with the person/astronaut they might kill if the change had a bad bug. Who cares if this person can't solve fizz-buzz on the whiteboard? That's probably not even a relevant skill to the job openi…
> Said space shuttle firmware engineer probably never had to solve a pop-quiz problem on a whiteboard. It's much more likely that he/she deliberated for weeks about a simple change with the rest of their team, and perhaps even with the person/astronaut they might kill if the change had a bad bug. > Who cares if this person can't solve fizz-buzz on the whiteboard? That's probably not even a relevant skill to the job o…
Also, another thing to consider is how this kind of interview encounter negatively affects diversity and the experience of candidates from different cultural backgrounds. If we treat this form of interview a sort of hazing experience that doesn't really inform on their aptitude on the job, what kind of traits does this process _actually_ select for? Would be an interesting study.
Earlier quoted context omitted.
I've had multiple comments detached (as you can see by my comment history) for calling out companies that suck to apply for in the monthly hiring threads. Either the people who posted must have complained so they removed it, or HN doesn't want people to know some companies suck to deal with when it comes to hiring process.
Don't let the HN censorship discourage you. Name them and shame them!
Earlier quoted context omitted.
A lot of that's true or might be true, but how do we improve things? > you are “leaving money on the table” when your interview process deselects great programmers because of a mistaken belief that Test A is a good proxy for developer talent. That's true for any non-perfect interview process at any job. The problem isn't that people don't know this, it's that it's hard to accurately measure who's good. > you might co…
One thing I would say is just talk through problems with candidates as simple as that sounds. Try to grok how they think through software problems. Nothing mind-blowing there, but what I'm saying is how someone codes fizz-buzz tells very little...or to me this is like hiring a driver by taking them out to a parking lot and doing doughnuts. If you can fathom the idea that they can drive a car (at all) it seems like it…
That's what people do, or should be doing, along with the whiteboarding. I don't think anyone just has them do fizzbuzz and that's it, like you seem to be implying. That won't even fill an entire interview slot.
> it seems like it is much more enlightening to hear about how they organize a schedule...
Sure, and that's also something you ask about, but that doesn't weed out the people who can talk the talk but can't really program, who do exist.
> But even as I type this, I'm wondering if the ability to read people is why this so hard for software interviewers...or maybe it's for lack of that simple skill that our industry has resorted to silly proxies like fizz buzz, etc.
I think it's because people want real evidence of skill, which is pretty easy to detect via whiteboard in most cases, not just the interviewer's gut feeling.
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…
Earlier quoted context omitted.
Exactly. Just a week or two of contract work will tell you if the candidate is a fit or not. A 30 minute phone screen will tell you if a candidate is worthy of a contract. I think companies don't do this because a. They don't want to pay and b. They don't get to gloat 'we have a super rigorous hiring process'
How many engineers would accept an offer which is conditional on "a week or two of contract work"? Most of the engineers that I've hired came from another job (not all though), and so they need a confirmed offer before they are willing to jump ship. So this practice introduces its own selection bias; you'd only be sampling from the pool of currently un-/fun-employed, and those who hate their current job enough to qui…
Earlier quoted context omitted.
Companies don't do this because it will wildly cut down their candidate pool. There is _literally no chance_ that I am going to leave an existing job for a "week or two" contract with a company. If that's part of their hiring process, I will simply look elsewhere.
It's typically a 3 month contract, not a couple of weeks. A couple of weeks isn't enough.