For example, I may say please use functional reactive
principals in JS to solve this problem, but the decision
of using Kefir, Bacon, or RX is left up to them.
These days I'm utterly unable to tell whether someone talking about JS is being serious or if it's parody.A Method I’ve Used to Eliminate Bad Tech Hires
391–400 of 517 posts
Re: A Method I’ve Used to Eliminate Bad Tech Hires
#392I a single non tech question that is a very good heuristic for hire/no hire. What is your favorite 4 letter word. I usually ask at the beginning of interview and expect an answer at the end. Answers like fuck and shit === no hire. The other ones tell you a lot about the person
but you cant say that because idiot hiring managers who ask idiot questions would insist that you do.
sorry, but if you ask shit questions, dont expect non-shit candidates.
Re: A Method I’ve Used to Eliminate Bad Tech Hires
#393Earlier quoted context omitted.
That only makes sense if you're talking about people who are unemployed. As someone who is already employed full-time, I simply don't have the time to solve your problems for free just to see if you'd like to invite me over for an interview. I avoid these problems like the plague and very much prefer to whiteboard. If you pay me consultant rates, I can more easily justify the effort.
>> much prefer to whiteboard Who would have thought? Maybe - just maybe - not everyone has the same strengths and weaknesses. The real answer here is obvious: present the interviewee with options. Forcing all potential hires to whiteboard is a terrible idea. Forcing all potential hires to do a take-home project is a terrible idea. It's extremely short-sighted and a little pompous to assume that any single interview f…
If you're a company that does any kind of business with the federal government, that's simply not an option. You have to be super-consistent in terms of your interviewing and recruiting process across all candidates for a job req and can't do things for some candidates without doing it for all of them.
Re: A Method I’ve Used to Eliminate Bad Tech Hires
#394I a single non tech question that is a very good heuristic for hire/no hire. What is your favorite 4 letter word. I usually ask at the beginning of interview and expect an answer at the end. Answers like fuck and shit === no hire. The other ones tell you a lot about the person
The only honest answer to this question is "i have no favourite four letter word". but you cant say that because idiot hiring managers who ask idiot questions would insist that you do. sorry, but if you ask shit questions, dont expect non-shit candidates.
Re: A Method I’ve Used to Eliminate Bad Tech Hires
#395This is one of those "aha" solutions that people keep mentioning, but completely ignore how it would work in a non-ideal world. • What 2 hour project can you assign that would let the candidate go into enough depth for you to judge their code, design decisions, architecture skills? • If you give them more time (e.g. a weekend like in the article), is it still financially viable to the company, especially at $100/hr??…
Well, the movie project suggested in the article was a pretty reasonable one.
Re: A Method I’ve Used to Eliminate Bad Tech Hires
#396This is a great way of hiring, but unfortunately it doesn't fit in all scenarios. First, this model alone doesn't scale. Big companies interview hundreds of candidates every week. It's not possible to design and evaluate a weekend project for each one of them. This doesn't mean that they can't have projects, but early filters are needed. That leads to the classic phone and F2F interviews to rule out those who can't c…
The common approach for big companies is to declare that false positives are way worse than false negatives, but if the problem is that you can't find enough developers to fill your roles, it may be better to have false positives coupled with a trial period or something similar.
Re: A Method I’ve Used to Eliminate Bad Tech Hires
#397Earlier quoted context omitted.
Interesting to note how different people are indeed. I am fine with white board type situations, don't worry about writing code without IDEs etc (in my very first job vi editor was the only thing we had to write code so I still have instinctive memory to be resourceful without an IDE but I love IntelliJ for most things). Happy to discuss/draw out ideas/solutions on whiteboards. But find it very seriously annoying tal…
Some of that really depends on the problem and the language. I program Java full time, yet I'd be useless with vi. I lean heavily on the IDE. I've done this a long time and I firmly believe that I should use the best tools available, not just a text editor or a TEXTAREA, even with syntax highlighting. Having suffered through a couple code interviews in Java, I now pick Python when allowed to pick a language. It seems…
Re: A Method I’ve Used to Eliminate Bad Tech Hires
#398Problem is, many companies are only playing interviews. When you want to hire people who gets the job done it is no harder than: 1. Please tell me about a project you have done, a sw book you read, a hard bug you solved, really anything you like about computing etc. 2.a (This guy seems smart) Let's discuss compensation and you can start your probation period asap. 2.b (This guy is not smart nor passionate) Thank you…
Exactly. Also you have no idea what kind of cultural fit you're having if you only rely on technical skill. And besides, why do you want me to solve $problem? Take a look at my portfolio and public code - it's telling enough.
I see a lot of comments here about how they would never waste their time on an exercise like this, but a small project for the purpose of an interview can probably be done in less time than any of your public projects.
Re: A Method I’ve Used to Eliminate Bad Tech Hires
#399Does anyone have experience with this style of interview from the candidate side of the equation? I want to move to this style of hiring; however, I fear that because it's against the grain I may miss out on good candidates. Is that unfounded?
I might be more ok with it if it was meant to replace the in-person interview but otherwise it took up significantly more of my time. It was nice that they gave me 2-3 $100 amazon gift cards but, like other posters, I'd rather have my time than extra compensation.
The first assignment was supposed to take 4 hours but took me over 6. The second was supposed to be a whole day thing but I could only put in about 4 hours.
It was useful to gain some insight into their culture. I'm still mixed about what I think of it. The short takeway is that they are continually learning and updating their practices (good) but they were koolaide drinkers (bad) and throwing around buzzwords from specific individuals' blogs as if that was everything without showing a deep understanding of those buzzwords (causing them to completely miss that I exercised those same principles, even if I had no clue what they were talking about).
The longer version. They originally were going to turn me down for not using enough . They were also disappointed that I didn't use . Originally, they weren't even going to explain more than that but I pushed on it to see what I could do better and through the conversation they warmed back up to me. Later I looked up their buzzwords.
The first was SOLID which appears to have limited use in the industry. First, they couldn't even break up which part of SOLID I was violating but instead were throwing the acronym of acronyms around like that was all that needed to be said. When I dug into their feedback more, I found out it was my main function that "wasn't SOLID enough" which did argument parsing and delegated the rest of the logic to other code that was so well designed that they had to throw out the main follow up question.
I literally could only find one software development subcommunity that used the second buzzword and that was mostly limited to one consultant's blog. They also showed a lack of depth in it because I was actually using it, just at a different layer in the stack, solving the same problem they thought it would address.
Re: A Method I’ve Used to Eliminate Bad Tech Hires
#400This is literally the only way I've gotten job offers. I'm a very competent programmer, but when I'm asked to solve some silly puzzle with someone staring over my shoulder, I freeze under pressure and can not think at all. Luckily not everyone thinks solving leetcode problems is a good way to hire.
If you can't code under pressure, you aren't a very competent programmer. Real world projects come with high pressure scenarios for software engineers. Code monkeys may be able to get away with low pressure, minimally impactful projects.
But I will not work in a company where that's the norm.
I value my health more than the potential money from that stressful job.