How to prepare for interview during technical round in Software Industry [closed]

.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;

up vote
-2
down vote

favorite

One of my friends younger brother asked me a question and I am writing this question in his words

His Question :-
Hi. I am a Senior software engineer in my company with IT experience of more than 5 years. I want to know how normally guys in software industry prepare for their interview. Reason behind this is there can be thousands of questions if interview is on any technology such as Java and DotNet and all this concepts are scattered in different books.

If any interview is scheduled and than I try to read this books than it takes lot of time to read all this concepts and if another interview is after 1-2 week than I normally forget atleast 50% part of what I read and I need to start it again.

My Answer :-
I told him that I normally search interview related questions in Google and while looking for answer I also start to make notes of this questions and answer in very short words and whenever I have any interview I follow the same process and it will help me to reduce the time and efforts required for preparing interview as normally if we are not working in certain concept of technologies than we normally start to forget it.

It was my answer to his question but want to know what normally other software professional do in such condition when they also face same situation

asked Dec 8 '13 at 15:25

kulwal_amit

2851311

closed as too broad by Jim G., jcmeloni, user8365, gnat, CMW Dec 9 '13 at 9:19

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

I have to agree with most answers that you can't prepare on short notice. However, this may come in handy: programmers.stackexchange.com/questions/135170/â€¦ ("The Joel Test's equivalent for measuring a programmer")
â€“Â Jan Doggen
Dec 9 '13 at 8:14

add a commentÂ |Â

up vote
-2
down vote

favorite

One of my friends younger brother asked me a question and I am writing this question in his words

It was my answer to his question but want to know what normally other software professional do in such condition when they also face same situation

asked Dec 8 '13 at 15:25

kulwal_amit

2851311

closed as too broad by Jim G., jcmeloni, user8365, gnat, CMW Dec 9 '13 at 9:19

I have to agree with most answers that you can't prepare on short notice. However, this may come in handy: programmers.stackexchange.com/questions/135170/â€¦ ("The Joel Test's equivalent for measuring a programmer")
â€“Â Jan Doggen
Dec 9 '13 at 8:14

add a commentÂ |Â

up vote
-2
down vote

favorite

One of my friends younger brother asked me a question and I am writing this question in his words

It was my answer to his question but want to know what normally other software professional do in such condition when they also face same situation

asked Dec 8 '13 at 15:25

kulwal_amit

2851311

One of my friends younger brother asked me a question and I am writing this question in his words

It was my answer to his question but want to know what normally other software professional do in such condition when they also face same situation

asked Dec 8 '13 at 15:25

kulwal_amit

2851311

asked Dec 8 '13 at 15:25

kulwal_amit

2851311

asked Dec 8 '13 at 15:25

kulwal_amit

2851311

asked Dec 8 '13 at 15:25

kulwal_amit

2851311

closed as too broad by Jim G., jcmeloni, user8365, gnat, CMW Dec 9 '13 at 9:19

I have to agree with most answers that you can't prepare on short notice. However, this may come in handy: programmers.stackexchange.com/questions/135170/â€¦ ("The Joel Test's equivalent for measuring a programmer")
â€“Â Jan Doggen
Dec 9 '13 at 8:14

add a commentÂ |Â

I have to agree with most answers that you can't prepare on short notice. However, this may come in handy: programmers.stackexchange.com/questions/135170/â€¦ ("The Joel Test's equivalent for measuring a programmer")
â€“Â Jan Doggen
Dec 9 '13 at 8:14

I have to agree with most answers that you can't prepare on short notice. However, this may come in handy: programmers.stackexchange.com/questions/135170/â€¦ ("The Joel Test's equivalent for measuring a programmer")
â€“Â Jan Doggen
Dec 9 '13 at 8:14

add a commentÂ |Â

4 Answers
4

active

oldest

votes

up vote
4
down vote

I don't prepare for my technical interview. The entire point of the interview process is to gauge if you're capable of doing the job. This goes both ways - the company wants an employee capable of doing the work, and you want a job that is challenging without setting you up for failure.

"Cramming" for an interview (if successful) defeats this idea. The company can't get a good gauge on your real skills, and you're setting yourself up for failure by representing skills you don't really have.

But that assumes you can be successful. I would argue that providing canned, textbook answers to technical questions isn't the best way to "pass" a technical interview. You need to know how things work, why they work, and sell that you actually know what the hell you're talking about. That only comes with experience.

