3 added 44 characters in body
source | link

When I'm interviewing, there are two types of questions I focus on:

  • Extent of exposure to the technologies we use. This might involve some very basic/surface level questions for a lot of different topics. This might give me some hints as to how well a candidate can temporarily absorb odd tasks or new technologies at a passable level.
  • Low level knowledge of topics that the candidate has highlighted as having great experience or passion for. If the candidate lists 5+ years of C# experience on their resume but doesn't know how the language works (IL, garbage collection, etc) it would not inspire a lot of confidence in me.

For the purposes of furthering those points, we will often try to ask a combination of closed (point 1) and open-ended (point 2) questions.

If asked an open-ended question, it is perfectly acceptable to elaborate to the extent of your knowledge, example:

Do you know how and where C# datatypes are stored in memory, which datatypes are treated differently?

This is an invitation for you to elaborate and discuss with me, but not a problem per-say. It's your opportunity to show off a bit, and if you seem to know a lot about the topic I might ask some harder / more targeted questions.

What is the default value for the css attribute 'position' and how does it differ from 'position: relative'.

This is a semi-closed question. I'm interested in knowing if you know some of the CSS basics but I'm not looking for an extended discussion about all of the different position types.


One thing you need to avoid at all costs is coming across smug or inquisitive about the knowledge of the interviewer, for instance, in my opinion a very bad answer to the above question might be.

I know all of the css position types,: relative, abs... Do you know about XYZ edge case when relative and absolute are configured in this specific way?

A better way to phrase it would be to say something like:

Yes. The default position is 'static', and it renders elements where they exist in the html - and it does not respect position attributes such as 'left', 'top' on itself or on it's children. I learned a lot about the edge cases about html positioning when i was working on project XYZ at [job/opensource], such as [insert really brief example here].

Basically this answers my question, doesn't inquire as to my own knowledgewithout wasting time, and also gives me the opportunity to ask you more about this if time allows (either now, or later on in the interview)


TL;DR -- In general, I would recommend not to ask questions which inquire as to the knowledge or competencies of the interviewer, and don't try to drive the interview. In some cases, they will be following a script and will not take kindly to deviations. Try to find opportunities to let your interviewer know that you are passionate or really knowledgeable about a specific subject. If they have time and are interested in knowing, they will pick up on this and ask you more about it. If they ran out of time because you were talking too much it reflects poorly on you and some people will take offence to you asking questions about their knowledge.

Also, everyone who does interviews may have a different opinion to mine. This is just general advice I would give to my own candidates.

When I'm interviewing, there are two types of questions I focus on:

  • Extent of exposure to the technologies we use. This might involve some very basic/surface level questions for a lot of different topics. This might give me some hints as to how well a candidate can temporarily absorb odd tasks or new technologies at a passable level.
  • Low level knowledge of topics that the candidate has highlighted as having great experience or passion for. If the candidate lists 5+ years of C# experience on their resume but doesn't know how the language works (IL, garbage collection, etc) it would not inspire a lot of confidence in me.

For the purposes of furthering those points, we will often try to ask a combination of closed (point 1) and open-ended (point 2) questions.

If asked an open-ended question, it is perfectly acceptable to elaborate to the extent of your knowledge, example:

Do you know how and where C# datatypes are stored in memory, which datatypes are treated differently?

This is an invitation for you to elaborate and discuss with me, but not a problem per-say. It's your opportunity to show off a bit, and if you seem to know a lot about the topic I might ask some harder / more targeted questions.

What is the default value for the css attribute 'position' and how does it differ from 'position: relative'.

This is a semi-closed question. I'm interested in knowing if you know some of the CSS basics but I'm not looking for an extended discussion about all of the different position types.


One thing you need to avoid at all costs is coming across smug or inquisitive about the knowledge of the interviewer, for instance, a very bad answer to the above question might be.

I know all of the css position types, relative, abs... Do you know about XYZ edge case when relative and absolute are configured in this specific way?

A better way to phrase it would be to say something like:

Yes. The default position is 'static', and it renders elements where they exist in the html - and it does not respect position attributes such as 'left', 'top' on itself or on it's children. I learned a lot about the edge cases about html positioning when i was working on project XYZ at [job/opensource], such as [insert really brief example here].

