Technical Architect vs. Senior Project Manager: "Technical Architect vs. Senior Project Manager"
Technical Architect vs. Senior Project Manager
I R2Ied in January. After talking to several companies and declining some low-ball offers, I now have two good offers. Both are from Indian Offshore Consulting companies (like TCS, Wipro, etc.). The money is not great, but not bad either.
One of the companies is giving a Senior Technical Architect Role with 50% focus on architecture across multiple projects and 50% focus on presales activities. Travel will be 40-50% so they say. This job has more technical activities. For now, there will be zero people reporting to me.
The other company is offering a Senior Project Manager position with Account Management for multiple projects. This is a pure PM role with 20% technical activities. There will be anywhere from 5 to 50 people in my team depending on the projects handled.
I have so far been involved more on the technical architecture side in the US. I am in that confused state on whether to continue on the technical side (which I like), or to switch over to Management (which I may not like that much).
Any suggestions from the group as to what may be better long term ? Are there career prospects if you stay technical for long ? What if I want to start something on my own, or be an Independent Contractor/Consultant later ? Would staying in the technical area be helpful, or would project mgmt be better ?
Any words of wisdom will be helpful.
Thursday, February 10, 2011
Friday, February 4, 2011
Algorithms for Interviews
Algorithms for Interviews: "Algorithms For Interviews"
Summary
Algorithms For Interviews (AFI) is a book that aims to help engineers interviewing for software development positions as well as their interviewers. AFI consists of 174 solved algorithm design problems. It covers core material, such as searching and sorting; general design principles, such as graph modeling and dynamic programming; advanced topics, such as strings, parallelism and intractability. It also covers system design, problem solving, and interviewing techniques. AFI's authors are practicing algorithmists, with extensive academic and industrial experience. They have collectively published over 100 articles on applied algorithms, applied their skills at Google, Microsoft, IBM, Qualcomm, and a number of smaller software startups, and conducted many job interviews for various computer science jobs.
Example
Let's begin with the picture on the front cover of the book, reproduced on the right. You may have observed that the portrait of Alan Turing is constructed from a number of pictures ("tiles") of great computer scientists and mathematicians.
Suppose you were asked in an interview to design a program that takes an image and a collection of s X s-sized tiles and produce a mosaic from the tiles that resembles the image. A good way to begin may be to partition the image into s X s-sized squares, compute the average color of each such image square, and then find the tile that is closest to it in the color space. Here distance in color space can be the Euclidean distance over Red-Green-Blue (RGB) intensities for the color. As you look more carefully at the problem, you might conclude that it would be better to match each tile with an image square that has a similar structure. One way could be to perform a coarse pixelization (2 X 2 or 3 X 3) of each image square and finding the tile that is "closest" to the image square under a distance function defined over all pixel colors (for example, Euclidean Distance over RGB values for each pixel). Depending on how you represent the tiles, you end up with the problem of finding the closest point from a set of points in a k-dimensional space.
If there are m tiles and the image is partitioned into n squares, then a brute-force approach would have O(m n) time complexity. You could improve on this by first indexing the tiles using an appropriate search tree. A more detailed discussion on this approach is presented in the book.
If in a 45-60 minute interview, you can work through the above ideas, write some pseudocode for your algorithm, and analyze its complexity, you would have had a fairly successful interview. In particular, you would have demonstrated to your interviewer that you possess several key skills:
The ability to rigorously formulate and abstract a real-world problem.
The skills to solve problems and design algorithms.
The tools to go from an algorithm to a working program.
The analytical techniques required to determine the computational complexity of your solution.
Summary
Algorithms For Interviews (AFI) is a book that aims to help engineers interviewing for software development positions as well as their interviewers. AFI consists of 174 solved algorithm design problems. It covers core material, such as searching and sorting; general design principles, such as graph modeling and dynamic programming; advanced topics, such as strings, parallelism and intractability. It also covers system design, problem solving, and interviewing techniques. AFI's authors are practicing algorithmists, with extensive academic and industrial experience. They have collectively published over 100 articles on applied algorithms, applied their skills at Google, Microsoft, IBM, Qualcomm, and a number of smaller software startups, and conducted many job interviews for various computer science jobs.
Example
Let's begin with the picture on the front cover of the book, reproduced on the right. You may have observed that the portrait of Alan Turing is constructed from a number of pictures ("tiles") of great computer scientists and mathematicians.
Suppose you were asked in an interview to design a program that takes an image and a collection of s X s-sized tiles and produce a mosaic from the tiles that resembles the image. A good way to begin may be to partition the image into s X s-sized squares, compute the average color of each such image square, and then find the tile that is closest to it in the color space. Here distance in color space can be the Euclidean distance over Red-Green-Blue (RGB) intensities for the color. As you look more carefully at the problem, you might conclude that it would be better to match each tile with an image square that has a similar structure. One way could be to perform a coarse pixelization (2 X 2 or 3 X 3) of each image square and finding the tile that is "closest" to the image square under a distance function defined over all pixel colors (for example, Euclidean Distance over RGB values for each pixel). Depending on how you represent the tiles, you end up with the problem of finding the closest point from a set of points in a k-dimensional space.
If there are m tiles and the image is partitioned into n squares, then a brute-force approach would have O(m n) time complexity. You could improve on this by first indexing the tiles using an appropriate search tree. A more detailed discussion on this approach is presented in the book.
If in a 45-60 minute interview, you can work through the above ideas, write some pseudocode for your algorithm, and analyze its complexity, you would have had a fairly successful interview. In particular, you would have demonstrated to your interviewer that you possess several key skills:
The ability to rigorously formulate and abstract a real-world problem.
The skills to solve problems and design algorithms.
The tools to go from an algorithm to a working program.
The analytical techniques required to determine the computational complexity of your solution.
Subscribe to:
Posts (Atom)