If you're concerned about not knowing something, don't worry - nobody knows everything and "knowing what you know" is a valuable trait in and of itself. "I don't know" is a far better answer than trying to bullshit your interviewers.

edited Dec 9 '13 at 4:02

ContextSwitch

1033

answered Dec 8 '13 at 17:20

Telastyn

33.9k977120

add a commentÂ |Â

up vote
0
down vote

I have had a whole string of interviews where people asked me various 'trick questions', and I never got any of them right, and they concluded I didn't know anything. These things had to do with the difference between 'int' and 'int?', Singletons, Boxing and Unboxing, etc. I would flunk out as unqualified even though I've been making a living as a programmer since the late 1970s. In retrospect, I realized that the interviewers didn't know what they were doing.

The questions your interviewer should be asking are 'what problems did you solve?'. In my case this would run to scheduling production in a food packing plant or reverse engineering the record and field structures of binary flat files from 20 year old financial applications. These would progress to the respective technologies, which in my case was Access 2000 and SQL Server 2000, and C# and PostGreSQL. They could drill into areas that are of particular utility to them - they might find there's something you don't understand, but what you do understand is so close that a few minutes of reading will make up the difference.

answered Dec 8 '13 at 22:04

Meredith Poor

8,8661730

1

...except there's a huge difference between int and int?. People do in depth technical interviews to see if you really solved the problem or if you learned just enough to build a hacky, fragile solution that couldn't stand the test of time. (I don't necessarily mean you in particular - there's certainly not enough in answers to say, or mean for this to seem too harsh, I've been working with and interviewing a lot of people with 'shallow' knowledge as of late).
â€“Â Telastyn
Dec 8 '13 at 22:16

@Telastyn - Shallow in what respect? I have friends that have entered the workforce in the last few years, and have been handed "compose eMail HTML with Javascript driven buttons so the customers can link to the right place in the site". In short, they're handed responsibility for shallow tasks, so they don't really drill into databases, business rules, web services, etc. We're seeing vast amounts of compartmentalization, which makes developers productive quickly, but immediately casts them in 'slots'. Pretty nasty, and dangerous for everyone involved.
â€“Â Meredith Poor
Dec 8 '13 at 22:22

Bleh, that is no good. When I talk about shallow here, I mean people who have learned just enough to solve the problem at hand. Because of that, they don't have in depth knowledge of their primary language, or modern development techniques, or really anything beyond the horizon of their day to day problems. And because of that, the day to day problems are more frequent, and expensively solved than if they knew what tools were available in the first place.
â€“Â Telastyn
Dec 8 '13 at 22:51

1

@Telastyn - In the real world, most developers have learned 'just enough' to solve the problem at hand. I could expand on this in lengthy detail, but it basically boils down to the fact that at any particular moment one has an issue in front of them and time is short. There are people that spend four years in school getting degrees and they learned some 'more advanced techniques', and others are periodically sent out to training to learn new methodologies. For the most part, however, these are luxuries. If you want someone to do it a particular way, ask them to learn it.
â€“Â Meredith Poor
Dec 8 '13 at 23:01

2

I'm sorry, I don't see being competent as a luxury. I am currently a tech lead - I do not and can not have the time to analyze each individual problem to tell professional programmers how best to solve it. Sharpening the saw isn't a luxury, it's vital to success in any career.
â€“Â Telastyn
Dec 8 '13 at 23:59

add a commentÂ |Â

up vote
0
down vote

If the interview focuses on the syntax of a programming language, rather than the semantics of problem solving, that is a red flag for me. I take that as a sign that they are looking short-term and are not interested in thinking about the problem space and dive right into the solution space.

Yes, you should be able to speak knowledgeably and in-depth about technical matters, but competent interviewers should be able to elicit that information from you in the course of asking broader questions about how to solve problems.

answered Dec 9 '13 at 1:40

KevDog

933157

add a commentÂ |Â

up vote
0
down vote

As with so many things, you're going to get out what you put in. If you're trying to read a book in preparation for one interview, and then read another book for a different interview 1-2 weeks later, then you're doing something wrong. Unless you've been severely lax in your current position (or the caveat below applies), you shouldn't need to do much technical "brushing up" to interview well. In this case, your friend is a senior software engineer with 5 years experience... if he didn't learn it in the last 5 years, then another 1-2 weeks shouldn't make a big difference.

There's a couple caveats to this:

If you're trying to make a "jump" (to a different role, like manager, or to a different technology stack, or to a different domain). In this case, the whole point is that the last 5 years don't apply as well as you might like. So you should be studying that role, technology stack, or domain. But since you're make a jump in a particular direction, all of your studying should apply to all of your upcoming interviews. (Implicit in this is that you're making a directed jump, and not a "anywhere but here" jump.)