Basically this answers my question, doesn't inquire as to my own knowledge, and also gives me the opportunity to ask you more about this if time allows (either now, or later on in the interview)


TL;DR -- In general, I would recommend not to ask questions which inquire as to the knowledge of the interviewer, and don't try to drive the interview. Try to find opportunities to let your interviewer know that you are passionate or really knowledgeable about a specific subject. If they have time and are interested in knowing, they will pick up on this and ask you more about it. If they ran out of time because you were talking too much it reflects poorly on you and some people will take offence to you asking questions about their knowledge.

Also, everyone who does interviews may have a different opinion to mine. This is just general advice I would give to my own candidates.

When I'm interviewing, there are two types of questions I focus on:

  • Extent of exposure to the technologies we use. This might involve some very basic/surface level questions for a lot of different topics. This might give me some hints as to how well a candidate can temporarily absorb odd tasks or new technologies at a passable level.
  • Low level knowledge of topics that the candidate has highlighted as having great experience or passion for. If the candidate lists 5+ years of C# experience on their resume but doesn't know how the language works (IL, garbage collection, etc) it would not inspire a lot of confidence in me.

For the purposes of furthering those points, we will often try to ask a combination of closed (point 1) and open-ended (point 2) questions.

If asked an open-ended question, it is perfectly acceptable to elaborate to the extent of your knowledge, example:

Do you know how and where C# datatypes are stored in memory, which datatypes are treated differently?

This is an invitation for you to elaborate and discuss with me, but not a problem per-say. It's your opportunity to show off a bit, and if you seem to know a lot about the topic I might ask some harder / more targeted questions.

What is the default value for the css attribute 'position' and how does it differ from 'position: relative'.

This is a semi-closed question. I'm interested in knowing if you know some of the CSS basics but I'm not looking for an extended discussion about all of the different position types.


One thing you need to avoid at all costs is coming across smug, for instance, in my opinion a very bad answer to the above question might be.

I know all of the css position types: relative, abs... Do you know about XYZ edge case when relative and absolute are configured in this specific way?

A better way to phrase it would be to say something like:

Yes. The default position is 'static', and it renders elements where they exist in the html - and it does not respect position attributes such as 'left', 'top' on itself or on it's children. I learned a lot about the edge cases about html positioning when i was working on project XYZ at [job/opensource], such as [insert really brief example here].

Basically this answers my question, without wasting time, and also gives me the opportunity to ask you more about this if time allows (either now, or later on in the interview)


TL;DR -- In general, I would recommend not to ask questions which inquire as to the knowledge or competencies of the interviewer, and don't try to drive the interview. In some cases, they will be following a script and will not take kindly to deviations. Try to find opportunities to let your interviewer know that you are passionate or really knowledgeable about a specific subject. If they have time and are interested in knowing, they will pick up on this and ask you more about it. If they ran out of time because you were talking too much it reflects poorly on you and some people will take offence to you asking questions about their knowledge.

Also, everyone who does interviews may have a different opinion to mine. This is just general advice I would give to my own candidates.

2 added 141 characters in body
source | link

When I'm interviewing, there are two types of questions I focus on:

  • Extent of exposure to the technologies we use. This might involve some very basic/surface level questions for a lot of different topics. This might give me some hints as to how well a candidate can temporarily absorb odd tasks or new technologies at a passable level.
  • Low level knowledge of topics that the candidate has highlighted as having great experience or passion for. If the candidate lists 5+ years of C# experience on their resume but doesn't know how the language works (IL, garbage collection, etc) it would not inspire a lot of confidence in me.

For the purposes of furthering those points, we will often try to ask a combination of closed (point 1) and open-ended (point 2) questions.

If asked an open-ended question, it is perfectly acceptable to elaborate to the extent of your knowledge, example:

Do you know how and where C# datatypes are stored in memory, which datatypes are treated differently?

This is an invitation for you to elaborate and discuss with me, but not a problem per-say. It's your opportunity to show off a bit, and if you seem to know a lot about the topic I might ask some harder / more targeted questions.

What is the default value for the css attribute 'position' and how does it differ from 'position: relative'.

