261–270 of 354 posts
Earlier quoted context omitted.
You used the term "gently fire". I was wondering if you could elaborate on how you "gently fire".
Stop sending paychecks, they figure it out eventually.
They may have performed work for you, and they might not have gotten paid. You open yourself to so much liability it's not funny. A judge would look very unkindly to such practice.
Hiring engineers is hard, and companies haven't really figured it out yet. Even the best companies rely on puzzles and gimmicks that often have little to do with day-to-day programming. At one company I interviewed with, I was asked to implement a queue using two stacks. At that time in my programming career, I had worked with C, C++, Obj-C, Lua, Python, JavaScript, SQL, and a handful of DSLs developing games, game d…
Exactly. "Tell me about your last project" can easily turn into a 2 hour conversation with any developer who has built anything of substance. It will tell you everything you need to know about them.
Earlier quoted context omitted.
What kind of IQ tests? Math thinking? Language? Other? These tests are kinda old and don't prove anything besides the fact that the person has a certain level of intelligence but that doesn't mean they can code.
> What kind of IQ tests? Math thinking? Language? Other? Both. They're not perfect, but I'm going to be picky and look for people who can generally reason well (both mathematically and verbally). > but that doesn't mean they can code. That's why you pair it with work samples. The ideal hire would be an impressive GitHub + evidence of intellect. The GitHub shows they have coding chops, while an IQ test usually means t…
I still have a bit to show on Github and mean to put up more when I have a chance but still, most developers find that when you've got a decade or more of experience, you start to want to take on new challenges and experiences (whether family or woodworking) in your free time rather than more programming.
If a startup asks you to solve math puzzles, it's possible that the work you will be doing heavily involves the creative use of math or information analysis. (This is more broadly valuable than many people recognize.)
Also, it's also possible that that particular startup doesn't know how to effectively interview.
It doesn't sensationalisticly mean all Startups (capitalization yours) don't know how to effectively interview.
Also, rather than focus on your ability to learn, I would humbly recommend you reconsider the basic nature of employment. An interview should be considered a two-way conversation. You're not selling yourself as a slave, you're entering into a mutually-beneficial, private, voluntary arrangement. Thus, even someone who goes into an interview willing to accept anything and everything they offer could be expected to ask simply, "And what exactly will I be doing?" But better yet, grill them about every nitty-gritty detail you can think of. Although some insecure interviewers may be taken aback (I'm guilty of asserting the interviewer was wrong on more than one occasion, both times still receiving an offer), I for one am impressed when a candidate demonstrates a sharp, critical and skeptical mind in this way.
There are many discussions here on HN about company hiring procedures. Company hiring procedures and their effectiveness is a heavily researched topic, but most hiring managers and most job applicants haven't looked up much of the research. After reading the blog post kindly submitted here and some of its comments, and then reading most of the comments here on HN that came in while I was asleep in my time zone, it lo…
I can confirm this works in my own experience of trial-and-error interviewing over 2000 applicants and hiring over 200 for my clients and myself (since ~2006). Nearly 100% of the applicants were remote, so I think that helped me from falling into traps of poor "traditional" hiring practices. The point of hiring these remote folks was to help accelerate whatever team I was on. It can be a great way to scale your exist…
God I would hate this. I'd rather be told that my work sucks, and shown examples of better work, so that I could actually improve and not just wonder if I was let go for some arbitrary reason. If I disagree with you BFD, life goes on, but I'd at least like to know if it was related to my output or not.
Earlier quoted context omitted.
Stop sending paychecks, they figure it out eventually.
That is so wrong. They may have performed work for you, and they might not have gotten paid. You open yourself to so much liability it's not funny. A judge would look very unkindly to such practice.
Earlier quoted context omitted.
> For some bizzare reason, a lot of P̶H̶P̶ devs obsess over mini benchmarks and tiny speed issues while ignoring massive latency factors (like the DB). This sort of behaviour isn't unique to PHP Devs, not even close.
True. Reminds me of all the roadies (road cyclists) who would come into our bike shop and demand the lightest components to put on their bikes, then rave about how they cut 10 GRAMS off of their bike weight. Totally ignoring the fact they're pushing almost 220lbs themselves.
1 rider managed to get more than half right. And he was a frame builder riding his own bike.
Earlier quoted context omitted.
Stop sending paychecks, they figure it out eventually.
That is so wrong. They may have performed work for you, and they might not have gotten paid. You open yourself to so much liability it's not funny. A judge would look very unkindly to such practice.
On odesk you hire people for projects of limited time.
He didn't mean that you don't pay the people you've hired if they do the work they promised - that will get you kicked out of odesk really quickly.
What he does mean by "gentle fire" is "don't hire them again for more work".
And that's how it's supposed to work: odesk freelancers have no right to expect being hired by you for second job if they didn't perform to your satisfaction on their first job, for which they were paid the amount they agreed to be paid (just to make this clear).
Earlier quoted context omitted.
despite Hacker News/Paul Graham dogma to the contrary, "smartness" isn't the only thing that matters in programmers. It's actually fairly low down the list. [...] I interviewed a guy who was intellectually very smart and understood a lot about CS theory. I asked him why the PHP code he sent me didn't have any comments. "I don't believe in comments because they slow the PHP interpreter down." Sorry, he can be smarter…
So, smart includes some kind of experience-derived common sense that isn't measured well by IQ tests...? Perhaps someone should tell the people who want to use IQ tests to measure the quality of programmers...
This isn't "common sense," per se. It's more like uncommon sense. Most people follow an effort in -> result out paradigm, believing the two are perfectly correlated. A "smart" person, in PG's view, attempts to min effort and max result. (I've also heard this sort of hacker described as "lazy," in a positive and non-derogatory sense. A "lazy" person finds the most efficient and effective ways to do things, minimizing man-hours and resources.)
The relationship between "smart"/"lazy" and IQ hasn't been studied all that well, but it seems plausible that there is some sort of relationship. Perhaps it's a strong one, and perhaps it's not. Either way, I don't believe an IQ test as a single-factor qualification gate will filter effectively for "smart"/"lazy."