731–740 of 766 posts
Earlier quoted context omitted.
"For negative performing people, I usually give them something kind of busy-work that doesn't involve the rest of the team." Why waste time? Why not just fire them?
Because you can get sued for firing them. Sued for multiples of their annual salary.
Earlier quoted context omitted.
How often do you need to write palindrome functions for your job? Checking substring in a string is a 1 liner in languages like python. I was at a final interview with FAANG. One question asked was to load a csv. I used pandas, it's a 1 liner. You could see the wretched face of the interviewer since he was expecting a with open() as f: do_some_shit and kept pushing me to write this on the board. I looked at him and s…
Ah. Did I not mention that these CSV files I wanted you to parse... they're generated by an old mainframe system we can't modify the sourcecode to. It does have a few idiosyncracies - for fields like addresses which can contain commas, it uses a special escape sequence where the field just consists of three asterisks, then the value for that field is the content of the next line. Oh, and it uses just CR characters fo…
Earlier quoted context omitted.
Don't know why you're getting downvoted. Much of the language I get from bigco people about why they are so selective is exactly this; it's almost a confession that once in, they are very bad at managing performance.
The downvotes are probably because I've implicitly called out individuals who believe in - have perhaps even published materials encouraging - the "missing out on 99 good hires is better than making one bad hire" philosophy. I've also explicitly called out the FAANG hiring practices, which are frequently held up as the best practices in the industry by those doing the hiring. After all, who wants to be even partially…
To me it paints a terrible picture. My suspicion is that the dangerous bad hires are not the utterly incompetent people who will flail in place until removed. The dangerous ones are going to energetically do all sorts of peripheral, irrelevant work, try to insinuate themselves into a lot of 'process' type setups, and move around the company in a way that stops anyone from ever noticing that they can't actually do anything. I suspect a lot of BigCos have very weak immune systems against such mobile 'attacks'.
Earlier quoted context omitted.
> Motives are mostly irrelevant They are relevant enough that the prior poster felt the need to smear them. > if the effect is the same The claimed effect is, at this point, purely hypothetical and indeed runs contrary to my experience. > An easy switch would be to convert take homes to onsite work. Generally speaking, an onsite task like you describe seems like a reasonable choice for a company to make. However, thi…
I think you’re reading malevolence where none is intended. Simply pointing unintended consequences is not smearing. While it is true that the effect is merely claimed, as I know of no relevant study, your anecdote equally meaningless. The the on-site solution remains a blind audition if the people doing the evaluation are not the people administering the test. This is exactly the case for a take home assignment, only…
Pointing out (potential) unintended consequences is fine, even welcome.
Putting sexist remarks in the mouths of others is a smear, even if it is done merely flippantly.
> While it is true that the effect is merely claimed, as I know of no relevant study, your anecdote equally meaningless.
Anecdote is more meaningful than mere speculation. Even without statistically valid data, examples that are contrary to our expectations can bring to light factors that we had not previously considered.
> The the on-site solution remains a blind audition if the people doing the evaluation are not the people administering the test...The purpose of the blind audition is not to hide the identity of person being interviewed, as much as it is to enforce an objective standard and remove bias. If the rubric is, “Accept all that got automatic evaluation score of at least X”, then that achieves a similar goal.
A fair point.
> This is exactly the case for a take home assignment, only now it is timeboxed and with access relatively timely help if needed.
The point about timely help is definitely a point in favor of on-site work tests. But working in a timebox can also be stressful. A take-home assignment without artificial deadlines (i.e. don't schedule any interviews until after the assignment was received and approved) can eliminate that stress.
> As far as time-poor people, never underestimate the desire of having a clearly defined block of time. Of course, onsite or not can always be optional as well.
I think this hits on an important point, and one that I think would benefit from research and expertise I don't have. I'd hazard a guess that it depends upon why one is time poor.
If the candidate is intelligent and capable, but somewhat disorderly, then they would probably benefit from a structured, on-site task.
If the candidate is more organized but simply has a difficult and rigid schedule (which is actually something I would expect true, for example, of a working mother) then a take-home assignment might be better.
I don't know that either one is superior in all cases. Honestly, I think the best option would be to give the candidate a choice.
We also, sadly, have found that a large portion of our interviewing time is devoted to "fraud detection" as many candidates simply cannot do the things that their resumes indicate they should be able to do.
The process described in Point 1 is the most important takeaway. Probably HR departments have all adopted this process following some best-practice which surely arose in the last few years. Maybe there is some blog post (from HR specialist) explaining it in detail?
E.g. https://www.jobvite.com/recruiting-process/7-benchmark-metri... https://www.glassdoor.com/employers/blog/4-tips-for-hiring-t...
That's a reasonable model, but it works best if all your filtering steps are effective tests for the things you care about. Getting that right is demonstrably hard, between some hiring managers who don't know or don't communicate what they're looking for, some recruiters who don't understand what they're looking for or how to recognize it, and some job-seekers who don't communicate or demonstrate their skills through the hiring process. And so everyone sees and resents flaws in the funnel.
Earlier quoted context omitted.
Do you get a IDE with compiler for the palindrom question? Id say that close to 0 out off 10 engineers at work including me would get a working program without debugger or print statements. Just tried in c and got me 2 compiles to get it right. Without the output I would just present a nonworking program.
Maybe it's just me, but needing an entire IDE or a debugger to write a function that checks if a string is the same backwards seems entirely too much to me. It's a pen&paper question really.
Earlier quoted context omitted.
> Point number 2 doesn't really land for me. I can see how a dev of 10 years might never have needed to think about tuples, depending on what code she was responsible for. i'm sorry but i don't agree there. in this specific case, tuples and lists are really different and there's specific reasoning for using one or the other. it's a core feature for the language. it would be like saying someone that is a Java dev and…
Perhaps I come from a different land, but in my field, knowing a specific language intimately is not as important as knowing the wider scope of software engineering and distributed system design. I'm not a developer who is down in the weeds optimizing specific algorithms though, and I can see how a mastery of language-specific data structures and how they are represented in memory might be required for such a person.
I say this after having done an M.Sc. in Distributed Systems focused on performance analysis. In a lot of cases that I've encountered, mastery of data structures and choosing languages and runtimes appropriately can completely eliminate the need for a distributed system, or significantly reduce the complexity (an efficient 3-node system is much less complex to manage than a 100-node inefficient system).
A recent example that comes to mind is a pair of similar systems, one written in Java and one written in Go. There was an approximately 80x larger memory footprint for the Java system while having similar functionality. Plus the Java system took about 2 minutes to start up (yay Spring), vs. sub-second startup for the Go binary.
I fully appreciate the high level design of systems, and these days that's what I spend a lot of my time doing, but when shit hits the fan and the implementation of the system doesn't perform the way I'd expect it to, it's time to roll up my sleeves and get down in the weeds to help solve whatever is keeping the system from reaching its full potential. Maybe that means there was a flaw in the design, but often it's just a shoddy implementation (with Pareto 80/20 fixes to make it better)
Earlier quoted context omitted.
"That guy didn't have 20 years of experience with db2... He had 2 years of experience, 10 times." One of my mentors said that about an interview he conducted a while back. I found a lot of truth in that line. I run my tech interviews by starting very green and let the candidate dictate how fast I ramp it up. I've gotten pushback from managers before that you can't start with basic questions, but I've equally gotten p…
This is a brilliant approach because everyone has more context, meaning answers can be more pointed and exact. When the questions start small and build incrementally the next topic of conversation becomes much more natural. The candidate knows that they can use a technique because it's already been discussed and the interviewer is has more control over the flow because there are fewer tangential topics.
Earlier quoted context omitted.
Was it necessary to know on the top of your head without Googling what a binary tree is for the position the candidate applied for? I've been a developer for 12 years and I've never had the use for that. Computer science is a VERY large field and being good at everything is impossible. Asking the right questions at interviews are crucial for finding the right people. If a candidate for a programming job knows binary…
I've been a developer for 30 years, and I haven't ever had a need for it, either - but I still know what one is. I expect that you do, too.