I can see this for a team of interns on a summer project, but not senior devs that don’t really get stuck that often, or know to involve someone for the brief periods where they need a second set of eyes.
I spend most of my time in Go these days, and find that it's goroutine model is perfectly suited for both I/O and CPU-bound services. The runtime decides if a thread is needed, and will spawn one any time you're waiting on a syscall.
I spend most of my time in Go these days, and find that it's goroutine model is perfectly suited for both I/O and CPU-bound services. The runtime decides if a thread is needed, and will spawn one any time you're waiting on a syscall.
Wouldn't you agree that a compiled language is typically much easier to maintain than an interpreted one (refactoring, etc). Also, it's been years since I've worked in C#, but I would imagine you could stay in the language but ditch the frameworks.
Agree. I like Go for the same reason. With Java, there's a weird pressure to spend a week designing class hierarchies and to set up all the factories and abstract factories. In Go - uh, you can do it, but you're going against the grain.
Yeah. You can save a lot of your time, and the candidates' time with a simple coding interview - even FizzBuzz will knock out half of the candidates. Then pair up and/or give a take-home, then discuss the solution in a one-on-one session.
Coding interviews are very stressful, and churn through a lot of really awesome potential hires. I imagine there are tons of false negatives, but it's nearly impossible for a terrible programmer to get through a gauntlet of programming interviews. However, I agree. They don't give a full picture of a developer's abilities.
As a developer, I prefer take-home projects. As an interviewer, I prefer a few coding interviews, followed by a take-home project.