• Can you write working code?

This is of course assuming you're actually asked to write actual code in the interview (white-board style).

This isn't so much about not even having a single typo in your code, but more about just knowing what basic constructs like for-loops look like, knowing how to put the bits together and proving that you've actually written a bit of code in a language to know most of the most common methods / classes (apparently interviewers have a bit of a problem with candidates that can't even pass the fizz buzz test).

• Can you think through a problem?

This definitely doesn't just apply to algorithms.

You need to be able to understand the problem, analyse the requirements, pick appropriate data structures and algorithms, write the code / walk through the approach, and analyse it - that's required for many / most (non-bug-fix) programming tasks.

• Can you communicate well (about programming)?

Do you understand the problem as described?

Do you ask for clarification when required?

Can you explain the high-level approach before you start writing the code?

Are you able to explain your code after the fact?

The ability to communicate well is important in your day-to-day job as a programmer.

Your boss shouldn't be concerned that you're not going to be able to understand the explanation of a problem, not ask for clarification when things are unclear (and just make some radical assumptions), have no ability to walk through how you're planning to solve any given problem and/or have no ability to explain code you've written to anyone else.

• Do you have a decent knowledge of data structures and algorithms?

While you may be asked about an advanced data structure or algorithm that you'll never use, knowledge of this data structure may be a fairly accurate indicator that you know pretty much all the basic ones quite well.

I'm also fairly sure you can stick to simple data structures or algorithms (linked-list, array, binary search tree, binary search, etc.) in many cases and still do well in this specific aspect - while an advanced data structure or algorithm may be better suited to solve the problem at hand, you could often fairly efficiently solve the problem with a combination of basic ones - there's still picking between them based on appropriateness and combining them appropriately.

And you definitely need a decent knowledge of data structures and algorithms - you can't be good at what you do if you don't know when to use which tools in your toolbox.

• Can you analyse time and space complexity and make choices that minimizes them?

Any data structure or algorithm question should involve complexity, and it will be very significant to your day-to-day job - no-one wants you write code that endlessly does linear search through a large unchanging array because you don't know what's going on on the low level.

• Can you write working code?

This is of course assuming you're actually asked to write actual code in the interview (white-board style).

This isn't so much about not even having a single typo in your code, but more about just knowing what basic constructs like for-loops look like, knowing how to put the bits together and proving that you've actually written a bit of code in a language to know most of the most common methods / classes (apparently interviewers have a bit of a problem with candidates that can't even pass the fizz buzz test).

• Can you think through a problem?

This definitely doesn't just apply to algorithms.

You need to be able to understand the problem, analyse the requirements, pick appropriate data structures and algorithms, write the code / walk through the approach, and analyse it - that's required for many / most (non-bug-fix) programming tasks.

• Can you communicate well (about programming)?

Do you understand the problem as described?

Do you ask for clarification when required?

Can you explain the high-level approach before you start writing the code?

Are you able to explain your code after the fact?

The ability to communicate well is important in your day-to-day job as a programmer.

Your boss shouldn't be concerned that you're not going to be able to understand the explanation of a problem, not ask for clarification when things are unclear (and just make some radical assumptions), have no ability to walk through how you're planning to solve any given problem and/or have no ability to explain code you've written to anyone else.

• Do you have a decent knowledge of data structures and algorithms?

While you may be asked about an advanced data structure or algorithm that you'll never use, knowledge of this data structure may be a fairly accurate indicator that you know pretty much all the basic ones quite well.

I'm also fairly sure you can stick to simple data structures or algorithms (linked-list, array, binary search tree, binary search, etc.) in many cases and still do well in this specific aspect - while an advanced data structure or algorithm may be better suited to solve the problem at hand, you could often fairly efficiently solve the problem with a combination of basic ones - there's still picking between them based on appropriateness and combining them appropriately.

And you definitely need a decent knowledge of data structures and algorithms - you can't be good at what you do if you don't know when to use which tools in your toolbox.

• Can you analyse time and space complexity and weigh choices up against each other with them in mind, making the most appropriate choice for the situation?

Any data structure or algorithm question should involve complexity, and it will be very significant to your day-to-day job - no-one wants you to, for example, write code that endlessly does linear search through a large unchanging array because you don't know what's going on on the low level.

• Can you write working code?

This is of course assuming you're actually asked to write actual code in the interview (white-board style).

This isn't so much about not even having a single typo in your code, but more about just knowing what basic constructs like for-loops look like, knowing how to put the bits together and proving that you've actually written a bit of code in a language to know most of the most common methods / classes (apparently interviewers have a bit of a problem with candidates that can't even pass the fizz buzz test).

• Can you think through a problem?

This definitely doesn't just apply to algorithms.

You need to be able to understand the problem, analyse the requirements, pick appropriate data structures and algorithms, write the code / walk through the approach, and analyse it - that's required for many / most (non-bug-fix) programming tasks.

• Can you communicate well (about programming)?

Do you understand the problem as described?

Do you ask for clarification when required?

Can you explain the high-level approach before you start writing the code?

Are you able to explain your code after the fact?

The ability to communicate well is important in your day-to-day job as a programmer.

Your boss shouldn't be concerned that you're not going to be able to understand an explanation of a problem, ask for clarification when things are unclear (and just make some radical assumptions), have no ability to walk through how you're planning to solve any given problem and/or have no ability to explain code you've written to anyone else.

• Do you have a decent knowledge of data structures and algorithms?

While you may be asked about an advanced data structure or algorithm that you'll never use, knowledge of this data structure may be a fairly accurate indicator that you know pretty much all the basic ones quite well.

I'm also fairly sure you can stick to simple data structures or algorithms (linked-list, array, binary search tree, binary search, etc.) in many cases and still do well in this specific aspect - while an advanced data structure or algorithm may be better suited to solve the problem at hand, you could often fairly efficiently solve the problem with a combination of basic ones - there's still picking between them based on appropriateness and combining them appropriately.

And you definitely need a decent knowledge of data structures and algorithms - you can't be good at what you do if you don't know when to use which tools in your toolbox.

• Can you analyse time and space complexity and make choices that minimizes them?

Any data structure or algorithm question should involve complexity, and it will be very significant to your day-to-day job - no-one wants you write code that endlessly does linear search through a large unchanging array because you don't know what's going on on the low level.

• Can you write working code?

This is of course assuming you're actually asked to write actual code in the interview (white-board style).

This isn't so much about not even having a single typo in your code, but more about just knowing what basic constructs like for-loops look like, knowing how to put the bits together and proving that you've actually written a bit of code in a language to know most of the most common methods / classes (apparently interviewers have a bit of a problem with candidates that can't even pass the fizz buzz test).

• Can you think through a problem?

This definitely doesn't just apply to algorithms.

You need to be able to understand the problem, analyse the requirements, pick appropriate data structures and algorithms, write the code / walk through the approach, and analyse it - that's required for many / most (non-bug-fix) programming tasks.

• Can you communicate well (about programming)?

Do you understand the problem as described?

Do you ask for clarification when required?

Can you explain the high-level approach before you start writing the code?

Are you able to explain your code after the fact?

The ability to communicate well is important in your day-to-day job as a programmer.

Your boss shouldn't be concerned that you're not going to be able to understand the explanation of a problem, not ask for clarification when things are unclear (and just make some radical assumptions), have no ability to walk through how you're planning to solve any given problem and/or have no ability to explain code you've written to anyone else.

• Do you have a decent knowledge of data structures and algorithms?

While you may be asked about an advanced data structure or algorithm that you'll never use, knowledge of this data structure may be a fairly accurate indicator that you know pretty much all the basic ones quite well.

I'm also fairly sure you can stick to simple data structures or algorithms (linked-list, array, binary search tree, binary search, etc.) in many cases and still do well in this specific aspect - while an advanced data structure or algorithm may be better suited to solve the problem at hand, you could often fairly efficiently solve the problem with a combination of basic ones - there's still picking between them based on appropriateness and combining them appropriately.

And you definitely need a decent knowledge of data structures and algorithms - you can't be good at what you do if you don't know when to use which tools in your toolbox.

• Can you analyse time and space complexity and make choices that minimizes them?

Any data structure or algorithm question should involve complexity, and it will be very significant to your day-to-day job - no-one wants you write code that endlessly does linear search through a large unchanging array because you don't know what's going on on the low level.