4 ms·

Semi off-topic, but i am curious. How much of CS fundamentals do you expect a backend (or fullstack) developer to recite in an job interview? I did all CS theor

Semi off-topic, but i am curious. How much of CS fundamentals do you expect a backend (or fullstack) developer to recite in an job interview? I did all CS theory stuff many years ago at university, but i could not pass a interview test full with these CS basics. 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 to integrate with third party APIs. How to setup logging. How to sanitize data and other common security problems. How to setup test/build/deploy structures. Et cetera, you get the point. If, while building a web application, i encounter a "big data"/"data processing" problem, i will find a appropriate solution using CS best practices. But hell, i would struggle to implement a simple array sorting algorithm under pressure.

thecardcheat 10y ago
What matters is how much the company you want to work for expects you to whiteboard or code to pass their screens. Big company? You almost certainly need to have your CS challenge question toolbox full. Smaller company? Many follow the big company interview methodology, but some don't, so more likely you can get away with not breaking the spine on your Cracking the Coding Interview.
brianwawok 10y ago
I think if you are fresh out of college, cute little algo challenges are OK.. because a) You should have just learned it b) You don't have years of experience with 12 languages Anything past fresh college grad and they are pretty dumb...
stuaxo 10y ago
As a fullstack developer most of these things are not needed. Having a good understanding of what is optimal is good, but you shouldn't have to be able to recite all the big O notation. Funnily enough none of the tests I've had ever talk about relevant things like data normalisation / de-normalisation or anything that will be used in the project.
- collyw 10y ago
  Often if you get your database designed well, then there is no need for lots of code and fancy algorithms.
numbsafari 10y ago
> 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.
- 10y ago

thecardcheat 10y ago

What matters is how much the company you want to work for expects you to whiteboard or code to pass their screens. Big company? You almost certainly need to have your CS challenge question toolbox full. Smaller company? Many follow the big company interview methodology, but some don't, so more likely you can get away with not breaking the spine on your Cracking the Coding Interview.

brianwawok 10y ago

I think if you are fresh out of college, cute little algo challenges are OK.. because a) You should have just learned it b) You don't have years of experience with 12 languages Anything past fresh college grad and they are pretty dumb...

stuaxo 10y ago

As a fullstack developer most of these things are not needed. Having a good understanding of what is optimal is good, but you shouldn't have to be able to recite all the big O notation. Funnily enough none of the tests I've had ever talk about relevant things like data normalisation / de-normalisation or anything that will be used in the project.

collyw 10y ago
Often if you get your database designed well, then there is no need for lots of code and fancy algorithms.

numbsafari 10y ago

> 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.
10y ago