Interviewing skills probably weren't key to your job for the last 5 years, so it makes sense to brush up on those. Writing code on a whiteboard, explaining things to people who are judging your ability to explain without actually participating in depth, stupid puzzles, etc. are all things that are much more common in interviews than on the job. So studying those things doesn't hurt. But again, you shouldn't have to study different things for different interviews.

answered Dec 9 '13 at 2:53

Tom Panning

41424

add a commentÂ |Â

4 Answers
4

active

oldest

votes

4 Answers
4

active

oldest

votes

up vote
4
down vote

edited Dec 9 '13 at 4:02

ContextSwitch

1033

answered Dec 8 '13 at 17:20

Telastyn

33.9k977120

add a commentÂ |Â

up vote
4
down vote

edited Dec 9 '13 at 4:02

ContextSwitch

1033

answered Dec 8 '13 at 17:20

Telastyn

33.9k977120

add a commentÂ |Â

up vote
4
down vote

edited Dec 9 '13 at 4:02

ContextSwitch

1033

answered Dec 8 '13 at 17:20

Telastyn

33.9k977120

edited Dec 9 '13 at 4:02

ContextSwitch

1033

answered Dec 8 '13 at 17:20

Telastyn

33.9k977120

edited Dec 9 '13 at 4:02

ContextSwitch

1033

edited Dec 9 '13 at 4:02

ContextSwitch

1033

edited Dec 9 '13 at 4:02

ContextSwitch

1033

answered Dec 8 '13 at 17:20

Telastyn

33.9k977120

answered Dec 8 '13 at 17:20

Telastyn

33.9k977120

answered Dec 8 '13 at 17:20

Telastyn

33.9k977120

add a commentÂ |Â

up vote
0
down vote

answered Dec 8 '13 at 22:04

Meredith Poor

8,8661730

1