This is a semi-closed question. I'm interested in knowing if you know some of the CSS basics but I'm not looking for an extended discussion about all of the different position types.


One thing you need to avoid at all costs is coming across smug or inquisitive about the knowledge of the interviewer, for instance, a very bad answer to the above question might be.

I know all of the css position types, relative, abs... Do you know about XYZ edge case when relative and absolute are configured in this specific way?

A better way to phrase it would be to say something like:

Yes. The default position is 'static', and it renders elements where they exist in the html - and it does not respect position attributes such as 'left', 'top' on itself or on it's children. I learned a lot about the edge cases about html positioning when i was working on project XYZ at [job/opensource], such as [insert really brief example here].

Basically this answers my question, doesn't inquire as to my own knowledge, and also gives me the opportunity to ask you more about this if time allows (either now, or later on in the interview)


TL;DR -- In general, don'tI would recommend not to ask questions which inquire as to the knowledge of the interviewer, and don't try to drive the interview. Answer the questions in a friendly way, and tryTry to find opportunities to let your interviewer know that you are passionate or really knowledgeable about a specific subject. If they have time and are interested in knowing, they will pick up on this and ask you more about it. If they ran out of time because you were talking too much it reflects poorly on you and some people will take offence to you asking questions about their knowledge.

Also, everyone who does interviews may have a different opinion to mine. This is just general advice I would give to my own candidates.

When I'm interviewing, there are two types of questions I focus on:

  • Extent of exposure to the technologies we use. This might involve some very basic/surface level questions for a lot of different topics. This might give me some hints as to how well a candidate can temporarily absorb odd tasks or new technologies at a passable level.
  • Low level knowledge of topics that the candidate has highlighted as having great experience or passion for. If the candidate lists 5+ years of C# experience on their resume but doesn't know how the language works (IL, garbage collection, etc) it would not inspire a lot of confidence in me.

For the purposes of furthering those points, we will often try to ask a combination of closed (point 1) and open-ended (point 2) questions.

If asked an open-ended question, it is perfectly acceptable to elaborate to the extent of your knowledge, example:

Do you know how and where C# datatypes are stored in memory, which datatypes are treated differently?

This is an invitation for you to elaborate and discuss with me, but not a problem per-say. It's your opportunity to show off a bit, and if you seem to know a lot about the topic I might ask some harder / more targeted questions.

What is the default value for the css attribute 'position' and how does it differ from 'position: relative'.

This is a semi-closed question. I'm interested in knowing if you know some of the CSS basics but I'm not looking for an extended discussion about all of the different position types.


One thing you need to avoid at all costs is coming across smug or inquisitive about the knowledge of the interviewer, for instance, a very bad answer to the above question might be.

I know all of the css position types, relative, abs... Do you know about XYZ edge case when relative and absolute are configured in this specific way?

A better way to phrase it would be to say something like:

Yes. The default position is 'static', and it renders elements where they exist in the html - and it does not respect position attributes such as 'left', 'top' on itself or on it's children. I learned a lot about the edge cases about html positioning when i was working on project XYZ at [job/opensource], such as [insert really brief example here].

Basically this answers my question, doesn't inquire as to my own knowledge, and also gives me the opportunity to ask you more about this if time allows (either now, or later on in the interview)


TL;DR -- In general, don't ask questions which inquire as to the knowledge of the interviewer, and don't try to drive the interview. Answer the questions in a friendly way, and try to find opportunities to let your interviewer know that you are passionate or really knowledgeable about a specific subject. If they have time and are interested in knowing, they will pick up on this and ask you more about it.

Also, everyone who does interviews may have a different opinion to mine. This is just general advice I would give to my own candidates.

When I'm interviewing, there are two types of questions I focus on:

  • Extent of exposure to the technologies we use. This might involve some very basic/surface level questions for a lot of different topics. This might give me some hints as to how well a candidate can temporarily absorb odd tasks or new technologies at a passable level.
  • Low level knowledge of topics that the candidate has highlighted as having great experience or passion for. If the candidate lists 5+ years of C# experience on their resume but doesn't know how the language works (IL, garbage collection, etc) it would not inspire a lot of confidence in me.

