191–200 of 226 posts
Earlier quoted context omitted.
I can never remember how modulus works, I use it so infrequently.
I think implementing a function that does what a modulo operator would is itself a fairly straightforward question.
Also a bunch of us have autism, so coding, presenting, trying to gauge the audiences, existing understanding, ensuring remaining available space on the whiteboard, working out, went to talk, and went to type, making sure you were in gauged with everybody in the room, and all the other aspects of presentation at the same time is difficult.
Earlier quoted context omitted.
I think that’s not really relevant, in the same way that it doesn’t much matter when they take a football prospect’s running times that someone could go much faster on a bicycle or in a car.
And then your football team will lose to players who are all on bicycle?
Earlier quoted context omitted.
OK. How does this answer my question, since presumably I would still want to identify at least the mediocrities rather than the complete jokers who have nothing to contribute?
Get them all to roll three 6-sided dice, and pick the one with the largest sum
In my experience conducting these live coding interviews, it's almost a universal rule that if the candidate starts coding immediately, they will waste a lot of time on irrelevant details, or take a long time to see that their approach can't work.
I always try to encourage the candidate to talk through their solution or draw a diagram if it helps them. Candidates who follow this advice always perform better.
To me this is the key to the whole problem. For many companies live coding interviews are a cargo cult approach to interviewing. Since the people that do them don't understand how to evaluate others they become a checkbox exercise that only evaluates if the candidate would tackle the problem the same way the interviewer thinks they would tackle the problem.
These debates have been done to death and mostly I also think that the article is a fairly typical strawman argument. Take the worst way to do a live coding test, point out the problems and then dismiss the whole idea. What else are we supposed to do? Take the fact that you can talk a good game as enough of a signal to invest 10s of 1000s? Assume that everyone with 20 years experience is as good as everyone else? The…
Interviewer: "Gosh darn it, you're hired!!"
Earlier quoted context omitted.
> Becoming really good at programming requires being able to focus on an actually difficult problem not work through a simplified example while entertaining an audience There are multiple ways to "become really good at programming". A company of any size needs people who can churn through well-defined problems quickly, and most live coding tests are relatively well-suited to selecting for that. They also need people…
I'd even argue it's a prerequisite. If one doesn't even know how to complete well-defined tasks reasonably quickly, I can't imagine how they would be able to break down complex tasks to these smaller, well-defined tasks, and accurately estimate the expected effort needed. This sounds almost Dilbert-esque. It seems like a lot of people here want to be a pointy-haired boss (or pointy-haired tech lead)!
You can know how to do something without being able to consistently do it.
Maintaining velocity is something that I've never been very good at. I always struggled as a junior and mid-level developer with having periods of very high productivity followed by periods of very low. I've been fired for it.
On the other hand, if you measure my output on a monthly or quarter time horizon, I'm very consistently at the top of the class.
My strong suits are around helping others get through tough problems, quickly switching between levels of abstraction (including within a single conversation), understanding how a part of a process fits into the whole, and in guiding/limiting architectural discussions by managing the scope of the problem space under consideration.
This fits very well with my current "staff level" role, but was a real struggle getting to this point.
> This sounds almost Dilbert-esque. It seems like a lot of people here want to be a pointy-haired boss (or pointy-haired tech lead)!
I can see why you'd say that, but I think there's a big difference: PHB was incompetent in addition to having a different role from his team. I've found a sweet spot for myself where I can fill the parts of the "PHB role" well that actually do help the team, but I'm also more than capable of switching contexts and knocking out some tickets when there's a crunch. When I'm especially "in the flow" I work on that sort of stuff and do well. When I'm not, I run interference and keep my team from having to deal with the organizational stuff that doesn't directly help them get their jobs done.
The best functioning teams I've experienced all have one thing in common: they set people up for success by allowing them to do play to their strengths. As a team grows, you can find gaps in those strengths. I see hiring as an opportunity to find someone who is strong in the areas the team is weak. Let the new person come in and do the things they like to do and are good at!
Earlier quoted context omitted.
Given two candidates who can break down problems, I'd prefer to hire the one who can do it with a gun to their head (metaphorically, of course). Lord knows owners, ceos, board members, managers, and angry co workers would often enough like to put a gun to my head.
What's wrong with hiring for interviewers to be this nihlistic.
A perspective from the other side of the desk (playing devil's advocate here): There's a fundamental skill that a good programmer has to have, and that is to be able to take a novel problem that they haven't seen before and break it down to solve it in a sensible way. There are plenty of programmers who fake their way through a career without having that skill. They just copy stuff and never really understand it. The…