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!
Subscribe to:
Posts (Atom)