4 ms·

> Isn't it far more important to know how to design a modern, maintainable, scalable web application? Know how an when to cache stuff. How to design a API. How

> Isn't it far more important to know how to design a modern, maintainable, scalable web application? Know how an when to cache stuff. How to design a API. How do you do that without some basic understanding of computer science-y stuff? How do you define "scalable", how do you measure it? How can you have some intuition about a design before we spend 3 months and many sprints building it first? How do I know when to cache stuff? Does it matter if I have calls to a remote cache in a tight loop? Should I be using an in-process, out-of-process, or remote cache for a particular piece of data? Here's one that comes up A LOT with junior and mid-level developers: floating point numbers aren't magically precise things. There's a balance here, somewhere. I personally would never use the trivia questions in the OP. But the idea that you don't need to know even basic computer science-y type things, seems crazy to me. I can't see myself hiring a computer programmer who is offended by being expected to have a casual acquaintance with computer science.

hack_edu 10y ago
> How do you do that without some basic understanding of computer science-y stuff? > How do you define "scalable", how do you measure it? How can you have some intuition about a design before we spend 3 months and many sprints building it first? > How do I know when to cache stuff? Does it matter if I have calls to a remote cache in a tight loop? Should I be using an in-process, out-of-process, or remote cache for a particular piece of data? You're proving the above poster's exact point. You are putting your weight in applied questions that rest upon the developer's specific experience. This method is the opposite of evaluating people for their ability to memorize a half dozen algorithms and data structures. In my experience interviewing candidates, asking people to implement a caching algorithm is a distraction to both parties. A much better evaluation is their ability to provide box-arrow diagram and talk it through. This is much more effective towards understanding their thought processes and knowledge. It is also much, much closer to the _real_ day to day of a today's engineer: communication, advocacy, and breadth of knowledge. Code is cheap. Business should screen employees for an interest. CS textbook questions introduce enormous amounts of bias, especially in panel interviews. It is a dangerous trap that companies use to further entrench their team cliquiness and departmental monoculture. It is ripe for Simple Sabotage. Simply put, its lazy.
sidlls 10y ago
> How do you do that without some basic understanding of computer science-y stuff? What do you mean by "understand"? In some ways your question is like asking an engineer how he can choose a particular bolt for use in, say, an elevator, without understanding the basics of how the failure characteristics of the bolt are known. There's some relationship there, but is it really an important one? Sometimes it may be. Other times (most times?) probably not. > How do you define "scalable", how do you measure it? How can you have some intuition about a design before we spend 3 months and many sprints building it first? "Scalable" is entirely dependent on the business' needs and plans, and measuring it certainly doesn't require any formal understanding of computer science. This is fairly basic arithmetic. As for the design intuition: computer science-y things are only so useful as far as that goes. Their real utility is in optimization, not designing ahead of time. > I can't see myself hiring a computer programmer who is offended by being expected to have a casual acquaintance with computer science. Well, as you yourself noted, questions of this sort aren't for "casual acquaintance" levels of knowledge. These kinds of exercises are basically things an undergrad (or, in some cases, graduate) student thinks are important because they're all he knows. Incidentally, the fact that interviews focus so much on these kinds of "CS fundamentals" is one reason I chuckle whenever somebody tries to describe these companies' activities as "engineering." Any engineering that goes on in places that put much weight to these kinds of questions, and which isn't interviewing candidates specifically to engage in academic, or close-to-research CS, day-to-day, is usually by accident.

hack_edu 10y ago

> How do you do that without some basic understanding of computer science-y stuff? > How do you define "scalable", how do you measure it? How can you have some intuition about a design before we spend 3 months and many sprints building it first? > How do I know when to cache stuff? Does it matter if I have calls to a remote cache in a tight loop? Should I be using an in-process, out-of-process, or remote cache for a particular piece of data? You're proving the above poster's exact point. You are putting your weight in applied questions that rest upon the developer's specific experience. This method is the opposite of evaluating people for their ability to memorize a half dozen algorithms and data structures. In my experience interviewing candidates, asking people to implement a caching algorithm is a distraction to both parties. A much better evaluation is their ability to provide box-arrow diagram and talk it through. This is much more effective towards understanding their thought processes and knowledge. It is also much, much closer to the _real_ day to day of a today's engineer: communication, advocacy, and breadth of knowledge. Code is cheap. Business should screen employees for an interest. CS textbook questions introduce enormous amounts of bias, especially in panel interviews. It is a dangerous trap that companies use to further entrench their team cliquiness and departmental monoculture. It is ripe for Simple Sabotage. Simply put, its lazy.

sidlls 10y ago

> How do you do that without some basic understanding of computer science-y stuff? What do you mean by "understand"? In some ways your question is like asking an engineer how he can choose a particular bolt for use in, say, an elevator, without understanding the basics of how the failure characteristics of the bolt are known. There's some relationship there, but is it really an important one? Sometimes it may be. Other times (most times?) probably not. > How do you define "scalable", how do you measure it? How can you have some intuition about a design before we spend 3 months and many sprints building it first? "Scalable" is entirely dependent on the business' needs and plans, and measuring it certainly doesn't require any formal understanding of computer science. This is fairly basic arithmetic. As for the design intuition: computer science-y things are only so useful as far as that goes. Their real utility is in optimization, not designing ahead of time. > I can't see myself hiring a computer programmer who is offended by being expected to have a casual acquaintance with computer science. Well, as you yourself noted, questions of this sort aren't for "casual acquaintance" levels of knowledge. These kinds of exercises are basically things an undergrad (or, in some cases, graduate) student thinks are important because they're all he knows. Incidentally, the fact that interviews focus so much on these kinds of "CS fundamentals" is one reason I chuckle whenever somebody tries to describe these companies' activities as "engineering." Any engineering that goes on in places that put much weight to these kinds of questions, and which isn't interviewing candidates specifically to engage in academic, or close-to-research CS, day-to-day, is usually by accident.