141–150 of 152 posts
In related news, "People are still bad at knowing the unknown" and "Everybody thinks they're average; perhaps because their sample size can only be 1."
It's my understanding that this is not the case.
People typically think they're above average.
https://en.wikipedia.org/wiki/Illusory_superiority http://www.livescience.com/26914-why-we-are-all-above-averag...
Earlier quoted context omitted.
When I was at Code for America I redid their hiring process to optimize for interviewee experience rather than hiring manager experience. One of the things that really struck me at the time was that traditional interview processes are built around a notion of worker surplus and job scarcity. They make very little sense when the opposite condition applies. Even little things like contacting all applicants within 24 ho…
> worker surplus and job scarcity I'm convinced that's the only reason why processes at places like google aren't considered completely broken.
Some of that filtering, whether intentional or not, is how rigorous the interview process is. They can afford to be that rigorous though because the fact is that even if they miss out on one really good candidate there are 10 or more replacements in the pipeline.
The same does not apply for smaller companies with less engineering centric workplaces. If they try to do it Google's way they'll be shooting themselves in the foot.
Earlier quoted context omitted.
A company's bad interview process might have nothing at all to do with the rest of the company. At this point, isn't it generally accepted that all tech interviewing sucks, and companies would do better throwing darts at resumes? If all interviewing is bad, and all companies are not bad, there's no benefit to judging a company based on that process.
People have been talking about the terribleness of tech interviewing for years. If a company isn't able/willing to improve important processes, that's definitely a sign to me.
1. Pushback on work sample tests from the recruiting companies.
2. Upper management wondering why it's so hard to find candidates that can pass our work sample tests.
3. Suggestions that maybe we should be using an online coding test. (multiple choice questions of poor quality)
It can be really difficult for companies that don't have a lot of in-house experience here to figure out how to hire good developers. Much of what is known in Silicon Valley style companies isn't really known by HR in a smaller company in the midwest. They don't typically read HN or follow the tech blogs. And unless they luck into hiring a vocal Senior Developer like me to specifically guide their recruiting and interviewing process they won't even realize how badly their hiring process is.
Earlier quoted context omitted.
I totally agree that they -can- do the job. The most important thing for a software developer is the ability to learn. We need to give people chances so that they even even enter the field to one day become senior level. But I also understand how a lot of business owners feel about it. It takes time to learn these things vs someone who has basically already done this project before in this stack before. A business in…
I think what you're getting at taps into the heart of the issue- it's not just that the software industry is fast-paced in terms of innovation, it's fast-paced in terms of business requirements, in getting products out of market to scramble for users, which translates to higher valuation, and more VC dumb money. So in SV we kinda have a HFT-type situation where companies have to continuously get more and more speedy…
Even jobs that don't really need developers of that caliber will hire like they do. I need someone to yet another billing app? Let me just hire one rockstar genius and squeeze the life out of them instead of two regular developers because it's cheaper.
- some mock-ups from when we first designed our product gallery
- a json file that listed the products names, pictures, description, etc.
- a blank css file
- a html file that loaded the css and jQuery, and then made an ajax request to load the json file. (This was back when jQuery was pretty much state of the art for front-end.)
With all of that in place, I'd explain that I'd like them to work on building a product gallery that looked similar to the mockups. I would further explain that, since we only had an hour, I didn't expect a polished or even fully functional product, but I'd just like them to dive in and see how far they got. They could use their editor of choice and ask any questions they wanted.
I felt like this gave better insight to candidates skill and workflow. My colleagues all gave more traditional interviews, so I also felt like there was a good counterbalance if someone didn't do well with this kind of interview.
Earlier quoted context omitted.
I agree with you about the training. However if the stack is too specific, then the stack it's like a fingerprint and they are looking for somebody with the same fingerprint...
@Jemmeh I "failed" a similar interview (VB, C#) Don't they know that the VB and C# examples are shown on Microsoft's site side by side?! The only conclusion I reached is that one should navigate in life in such a way that your well being should not depend on people that are less smart, less experienced, less curious than yourself.
I used to do a lot of interviews for front-end engineers. The process I settled on was to give them the following setup: - some mock-ups from when we first designed our product gallery - a json file that listed the products names, pictures, description, etc. - a blank css file - a html file that loaded the css and jQuery, and then made an ajax request to load the json file. (This was back when jQuery was pretty much…
Skewing interview performance based on some specific previous experience might be what you want if you expect your candidates to hit the ground running, but might not be the best to gauge long-term performance.
Earlier quoted context omitted.
I do not mean any offense. I really don't. If you can think of a nice way to convey the same sentiment/message, but without the offence, I'm all ears and would happily edit the post. Again, let me stress, I think there are arguments for long and short. I do not advocate for right and wrong, merely try to convey the reality I'm in, given that it's so different apparently from SF. Realise also, in good faith, how offen…
I'm replying to my own comment, since I unfortunately do not appear to be able to reply to the one below... But... You do realise what "mechanical Turk" is...as in...the Amazon service called "mechanical Turk" based upon the chess playing automaton, and that it's basic premise is often westerners paying people from poorer countries, say...India, to spit out quick small pieces of work for them. There is no offense int…
One of the important lessons we learn in this life is that we're responsible for the offense we cause (or more specifically: the offense implicit in what we say), not the offense we intend.
Once you have an engineering job, a typical project tasking involves: some team design discussion, some engineering research, some work, some review, more work. The requirements are either known upfront, or determined as a team. I do not understand why interviews are not conducted in this manner. Pick some arbitrary idea and have the candidate work with the interviewer to design something, then let the candidate do a…
That's a good idea but logistically is hard, both requiring the interviewer to spend considerable time on site as well as costing your own employee's time. It might work well for a small company especially with a small number of candidates but it doesn't really scale, unless you are a really big company (googleish size) that can dedicate so many resources to the interviewing process. Doing design and research takes t…
After you've run this process enough times, your interviewers will have a good grasp on the various solutions and technical problems. Most people's training on how to interview comes from how they themselves were interviewed - which was probably poorly done. Improve the interview process and you can train people to be better interviewers just by being interviewed. :)
I used to do a lot of interviews for front-end engineers. The process I settled on was to give them the following setup: - some mock-ups from when we first designed our product gallery - a json file that listed the products names, pictures, description, etc. - a blank css file - a html file that loaded the css and jQuery, and then made an ajax request to load the json file. (This was back when jQuery was pretty much…
Doesn't that heavily bias towards candidates who have used jQuery before and/or built a product gallery before? Skewing interview performance based on some specific previous experience might be what you want if you expect your candidates to hit the ground running, but might not be the best to gauge long-term performance.
As far as the product gallery goes, I wasn't looking for a pixel-perfect product. Just spit out a bit of html and matching CSS that look vaguely like the mockup. The mockup images had things like the hex values of the colors written on the image to make that part easy.
Basically, it was trying to focus on things that would be the main part of the candidate's job there. The folks that we did hire all did well on both that interview and long-term at the company.