61–70 of 97 posts
OP: "There is a slight proclivity to conduct technical interviews within the companies that comprise the community." The companies constitute the community. The community comprises the companies.
> as eluded in the following
It "alludes" (to), not "eludes".
And you and I are both complete jerks for being literate in at least one natural language.
Earlier quoted context omitted.
Not quite sure how to answer that. Do you mean what was the label on the job req? I don't remember. I think it was "Senior software developer" or something like that. Is that what you meant? (And if so, why do you ask?)
I'm trying to figure out what software development job that would ever come up? graphics?
Here is my take on hiring: an active Git repository with a decent amount of non-trivial code/projects generally gets applicants I have to evaluate to skip the whiteboard interview and instead grab lunch or coffee with me. We then discuss technology/software engineering. I find this approach to have yielded much more conclusive results, though it probably would not "scale" well. You can quickly tell whether someone is…
If you start with github repositories for your candidates, aren't you filtering out people who do things other than work? Most of us work 40 to 60 hours a week, and sign paperwork that says that any code we write belongs to the company. But now we need to work Saturday and Sunday on open source projects so we're worthy of sharing a coffee with a hiring manager?
I have turned down several jobs when they tried to hit me with that clause. I have negotiated a better clause that gave them the work I made for them, which just happens to line up with state law here
> But now we need to work Saturday and Sunday on open source projects so we're worthy of sharing a coffee with a hiring manager?
I wouldn't want to hire someone who didn't enjoy coding enough that they didn't have something on publicly visible repo.
Earlier quoted context omitted.
>, but something about the overall tone seems a bit off: [...] You're not an "A+ player", and most of your team aren't "A+ players" either. I believe you misinterpreted the author's backhanded "compliment" about teams' _self-proclaimed_ "impressive A+ players" . His tone is sarcasm if you combine it with the repeated fixation on "Fibonacci" puzzles in the rest of the essay: - quote: , what possible insight does quest…
But he also says "After all, the primary purpose of doing technical interviews is to ensure A+ players are identified and are persuaded to join your team. If your process is preventing this, then you are doing it wrong." That doesn't sound like sarcasm to me...
Perhaps calling it "sarcasm" is too strong since his sarcasm is very subtle. If you integrate his entire essay about "Technical Interview Rift", he essentially wants to lecture the "too cool for school" dev teams that pride themselves on Fibonacci puzzles, etc. However, he can't go into full-frontal sarcasm mode like Stephen Colbert / John Stewart because he doesn't want to make the very audience he's trying to reach tune out from his message.
Therefore, he has to dance around his intended message in such a way as to not insult his target. There's probably a better word to describe what he's trying to accomplish but I couldn't think of it so I called his passive-aggressive tone: "sarcasm".
OP: "There is a slight proclivity to conduct technical interviews within the companies that comprise the community." The companies constitute the community. The community comprises the companies.
And: > as eluded in the following It "alludes" (to), not "eludes". And you and I are both complete jerks for being literate in at least one natural language.
Seriously, though, the original attempt at writing actually does mean something -- if the companies do comprise communities somehow (perhaps of users or shareholders), then it makes sense to reference the subset of companies that comprise a particular community. But that's not what the author intended to say -- they just wanted a pompous way to say "all the companies" or (better) "the companies".
(And don't get me started about misusing "community" to mean "group" or "collection" or "lame way to make the preceding word plural", as in "the developer community".)
Earlier quoted context omitted.
If you start with github repositories for your candidates, aren't you filtering out people who do things other than work? Most of us work 40 to 60 hours a week, and sign paperwork that says that any code we write belongs to the company. But now we need to work Saturday and Sunday on open source projects so we're worthy of sharing a coffee with a hiring manager?
> says that any code we write belongs to the company. I have turned down several jobs when they tried to hit me with that clause. I have negotiated a better clause that gave them the work I made for them, which just happens to line up with state law here > But now we need to work Saturday and Sunday on open source projects so we're worthy of sharing a coffee with a hiring manager? I wouldn't want to hire someone who…
Shudder. Sounds like one chooses to work for you, or have a healthy life that involves non-coding/computer hobbies and relationships.
Maybe it's a good filter for us in the opposite direction.
> All in all, would do again, except not more than 1 a month because flying across a continent and back for 1.5 days is gruelling. This is part of the problem. Aside from college graduates, who has time to fly around the country burning vacation time to maybe get an offer?
On the other hand, would you really accept an offer without having at least met the people you'd have to work with? Especially if you have to move across the country?
I think Triplebyte has the right idea: essentially a take-home test conducted over a period of a couple of days. It allows a candidate to show off what they can do under realistic conditions, instead of allowing an interviewer to poke at what they can't do under highly unrealistic high-pressure conditions. A typical tech interview is more like a spelling bee than a realistic test of a candidate's abilities: if you ha…
I have tried using take-home tests before. The level of plagiarism was astonishing. And that's just the plagiarism I could detect. Even with a problem that's unique to my organization, I don't know how I could trust that the actual candidate themselves was the one who completed it, and that they completed it without unfair assistance (e.g. from other people). Similarly, I have a habit of looking over someone's resume…
This is a requirement to get past the HR gatekeepers at most companies. That may not be the case at your company, but how can I tell? When a critical mass of companies require you to lie before you can even talk to a technical person, then you're going to get lied to as well.
Earlier quoted context omitted.
If you start with github repositories for your candidates, aren't you filtering out people who do things other than work? Most of us work 40 to 60 hours a week, and sign paperwork that says that any code we write belongs to the company. But now we need to work Saturday and Sunday on open source projects so we're worthy of sharing a coffee with a hiring manager?
> says that any code we write belongs to the company. I have turned down several jobs when they tried to hit me with that clause. I have negotiated a better clause that gave them the work I made for them, which just happens to line up with state law here > But now we need to work Saturday and Sunday on open source projects so we're worthy of sharing a coffee with a hiring manager? I wouldn't want to hire someone who…
Why? Those people sound like terrible employees. Those are the people who come into work to punch the clock and get paid while saving their energy and creativity for their side projects, which is what they'd really rather be working on.
Earlier quoted context omitted.
You definitely are filtering people, unless you accept everyone who goes through the usual (tedious) interview process. This interview process is quite noisy, so being able to skip it gives a clear advantage. Whether or not this is a good thing is another question, but don't claim you aren't discriminating against people who don't code in their free time.
This is a hard problem to which there are no easy solutions, only trade-offs to be made. Here I think that I strike a reasonable middle-ground providing I act in good faith.