...except there's a huge difference between int and int?. People do in depth technical interviews to see if you really solved the problem or if you learned just enough to build a hacky, fragile solution that couldn't stand the test of time. (I don't necessarily mean you in particular - there's certainly not enough in answers to say, or mean for this to seem too harsh, I've been working with and interviewing a lot of people with 'shallow' knowledge as of late).
â€“Â Telastyn
Dec 8 '13 at 22:16

@Telastyn - Shallow in what respect? I have friends that have entered the workforce in the last few years, and have been handed "compose eMail HTML with Javascript driven buttons so the customers can link to the right place in the site". In short, they're handed responsibility for shallow tasks, so they don't really drill into databases, business rules, web services, etc. We're seeing vast amounts of compartmentalization, which makes developers productive quickly, but immediately casts them in 'slots'. Pretty nasty, and dangerous for everyone involved.
â€“Â Meredith Poor
Dec 8 '13 at 22:22

Bleh, that is no good. When I talk about shallow here, I mean people who have learned just enough to solve the problem at hand. Because of that, they don't have in depth knowledge of their primary language, or modern development techniques, or really anything beyond the horizon of their day to day problems. And because of that, the day to day problems are more frequent, and expensively solved than if they knew what tools were available in the first place.
â€“Â Telastyn
Dec 8 '13 at 22:51

1

@Telastyn - In the real world, most developers have learned 'just enough' to solve the problem at hand. I could expand on this in lengthy detail, but it basically boils down to the fact that at any particular moment one has an issue in front of them and time is short. There are people that spend four years in school getting degrees and they learned some 'more advanced techniques', and others are periodically sent out to training to learn new methodologies. For the most part, however, these are luxuries. If you want someone to do it a particular way, ask them to learn it.
â€“Â Meredith Poor
Dec 8 '13 at 23:01

2

I'm sorry, I don't see being competent as a luxury. I am currently a tech lead - I do not and can not have the time to analyze each individual problem to tell professional programmers how best to solve it. Sharpening the saw isn't a luxury, it's vital to success in any career.
â€“Â Telastyn
Dec 8 '13 at 23:59

add a commentÂ |Â

up vote
0
down vote

answered Dec 8 '13 at 22:04

Meredith Poor

8,8661730

1

...except there's a huge difference between int and int?. People do in depth technical interviews to see if you really solved the problem or if you learned just enough to build a hacky, fragile solution that couldn't stand the test of time. (I don't necessarily mean you in particular - there's certainly not enough in answers to say, or mean for this to seem too harsh, I've been working with and interviewing a lot of people with 'shallow' knowledge as of late).
â€“Â Telastyn
Dec 8 '13 at 22:16

@Telastyn - Shallow in what respect? I have friends that have entered the workforce in the last few years, and have been handed "compose eMail HTML with Javascript driven buttons so the customers can link to the right place in the site". In short, they're handed responsibility for shallow tasks, so they don't really drill into databases, business rules, web services, etc. We're seeing vast amounts of compartmentalization, which makes developers productive quickly, but immediately casts them in 'slots'. Pretty nasty, and dangerous for everyone involved.
â€“Â Meredith Poor
Dec 8 '13 at 22:22

Bleh, that is no good. When I talk about shallow here, I mean people who have learned just enough to solve the problem at hand. Because of that, they don't have in depth knowledge of their primary language, or modern development techniques, or really anything beyond the horizon of their day to day problems. And because of that, the day to day problems are more frequent, and expensively solved than if they knew what tools were available in the first place.
â€“Â Telastyn
Dec 8 '13 at 22:51

1

@Telastyn - In the real world, most developers have learned 'just enough' to solve the problem at hand. I could expand on this in lengthy detail, but it basically boils down to the fact that at any particular moment one has an issue in front of them and time is short. There are people that spend four years in school getting degrees and they learned some 'more advanced techniques', and others are periodically sent out to training to learn new methodologies. For the most part, however, these are luxuries. If you want someone to do it a particular way, ask them to learn it.
â€“Â Meredith Poor
Dec 8 '13 at 23:01

2

I'm sorry, I don't see being competent as a luxury. I am currently a tech lead - I do not and can not have the time to analyze each individual problem to tell professional programmers how best to solve it. Sharpening the saw isn't a luxury, it's vital to success in any career.
â€“Â Telastyn
Dec 8 '13 at 23:59

add a commentÂ |Â

up vote
0
down vote

answered Dec 8 '13 at 22:04

Meredith Poor

8,8661730

answered Dec 8 '13 at 22:04

Meredith Poor

8,8661730

answered Dec 8 '13 at 22:04

Meredith Poor

8,8661730

answered Dec 8 '13 at 22:04

Meredith Poor

8,8661730

answered Dec 8 '13 at 22:04

Meredith Poor

8,8661730

1

...except there's a huge difference between int and int?. People do in depth technical interviews to see if you really solved the problem or if you learned just enough to build a hacky, fragile solution that couldn't stand the test of time. (I don't necessarily mean you in particular - there's certainly not enough in answers to say, or mean for this to seem too harsh, I've been working with and interviewing a lot of people with 'shallow' knowledge as of late).
â€“Â Telastyn
Dec 8 '13 at 22:16

@Telastyn - Shallow in what respect? I have friends that have entered the workforce in the last few years, and have been handed "compose eMail HTML with Javascript driven buttons so the customers can link to the right place in the site". In short, they're handed responsibility for shallow tasks, so they don't really drill into databases, business rules, web services, etc. We're seeing vast amounts of compartmentalization, which makes developers productive quickly, but immediately casts them in 'slots'. Pretty nasty, and dangerous for everyone involved.
â€“Â Meredith Poor
Dec 8 '13 at 22:22

Bleh, that is no good. When I talk about shallow here, I mean people who have learned just enough to solve the problem at hand. Because of that, they don't have in depth knowledge of their primary language, or modern development techniques, or really anything beyond the horizon of their day to day problems. And because of that, the day to day problems are more frequent, and expensively solved than if they knew what tools were available in the first place.
â€“Â Telastyn
Dec 8 '13 at 22:51

1

@Telastyn - In the real world, most developers have learned 'just enough' to solve the problem at hand. I could expand on this in lengthy detail, but it basically boils down to the fact that at any particular moment one has an issue in front of them and time is short. There are people that spend four years in school getting degrees and they learned some 'more advanced techniques', and others are periodically sent out to training to learn new methodologies. For the most part, however, these are luxuries. If you want someone to do it a particular way, ask them to learn it.
â€“Â Meredith Poor
Dec 8 '13 at 23:01

2

I'm sorry, I don't see being competent as a luxury. I am currently a tech lead - I do not and can not have the time to analyze each individual problem to tell professional programmers how best to solve it. Sharpening the saw isn't a luxury, it's vital to success in any career.
â€“Â Telastyn
Dec 8 '13 at 23:59

add a commentÂ |Â

1

...except there's a huge difference between int and int?. People do in depth technical interviews to see if you really solved the problem or if you learned just enough to build a hacky, fragile solution that couldn't stand the test of time. (I don't necessarily mean you in particular - there's certainly not enough in answers to say, or mean for this to seem too harsh, I've been working with and interviewing a lot of people with 'shallow' knowledge as of late).
â€“Â Telastyn
Dec 8 '13 at 22:16

@Telastyn - Shallow in what respect? I have friends that have entered the workforce in the last few years, and have been handed "compose eMail HTML with Javascript driven buttons so the customers can link to the right place in the site". In short, they're handed responsibility for shallow tasks, so they don't really drill into databases, business rules, web services, etc. We're seeing vast amounts of compartmentalization, which makes developers productive quickly, but immediately casts them in 'slots'. Pretty nasty, and dangerous for everyone involved.
â€“Â Meredith Poor
Dec 8 '13 at 22:22

Bleh, that is no good. When I talk about shallow here, I mean people who have learned just enough to solve the problem at hand. Because of that, they don't have in depth knowledge of their primary language, or modern development techniques, or really anything beyond the horizon of their day to day problems. And because of that, the day to day problems are more frequent, and expensively solved than if they knew what tools were available in the first place.
â€“Â Telastyn
Dec 8 '13 at 22:51

1

@Telastyn - In the real world, most developers have learned 'just enough' to solve the problem at hand. I could expand on this in lengthy detail, but it basically boils down to the fact that at any particular moment one has an issue in front of them and time is short. There are people that spend four years in school getting degrees and they learned some 'more advanced techniques', and others are periodically sent out to training to learn new methodologies. For the most part, however, these are luxuries. If you want someone to do it a particular way, ask them to learn it.
â€“Â Meredith Poor
Dec 8 '13 at 23:01

2

I'm sorry, I don't see being competent as a luxury. I am currently a tech lead - I do not and can not have the time to analyze each individual problem to tell professional programmers how best to solve it. Sharpening the saw isn't a luxury, it's vital to success in any career.
â€“Â Telastyn
Dec 8 '13 at 23:59

...except there's a huge difference between int and int?. People do in depth technical interviews to see if you really solved the problem or if you learned just enough to build a hacky, fragile solution that couldn't stand the test of time. (I don't necessarily mean you in particular - there's certainly not enough in answers to say, or mean for this to seem too harsh, I've been working with and interviewing a lot of people with 'shallow' knowledge as of late).
â€“Â Telastyn
Dec 8 '13 at 22:16

@Telastyn - Shallow in what respect? I have friends that have entered the workforce in the last few years, and have been handed "compose eMail HTML with Javascript driven buttons so the customers can link to the right place in the site". In short, they're handed responsibility for shallow tasks, so they don't really drill into databases, business rules, web services, etc. We're seeing vast amounts of compartmentalization, which makes developers productive quickly, but immediately casts them in 'slots'. Pretty nasty, and dangerous for everyone involved.
â€“Â Meredith Poor
Dec 8 '13 at 22:22

Bleh, that is no good. When I talk about shallow here, I mean people who have learned just enough to solve the problem at hand. Because of that, they don't have in depth knowledge of their primary language, or modern development techniques, or really anything beyond the horizon of their day to day problems. And because of that, the day to day problems are more frequent, and expensively solved than if they knew what tools were available in the first place.
â€“Â Telastyn
Dec 8 '13 at 22:51

@Telastyn - In the real world, most developers have learned 'just enough' to solve the problem at hand. I could expand on this in lengthy detail, but it basically boils down to the fact that at any particular moment one has an issue in front of them and time is short. There are people that spend four years in school getting degrees and they learned some 'more advanced techniques', and others are periodically sent out to training to learn new methodologies. For the most part, however, these are luxuries. If you want someone to do it a particular way, ask them to learn it.
â€“Â Meredith Poor
Dec 8 '13 at 23:01

I'm sorry, I don't see being competent as a luxury. I am currently a tech lead - I do not and can not have the time to analyze each individual problem to tell professional programmers how best to solve it. Sharpening the saw isn't a luxury, it's vital to success in any career.
â€“Â Telastyn
Dec 8 '13 at 23:59

add a commentÂ |Â

up vote
0
down vote

answered Dec 9 '13 at 1:40

KevDog

933157

add a commentÂ |Â

up vote
0
down vote

answered Dec 9 '13 at 1:40

KevDog

933157

add a commentÂ |Â

up vote
0
down vote

answered Dec 9 '13 at 1:40

KevDog

933157

answered Dec 9 '13 at 1:40

KevDog

933157

answered Dec 9 '13 at 1:40

KevDog

933157

answered Dec 9 '13 at 1:40

KevDog

933157

answered Dec 9 '13 at 1:40

KevDog

933157

add a commentÂ |Â

up vote
0
down vote

There's a couple caveats to this:

If you're trying to make a "jump" (to a different role, like manager, or to a different technology stack, or to a different domain). In this case, the whole point is that the last 5 years don't apply as well as you might like. So you should be studying that role, technology stack, or domain. But since you're make a jump in a particular direction, all of your studying should apply to all of your upcoming interviews. (Implicit in this is that you're making a directed jump, and not a "anywhere but here" jump.)

Interviewing skills probably weren't key to your job for the last 5 years, so it makes sense to brush up on those. Writing code on a whiteboard, explaining things to people who are judging your ability to explain without actually participating in depth, stupid puzzles, etc. are all things that are much more common in interviews than on the job. So studying those things doesn't hurt. But again, you shouldn't have to study different things for different interviews.

answered Dec 9 '13 at 2:53

Tom Panning

41424

add a commentÂ |Â

up vote
0
down vote

There's a couple caveats to this:

If you're trying to make a "jump" (to a different role, like manager, or to a different technology stack, or to a different domain). In this case, the whole point is that the last 5 years don't apply as well as you might like. So you should be studying that role, technology stack, or domain. But since you're make a jump in a particular direction, all of your studying should apply to all of your upcoming interviews. (Implicit in this is that you're making a directed jump, and not a "anywhere but here" jump.)

Interviewing skills probably weren't key to your job for the last 5 years, so it makes sense to brush up on those. Writing code on a whiteboard, explaining things to people who are judging your ability to explain without actually participating in depth, stupid puzzles, etc. are all things that are much more common in interviews than on the job. So studying those things doesn't hurt. But again, you shouldn't have to study different things for different interviews.

answered Dec 9 '13 at 2:53

Tom Panning

41424

add a commentÂ |Â

up vote
0
down vote

There's a couple caveats to this:

If you're trying to make a "jump" (to a different role, like manager, or to a different technology stack, or to a different domain). In this case, the whole point is that the last 5 years don't apply as well as you might like. So you should be studying that role, technology stack, or domain. But since you're make a jump in a particular direction, all of your studying should apply to all of your upcoming interviews. (Implicit in this is that you're making a directed jump, and not a "anywhere but here" jump.)

Interviewing skills probably weren't key to your job for the last 5 years, so it makes sense to brush up on those. Writing code on a whiteboard, explaining things to people who are judging your ability to explain without actually participating in depth, stupid puzzles, etc. are all things that are much more common in interviews than on the job. So studying those things doesn't hurt. But again, you shouldn't have to study different things for different interviews.

answered Dec 9 '13 at 2:53

Tom Panning

41424

There's a couple caveats to this:

If you're trying to make a "jump" (to a different role, like manager, or to a different technology stack, or to a different domain). In this case, the whole point is that the last 5 years don't apply as well as you might like. So you should be studying that role, technology stack, or domain. But since you're make a jump in a particular direction, all of your studying should apply to all of your upcoming interviews. (Implicit in this is that you're making a directed jump, and not a "anywhere but here" jump.)

Interviewing skills probably weren't key to your job for the last 5 years, so it makes sense to brush up on those. Writing code on a whiteboard, explaining things to people who are judging your ability to explain without actually participating in depth, stupid puzzles, etc. are all things that are much more common in interviews than on the job. So studying those things doesn't hurt. But again, you shouldn't have to study different things for different interviews.

answered Dec 9 '13 at 2:53

Tom Panning

41424

answered Dec 9 '13 at 2:53

Tom Panning

41424

answered Dec 9 '13 at 2:53

Tom Panning

41424

answered Dec 9 '13 at 2:53

Tom Panning

41424

add a commentÂ |Â

Search This Blog

Iyfjky