Take-home tests are great! All I have to say on this topic is, this is your chance to prove your mettle on your terms.
Nobody watching over your shoulder scrutinizing each thought and line of pseudo-code. No interactive tap-dance like the kind in face to face onsites. You get to iterate, test, pretty-fy, document, and package the hell out of it. Give it all you have.
Why an entire blog post for this? Because it is that valuable in the candidate's interview process and will only grow in favor with hiring teams.
Software Programming Interviews Part 3 - Getting Noticed
Take a look at your resume. A significant part of it lists software projects with technical descriptions. These projects help establish your areas of familiarity or expertise. Do they stand you apart from the crowd? Hint: its a rhetorical question.
All that falling-over-each-other-to-grab-the-coolest-project-at-work - when will it come handy you ask? One word: over-rated!
How about coursera/udemy or other online courses and certifications? Fantastic for self-learning but don't expect to be demonstrating your individual value based on these diplomas.
How about your Linked In profile where hyperbole is the norm? Loaded question, you might say but you get my point.
Does GPA matter? The truth is that its value ages out faster than you think once you graduate.
Let's step back a little bit and absorb the big picture:
The best hiring scenario is where the team has a clear understanding of your value before the face to face. Let this sink in a bit. The onsite face to face must only validate their previous assessment of your value. Dotting the i's and crossing the t's as its called.
The scenario I described poses least frustrations for both the candidate and the hiring team. Fewer surprises and less pressure during the face to face paves the way for starting career relationships rather than managing sweaty palms, beaded foreheads and out-of-the-natural behavior patterns.
So to re-state our problem statement:
How do you stand apart and establish value before the onsite?
Seems impossible, does it? Since I'm feeling generous with hints, here's one more: This bit takes a year or two of work in the least. The good news is that it is never too late to start.
We live in what is called the 'reputation economy'. An entity - in this case you - is associated with a score or 'reputation' that is accrued by being valuable to a crowd. Stack Overflow is the classic example which quantifies how much value you are adding to the community. Reputation could also be qualitative. Speaking at tech conferences, chairing standards working committees, competing in international coding competitions or local hackathons, contributing to open source or maintaining your own, blogging about pet projects, all earn respect. Being published and/or having patents to your name also has a similar effect.
Jump right in - this is your best bet. Be a presence in the public domain as a value-contributor. There are tons of paths to pick from. If you don't know initially where you fit, try many things until you find your thing. Identify your affinity, carve time out of your personal schedule and throw yourself headlong into it. And then make it count.
One final word on your resume since we are on the topic: in the current age where all your career information is published on Linked In, what is the role of the resume? Besides, does it need to be 5, 3 or even 2 pages long? Hint: rhetorical question!!!
All that falling-over-each-other-to-grab-the-coolest-project-at-work - when will it come handy you ask? One word: over-rated!
How about coursera/udemy or other online courses and certifications? Fantastic for self-learning but don't expect to be demonstrating your individual value based on these diplomas.
How about your Linked In profile where hyperbole is the norm? Loaded question, you might say but you get my point.
Does GPA matter? The truth is that its value ages out faster than you think once you graduate.
Let's step back a little bit and absorb the big picture:
The best hiring scenario is where the team has a clear understanding of your value before the face to face. Let this sink in a bit. The onsite face to face must only validate their previous assessment of your value. Dotting the i's and crossing the t's as its called.
The scenario I described poses least frustrations for both the candidate and the hiring team. Fewer surprises and less pressure during the face to face paves the way for starting career relationships rather than managing sweaty palms, beaded foreheads and out-of-the-natural behavior patterns.
So to re-state our problem statement:
How do you stand apart and establish value before the onsite?
Seems impossible, does it? Since I'm feeling generous with hints, here's one more: This bit takes a year or two of work in the least. The good news is that it is never too late to start.
We live in what is called the 'reputation economy'. An entity - in this case you - is associated with a score or 'reputation' that is accrued by being valuable to a crowd. Stack Overflow is the classic example which quantifies how much value you are adding to the community. Reputation could also be qualitative. Speaking at tech conferences, chairing standards working committees, competing in international coding competitions or local hackathons, contributing to open source or maintaining your own, blogging about pet projects, all earn respect. Being published and/or having patents to your name also has a similar effect.
Jump right in - this is your best bet. Be a presence in the public domain as a value-contributor. There are tons of paths to pick from. If you don't know initially where you fit, try many things until you find your thing. Identify your affinity, carve time out of your personal schedule and throw yourself headlong into it. And then make it count.
One final word on your resume since we are on the topic: in the current age where all your career information is published on Linked In, what is the role of the resume? Besides, does it need to be 5, 3 or even 2 pages long? Hint: rhetorical question!!!
Agile Transformation 2015 and the Gartner's Hype Cycle
I urge you to read up on the Gartner Hype Cycle before proceeding.
Let's face it - Agile is on life support and everybody is in denial. Sure, it shook us out of Waterfall complacency. It also handed us a boatload of cool jargon and delivered some but mostly is continuing to painfully disappoint.
This could end in two ways - either discard Agile and pick up the next hot methodology waiting in the wings (antifragility?) or fix Agile ruthlessly to make it work. I am rallying for the latter.
The Agile story for an organization starts with 'Agile Transformation' and truth be told, often never ends because of the chasm between ideal Agile and realized Agile. There is usually no effort to quantitatively measure the progress of the transformation and therefore, this wild-goose chase goes un-noticed.
Here is a simple idea for assessing the success of Agile using the Hype Cycle:
- Deconstruct Agile into its components and garner feedback from the teams on the efficacy of each component.
- Construct the Gartner's Hype Cycle based on this feedback and take a long hard look at where each component stands, and why.
Each organization needs to chart out the Agile Hype Cycle for themselves, using the feedback
received from the early adoption teams or even the mature teams.
What do you do next with this information? For one, confront the Hype and Trough items and assess
how to get creative, and perhaps even deviate some, to push those items towards
the plateau of productivity. This could potentially give Agile a new lease of life.
To demonstrate the Agile Hype Cycle that I recommend for each organization, I went ahead and created one with my understanding of how each aspect in Agile is faring in general:
Gartner's Hype Cycle for Agile 2015*
Agile Components
|
Status
|
Scrum meetings
|
Slope of enlightenment
Teams value this quick daily sync up and have adapted it to their specific needs.
|
Sprints/Demos
|
Slope of enlightenment
Scoping a sprint at a high level and setting goals for that short period is an organized approach to check-pointing progress. Demos are useful for sharing information in a heterogeneous team that works on different projects.
|
Sprint Planning and Burndown
|
Trough of disillusionment
Extremely difficult to predict exact estimates. Can lead to bidding wars for tasks. Updating tasks with burndown is tedium. It constantly reminds the developer of process which is contrary to Agile’s objectives.
|
Backlog Grooming
|
Trough of disillusionment
How much is enough? Is this work product mature for planning and budgeting long lead projects? Unclear.
|
Sprint Retrospective
|
Trough of disillusionment
Influence is limited to the specific cross-functional. Northbound feedback is absent leading to growing chasm between the ‘coaching’ community and the developer's.
|
CI/CD
|
Slope of enlightenment
CI/CD has matured, and is accepted as the de-facto release and deployment model.
|
Iterative Development
|
Peak of hype
Designs for refactoring. Lets sloppy design through. Is expensive over the long term, especially with growing codebase. Less exciting often than developing something new.
|
Technical Debt
|
Peak of hype
Designs in bugs to allow for expedient development. Lets sloppy code through.
|
Agile Roles
|
Trough of disillusionment
Transient roles, each with a learning curve. Some roles overlap with traditional titles like Project Manager or Line Manager. Can lead to tension and confusion due to unclear boundaries of responsibilities. Most organizations aren’t great at mapping these to appraisal goals. Career growth suffers. Accountability is another serious concern with an abundance of roles.
|
Agile Transformation
|
Trough of disillusionment
The ideal Agile implementation always seems beyond reach, leaving the organizations forever in transition.
|
Iterative software development is anything but a new concept. Fred Brooks’ The Mythical Man-Month, first published in 1975, prescribes it. It is beside the point that I wish I lived in a world where Person-Month was the norm; 40 years since this book, it still isn't.
Agile however has a lot of wrappers around the core concept of iterative production/deployment. Agile is a system (or dare I say it, a ‘process’) that although claims to be ‘loose’ and a ‘recommendation’, is followed more fastidiously than Waterfall. I don’t remember Waterfall dictating types of meetings and meeting cadence for a project – at least not in practice. Also, the set of Principles is akin to the Commandments, making it look and feel like a religion. I won’t go down that analogy any further but there is more than one example I can provide of the parallels.
I have been a Product Owner long enough that I have seen the liberation Agile brings and also the colossal costs (for individual and organization) of failure. The ‘retrospectives’ run at individual team level do very little to influence the enterprise-level Agile design and therefore the feedback loop is imperfect, if it exists at all.
Agile has a bunch of good things about it, including a genius name, but it is also extremely flawed. If an organization doesn’t look these flaws in the eye and address them in ways that are very unique to each company, everyone will forever remain in transformation.
I hope for the developer's sake that these discussions start now.
Software Programming Interviews Part 2 - Whatever is 'Culture Fit'!
Part 1 of this series is a perfect segue for this hot button topic - Culture Fit. What is it? Is it a hoax and/or an HR tool to explain away anomalies in hiring patterns? Must you care? How does one prepare for this?
Newsflash - Culture Fit is real whether you like it or not. Yes, it is a much-abused term, and often an easy crutch to explain away hiring biases. However, a 'team' is not an objective, automated entity. A team is only people who work together. When a new hire joins an already successful team, it is that same infamous 'Culture Fit' done right that keeps the team on the success trajectory. Or in a better outcome, even accelerates it.
The way I see it is like so: every team is a 'virtual person'. Every team has one single collective pulse, IQ, ethics, voice and image. By 'collective' I don't mean 'homogenous', rather a common fabric that holds together diversity successfully. It is the Fit with this collective presence that represents to me Culture Fit. The biases play out when consciously or (more likely) sub-consciously a team favors more of the same, or is swayed by stereotypes. If you do sense it and would like to make a change, you are probably most effective in influencing it after you join that team.
Corporate culture has an unstated baseline with collaboration, verbal/written communication, and body language. These lend very easily to conscious preparation which is not merely applicable to interviews but also to day to day work life.
There may be other aspects that you can train yourself for as part of continuous development. How well do you listen? How effective is your questioning and critical thinking? When presented with an alternate proposal or idea, how open are you to evaluating it against your own?
Then there are aspects may be closer to your core personality and harder (but not impossible) to change: What do you do when you hit a wall or draw a blank with a problem? If you want to change this behavior, you have options and now you have to make a choice. That choice may or may not align with the team you are interviewing for.
Do you ask for help and if so, at what point in the problem solving? This again is tied to core personality which reveals tenacity, self-driven-ness and initiative.
I don't intend to present here an exhaustive checklist of behavior patterns and scenarios. And in fact, many of these don't have a right or wrong answer.
Know that Culture Fit is not often consciously tested for in technical interviews. However, a mis-alignment (whether governed by sub-conscious bias or not) quickly gets noticed as a red flag.
Do your research on the company culture and if possible, the team's. Analyze the interviewers carefully to better understand the team culture. Ask questions if needed. If you do want to adapt yourself to the team, understand that you are doing so not just for the interview but for that job role. Finally, be authentic and do not lie!
Newsflash - Culture Fit is real whether you like it or not. Yes, it is a much-abused term, and often an easy crutch to explain away hiring biases. However, a 'team' is not an objective, automated entity. A team is only people who work together. When a new hire joins an already successful team, it is that same infamous 'Culture Fit' done right that keeps the team on the success trajectory. Or in a better outcome, even accelerates it.
The way I see it is like so: every team is a 'virtual person'. Every team has one single collective pulse, IQ, ethics, voice and image. By 'collective' I don't mean 'homogenous', rather a common fabric that holds together diversity successfully. It is the Fit with this collective presence that represents to me Culture Fit. The biases play out when consciously or (more likely) sub-consciously a team favors more of the same, or is swayed by stereotypes. If you do sense it and would like to make a change, you are probably most effective in influencing it after you join that team.
Corporate culture has an unstated baseline with collaboration, verbal/written communication, and body language. These lend very easily to conscious preparation which is not merely applicable to interviews but also to day to day work life.
There may be other aspects that you can train yourself for as part of continuous development. How well do you listen? How effective is your questioning and critical thinking? When presented with an alternate proposal or idea, how open are you to evaluating it against your own?
Then there are aspects may be closer to your core personality and harder (but not impossible) to change: What do you do when you hit a wall or draw a blank with a problem? If you want to change this behavior, you have options and now you have to make a choice. That choice may or may not align with the team you are interviewing for.
Do you ask for help and if so, at what point in the problem solving? This again is tied to core personality which reveals tenacity, self-driven-ness and initiative.
I don't intend to present here an exhaustive checklist of behavior patterns and scenarios. And in fact, many of these don't have a right or wrong answer.
Know that Culture Fit is not often consciously tested for in technical interviews. However, a mis-alignment (whether governed by sub-conscious bias or not) quickly gets noticed as a red flag.
Do your research on the company culture and if possible, the team's. Analyze the interviewers carefully to better understand the team culture. Ask questions if needed. If you do want to adapt yourself to the team, understand that you are doing so not just for the interview but for that job role. Finally, be authentic and do not lie!
Software Programming Interviews Part 1 - Technical Questions
I am in a unique relationship with interviewing currently. To illustrate my point, here is a breakdown of the most recent 5 months in my career:
month 1: Update resume and relevant career sites; search for jobs and apply
months 2 and 3: Interview with fervor
month 4: Negotiate multiple offers, accept one and resign from then current employment
month 5: Join my new team and interview candidates for rest of the reqs at the rate of 3 interviews a week
It is the 5th month of this journey that stands me apart. In almost a continuum, I moved from one side of the interview desk to the other and the perspectives this has endowed me with are priceless.
I am attempting to capture my thoughts and observations in a multi-part blog post starting with this one. I don't plan on posting interview problems to solve and which companies ask what sorts of questions. There are plenty other great places where that information is available.
These are my personal views and do not reflect my employer's. Point to note also is that some aspects are topical or even locational and much is subject to change with various factors that affect hiring and the economy.
I'll start with my pet peeve about technical interviews:
Why *are* the questions book-ish and academic? Why aren't they more relevant to what is applied?
For example: Honest to goodness, I haven't had the need to use AVL trees in my entire career of 15 years of C programming. In the meanwhile, I have extensively used the Patricia Trie, the radix tree, the hash map and doubly linked list. Why then should I go back to the books to refresh on re-balancing of trees and convoluted algorithms for singly linked lists?
The most obvious reasoning is that the favored set of problems stems from foundational CS. So when you are able to convince the hiring team that you have nailed the foundations, there is greater confidence.
Then there are practicalities - the problems must be solvable in a short period of time and general enough to intersect a wide array of domains and expertise. They must be simple enough to help the review process, but complex enough to judge creativity. Makes sense?
I wasn't convinced entirely with these answers. While I plowed along with my interviews in months 2 and 3, a signal started to emerge from the noise. What I discovered may surprise you. Technical interviews - especially the face to face ones - have very little to do with 'coding kung-fu' and a lot to do with personality testing. Just as a body language expert looks for clues in behavior - those 'honest moments' - that reveal uncertainty, truth or lie, the hiring team uses the opportunity to pick up on whether each is able to see a working partnership in the candidate.
The first take away therefore is, an interview is anything but an exam. The hiring process is more analogous to match-making; complex, non-linear and very very personal. All that (often annoying) groundwork with practice problems and textbook refreshers is necessary to start playing but whether you get an offer or not relies a lot more than you think on the person that you are.
And here's another thing: the responsibility of finding that perfect match lies equally on either side of the hiring.
This has huge implications and dictates how you prepare yourself, present yourself and process a hit or a miss. Introspect, get in the shoes of the hiring side, and pay close attention to the 'soft' or 'behavior' aspects. Preparing for behavior questions is a slam dunk one would think but often ignored by the techies. That's low hanging fruit. What will really set you apart is your preparation to present a certain conscious behavior pattern while solving technical problems. Did I mention: introspect!!!
month 1: Update resume and relevant career sites; search for jobs and apply
months 2 and 3: Interview with fervor
month 4: Negotiate multiple offers, accept one and resign from then current employment
month 5: Join my new team and interview candidates for rest of the reqs at the rate of 3 interviews a week
It is the 5th month of this journey that stands me apart. In almost a continuum, I moved from one side of the interview desk to the other and the perspectives this has endowed me with are priceless.
I am attempting to capture my thoughts and observations in a multi-part blog post starting with this one. I don't plan on posting interview problems to solve and which companies ask what sorts of questions. There are plenty other great places where that information is available.
These are my personal views and do not reflect my employer's. Point to note also is that some aspects are topical or even locational and much is subject to change with various factors that affect hiring and the economy.
I'll start with my pet peeve about technical interviews:
Why *are* the questions book-ish and academic? Why aren't they more relevant to what is applied?
For example: Honest to goodness, I haven't had the need to use AVL trees in my entire career of 15 years of C programming. In the meanwhile, I have extensively used the Patricia Trie, the radix tree, the hash map and doubly linked list. Why then should I go back to the books to refresh on re-balancing of trees and convoluted algorithms for singly linked lists?
The most obvious reasoning is that the favored set of problems stems from foundational CS. So when you are able to convince the hiring team that you have nailed the foundations, there is greater confidence.
Then there are practicalities - the problems must be solvable in a short period of time and general enough to intersect a wide array of domains and expertise. They must be simple enough to help the review process, but complex enough to judge creativity. Makes sense?
I wasn't convinced entirely with these answers. While I plowed along with my interviews in months 2 and 3, a signal started to emerge from the noise. What I discovered may surprise you. Technical interviews - especially the face to face ones - have very little to do with 'coding kung-fu' and a lot to do with personality testing. Just as a body language expert looks for clues in behavior - those 'honest moments' - that reveal uncertainty, truth or lie, the hiring team uses the opportunity to pick up on whether each is able to see a working partnership in the candidate.
The first take away therefore is, an interview is anything but an exam. The hiring process is more analogous to match-making; complex, non-linear and very very personal. All that (often annoying) groundwork with practice problems and textbook refreshers is necessary to start playing but whether you get an offer or not relies a lot more than you think on the person that you are.
And here's another thing: the responsibility of finding that perfect match lies equally on either side of the hiring.
This has huge implications and dictates how you prepare yourself, present yourself and process a hit or a miss. Introspect, get in the shoes of the hiring side, and pay close attention to the 'soft' or 'behavior' aspects. Preparing for behavior questions is a slam dunk one would think but often ignored by the techies. That's low hanging fruit. What will really set you apart is your preparation to present a certain conscious behavior pattern while solving technical problems. Did I mention: introspect!!!
CodeChix
I have been a member of CodeChix (CC) for two years now and in this time, volunteered as an organizer and led CC's biggest software project to date called OFconnect. I have also represented CC at a hackathon and four technical conferences. In two years, I have gained experiences in managing software projects, leading a team, driving design ground-up, maintaining open source codebases, organizing tech events, and technical speaking.
I often am asked about CC, what we do and how it has helped. I have put my thoughts together here to share.
Why CC and not another women's society, group or meetup?
In early 2013, I scanned the entire landscape of tech clubs, networking events and meetups with a very specific intent: connect with other women engineers who have similar interests and most importantly, build and make software products together. It didn't take me too long to identify CC as the one and only organization where this was possible. Two years later, this still holds true.
CC also does a great job of keeping the work environment separate from recruitment agencies. As an engineer who wants to focus on learning and inventing, I value this hugely as it preserves the spirit of creativity without distractions.
What has been my experience working with CC members?
The membership base of CC has extremely talented and motivated engineers. This meant that a remarkable team came together for OFconnect and stuck it out to the end. The project promised to be fulfilling from a technical learning point of view but demanding on time and energy; and it delivered on that promise every bit of the way. The hacking sessions were productive, creative and fast paced. The online meetings were focused on unblocking each other's issues, much like scrum meetings. In all, the environment was always positive and collaborative.
On other occasions, I have worked with volunteers in organizing events, creating technical content for workshops, and fundraising. The experience has been one of tremendous learning.
What did I learn from CC?
I picked up a lot of experience with CC that my workplace would otherwise have taken quite a bit longer to make available for the grabbing and in some cases, forever. This is fact. I have listed above the range of responsibilities I have been able to explore in two short years. The problem-solving along the way for achieving each target big or small - that's where the joy and the growth lie.
Engage with CC and you'll be surprised how many opportunities you get to explore your interests and potential; be it in the technical sphere or administrative. If you like hands-on learning in a nothing-but-supportive environment, jump right in! All you need is initiative and drive.
How has CC helped my career?
With CC, I am constantly engaging with technology as a hobby and with also other individuals who thrive on it. This has had a direct positive influence on my motivation levels at my career.
CC has helped me keep up with new technologies in a very hands-on way. Be it Openstack, Raspberry Pi, Glass or Arduino. Be it SDN or Python.
And finally, CC makes it possible to bring new ideas to the table and realize them. Just as long as the ideas corroborate CC's mission and vision, the sky is the limit for new technical projects or events.
My work with CC has helped concretely demonstrate to my employer my motivation, initiative and drive, which directly translates to the value I bring to my job. This to me is victory.
Technology moves and fast too. The process of learning and growth is a continuous one and often an accelerating one in order to keep contributing and excelling. CC is a powerful enabler in this journey.
LCA 2015 - Day 1 Clouded Over by Containers
The miniconf on Clouds, Containers and Orchestration was extremely well attended!
Today's conference was marked by the over-abundant use of one word - 'container'. The container has taken the VM universe by storm and how! And now that you have LXC containers, you need to be able to manage them, migrate them, snapshot them, package them, cluster them, multiplex them and so forth. Enter a slew of solutions, some competing directly against others, and the rest with some degree of overlap.
Btw, second only to 'container' was 'docker'.
Here's a roadmap of sorts:
Google's kubernetes clusters containers.
CoreOS's rocket is an alternative to docker.
OpenShift is a smoothie of containers, docker, kubernetes, atomic and other ingredients.
Then there Mesos for clustering and HAProxy for load balancing.
Tomorrow's flavor is looking a lot like OpenStack.
In the meanwhile, a snippet of the Maori Welcome at today's start of conference:
Today's conference was marked by the over-abundant use of one word - 'container'. The container has taken the VM universe by storm and how! And now that you have LXC containers, you need to be able to manage them, migrate them, snapshot them, package them, cluster them, multiplex them and so forth. Enter a slew of solutions, some competing directly against others, and the rest with some degree of overlap.
Btw, second only to 'container' was 'docker'.
Here's a roadmap of sorts:
Google's kubernetes clusters containers.
CoreOS's rocket is an alternative to docker.
OpenShift is a smoothie of containers, docker, kubernetes, atomic and other ingredients.
Then there Mesos for clustering and HAProxy for load balancing.
Tomorrow's flavor is looking a lot like OpenStack.
In the meanwhile, a snippet of the Maori Welcome at today's start of conference:
Subscribe to:
Posts (Atom)