For the purposes of furthering those points, we will often try to ask a combination of closed (point 1) and open-ended (point 2) questions.

If asked an open-ended question, it is perfectly acceptable to elaborate to the extent of your knowledge, example:

Do you know how and where C# datatypes are stored in memory, which datatypes are treated differently?

This is an invitation for you to elaborate and discuss with me, but not a problem per-say. It's your opportunity to show off a bit, and if you seem to know a lot about the topic I might ask some harder / more targeted questions.

What is the default value for the css attribute 'position' and how does it differ from 'position: relative'.

This is a semi-closed question. I'm interested in knowing if you know some of the CSS basics but I'm not looking for an extended discussion about all of the different position types.


One thing you need to avoid at all costs is coming across smug or inquisitive about the knowledge of the interviewer, for instance, a very bad answer to the above question might be.

I know all of the css position types, relative, abs... Do you know about XYZ edge case when relative and absolute are configured in this specific way?

A better way to phrase it would be to say something like:

Yes. The default position is 'static', and it renders elements where they exist in the html - and it does not respect position attributes such as 'left', 'top' on itself or on it's children. I learned a lot about the edge cases about html positioning when i was working on project XYZ at [job/opensource], such as [insert really brief example here].

Basically this answers my question, doesn't inquire as to my own knowledge, and also gives me the opportunity to ask you more about this if time allows (either now, or later on in the interview)


TL;DR -- In general, I would recommend not to ask questions which inquire as to the knowledge of the interviewer, and don't try to drive the interview. Try to find opportunities to let your interviewer know that you are passionate or really knowledgeable about a specific subject. If they have time and are interested in knowing, they will pick up on this and ask you more about it. If they ran out of time because you were talking too much it reflects poorly on you and some people will take offence to you asking questions about their knowledge.

Also, everyone who does interviews may have a different opinion to mine. This is just general advice I would give to my own candidates.

1
source | link

When I'm interviewing, there are two types of questions I focus on:

  • Extent of exposure to the technologies we use. This might involve some very basic/surface level questions for a lot of different topics. This might give me some hints as to how well a candidate can temporarily absorb odd tasks or new technologies at a passable level.
  • Low level knowledge of topics that the candidate has highlighted as having great experience or passion for. If the candidate lists 5+ years of C# experience on their resume but doesn't know how the language works (IL, garbage collection, etc) it would not inspire a lot of confidence in me.

For the purposes of furthering those points, we will often try to ask a combination of closed (point 1) and open-ended (point 2) questions.

If asked an open-ended question, it is perfectly acceptable to elaborate to the extent of your knowledge, example:

Do you know how and where C# datatypes are stored in memory, which datatypes are treated differently?

This is an invitation for you to elaborate and discuss with me, but not a problem per-say. It's your opportunity to show off a bit, and if you seem to know a lot about the topic I might ask some harder / more targeted questions.

What is the default value for the css attribute 'position' and how does it differ from 'position: relative'.

This is a semi-closed question. I'm interested in knowing if you know some of the CSS basics but I'm not looking for an extended discussion about all of the different position types.


One thing you need to avoid at all costs is coming across smug or inquisitive about the knowledge of the interviewer, for instance, a very bad answer to the above question might be.

I know all of the css position types, relative, abs... Do you know about XYZ edge case when relative and absolute are configured in this specific way?

A better way to phrase it would be to say something like:

Yes. The default position is 'static', and it renders elements where they exist in the html - and it does not respect position attributes such as 'left', 'top' on itself or on it's children. I learned a lot about the edge cases about html positioning when i was working on project XYZ at [job/opensource], such as [insert really brief example here].

Basically this answers my question, doesn't inquire as to my own knowledge, and also gives me the opportunity to ask you more about this if time allows (either now, or later on in the interview)


TL;DR -- In general, don't ask questions which inquire as to the knowledge of the interviewer, and don't try to drive the interview. Answer the questions in a friendly way, and try to find opportunities to let your interviewer know that you are passionate or really knowledgeable about a specific subject. If they have time and are interested in knowing, they will pick up on this and ask you more about it.

Also, everyone who does interviews may have a different opinion to mine. This is just general advice I would give to my own candidates.