3 ms·
I think that's putting the cart before the horse. Every company I've worked for has had a hard enough time just finding people with basic coding literacy. Findi
by ng12 9y ago
I think that's putting the cart before the horse. Every company I've worked for has had a hard enough time just finding people with basic coding literacy. Finding somebody with good problem solving, communication, and programming skills is the hard part -- wondering if that person is the guy to architect a specific aspect of our platform is secondary. I can't speak for that job in particular but if half of your promising-looking candidates are getting weeded out by simple programming puzzles the bar tends to shift.
- bastijn 9y agoIt was meant as an example. If I would interview for an architect I would probably ask such a thing as I need to know if s/he would be capable of thinking ahead and outside of the direct requirements. For an engineer I would ask different questions. However, if I interview them for a job that does not focus on performance or scalability I would rather ask questions based on situations they run into than data structures. Data structures would be a last resort if I had no other options for questions. For most knowing when to use a certain data type is sufficient for me. Like math, I don't need them to give me the full proof of the theorem as long as they know it exists and can apply it in their daily work. That doesn't mean I wouldn't like a candidate who has it all of course. But those are scarce here, and probably everywhere as you mentioned. I am already happy with a person who can do the job s/he was hired for and hopefully more. Again, if you have valid reasons to ask what you ask, do. If not, think again if there are better alternatives is all I advocate.