We run a NodeJS app on AWS Elastic Beanstalk. Their node environment works well for us and on the machine is NGINX running on port 8080, and our node app running at port 8081. Some proxy table forwards port 80 to 8080, so NGINX receives all the traffic.
The SSL certificate is managed by AWS Certificate Manager, and is configured at the Load Balancer. That load balancer is serving traffic on port 80 (HTTP) and 443 (HTTPS), but always to port 80 on the beanstalk instance(s). It's very good to not have to worry about SSL in NGINX or node, and I could access our pages via HTTP or HTTPS.
However, I always wanted to use HTTPS. How could I automatically forward? Changing the Load Balancer to different ports (like 443 -> 80 to 443 -> 443) would have required some deep system changes on the beanstalk instances, which is handled by some complex beanstalk scripts. Examples are out there, but it all seemed overly complex and then I was tying our system to some random internet script that I did not write or understand.
Thankfully the solution was much simpler.
This is in my NGINX setup:
server {
listen 8080;
if ($http_x_forwarded_proto = "http") {
return 301 https://$host$request_uri;
}
// lots of other stuff
}
That's all it took, and I understand it! If the protocol is "http", redirect for "https" and keep everything else (host and URI) the same. Mostly this will only affect the first load of the page, after that all future requests will remain HTTPS anyway.
(Only downside is sometimes I forget the "s" when pasting a `curl` command, and the response doesn't follow the redirect, responding with 301.)
Monday, January 8, 2018
Wednesday, December 13, 2017
SSH EC2 to EC2 and Security Groups
I ran into the case where my shiny new Elastic Beanstalk instances wanted to talk to some older services running on standard EC2 instances, and the method to do that was via SSH.
I use SSH often to manage that older service and connect with an Elastic IP (which is basically a static IP) as the "hostname". Trying this same approach worked in dev (our office has a static IP and it's just like my terminal), but failed when deployed to Elastic Beanstalk.
Managing the Security Group (SG) of the older service required a new access rule for port 22:
Using the SG of Elastic Beanstalk failed to connect.
Using the private IP of of our VPC (e.g. 172.31.0.0) failed to connect.
Using the public IP of the Elastic Beanstalk worked!
However, this was problematic because the IP of my elastic beanstalk could change (our staging system is a single instance but production is a rolling cluster). Editing the SG manually would be dumb and writing a script to check public IPs in the Beanstalk after each deploy sounded hard.
Instead of referencing the static IP address XXX.XX.XXX.XXX when connecting via SSH, I used the public DNS, which contains the elastic/static IP address anyway (e.g.
I panicked and asked on AWS Forums and StackoverFlow as well, and answered my own question at each.
Problem
I use SSH often to manage that older service and connect with an Elastic IP (which is basically a static IP) as the "hostname". Trying this same approach worked in dev (our office has a static IP and it's just like my terminal), but failed when deployed to Elastic Beanstalk.
Managing the Security Group (SG) of the older service required a new access rule for port 22:
Using the SG of Elastic Beanstalk failed to connect.
Using the private IP of of our VPC (e.g. 172.31.0.0) failed to connect.
Using the public IP of the Elastic Beanstalk worked!
However, this was problematic because the IP of my elastic beanstalk could change (our staging system is a single instance but production is a rolling cluster). Editing the SG manually would be dumb and writing a script to check public IPs in the Beanstalk after each deploy sounded hard.
Easy Solution
Instead of referencing the static IP address XXX.XX.XXX.XXX when connecting via SSH, I used the public DNS, which contains the elastic/static IP address anyway (e.g.
ec2-XXX-XX-XXX-XXX.compute-1.amazonaws.com, so shouldn't change on me). This allowed EC2 to resolve internal IP addresses, and thus the Security Group rule on the older EC2 instanced worked for another security group instead of public IP. I panicked and asked on AWS Forums and StackoverFlow as well, and answered my own question at each.
Tuesday, August 22, 2017
Why we chose actionhero?
While there are many frameworks for NodeJS servers, I have been using a framework for building our applications for the past few years and wanted to sum up those thoughts here.
I've read a little about Jade and EJS as rendering engines for Node servers, namely Express, but never wanted to jump into having my front-end and back-end running on the same server. I had brief thoughts on the performance implications of having my single-threaded Node process serving and rendering web pages (over nginx or other proxies), and there were other reasons along those lines, though the scale of these projects were not going to be web-huge anyway. Mainly, I just did not want to tie my web page's HTML with server models, forever locking both together. (Having inherited a Java/JSP system, pulling the two apart in any language would leave some scars!)
Actionhero is almost purely for an API. Yes, it can serve static files, but to me it was built for data processing and message passing. I had flexibility in my client technologies because they simply spoke to an API. There are many features that are production ready and tested. This framework can be used for small prototypes to full-scale production systems.
Actionhero has a folder structure for components of the system: actions, initializers, configs, and tasks. Each component type has a purpose, code layout and sometimes a load order. There is a flow to how the server works - where "actions" are the focus. Starting a new project with actionhero, or jumping into another actionhero project, has everything laid out the same way and I do not need to worry about it. Another win! Personal favorite concept of organizing code with actionhero is thin Actions and fat Initializers - the concept works so well in practice.
Actionhero has some opinions and I'm content at the extent they are chosen. When a html app needed events pushed to it, actionhero already had a chat system and WebSockets. When a client did not want WebSockets in their Unity3D app, actionhero already handled every HTTP action via a TCP server. When I needed a dev, test and production environment for our system, a simple config controlled each one. A large list of common features to any production Node system are "built in", and while certain pieces are very opinionated, there is a lot of flexibility for everything else.
Also, the community of actionhero is top-notch. This is due to actionhero's creator and top-contributor, Evan Tahler, who runs a great project. It's tested, documented, and evolving - and has been the past few years. The Slack channel is particularly useful these days, even over Stackoverflow or Github issues.
If this is your first node project ever, follow along a blog for Express to make a HTTP endpoint respond "Hello World." If you want to make a full-sized web application server, and be ready for all those production issues and feature growth you aren't even thinking about right now, get started with actionhero. That's my go-to choice while working with NodeJS.
TL:DR
actionhero
Production API Server
I've read a little about Jade and EJS as rendering engines for Node servers, namely Express, but never wanted to jump into having my front-end and back-end running on the same server. I had brief thoughts on the performance implications of having my single-threaded Node process serving and rendering web pages (over nginx or other proxies), and there were other reasons along those lines, though the scale of these projects were not going to be web-huge anyway. Mainly, I just did not want to tie my web page's HTML with server models, forever locking both together. (Having inherited a Java/JSP system, pulling the two apart in any language would leave some scars!)Actionhero is almost purely for an API. Yes, it can serve static files, but to me it was built for data processing and message passing. I had flexibility in my client technologies because they simply spoke to an API. There are many features that are production ready and tested. This framework can be used for small prototypes to full-scale production systems.
Organization
My first Node project was built on top of Restify which was a fine choice for our data system (different team was building the front-end, another benefit of an API server). The concepts of Restify were solid, but I ended up developing my own system of organizing all my scripts. While that taught me a lot about Node's `require()` and the loading order of a Node app, it was a pain! Making sure all my end-points got loaded with clever directory layouts. Time spent on avoiding mixing the response handling and data retrieval. In the end it worked but there was time lost building, essentially, a framework for our app from scratch!Actionhero has a folder structure for components of the system: actions, initializers, configs, and tasks. Each component type has a purpose, code layout and sometimes a load order. There is a flow to how the server works - where "actions" are the focus. Starting a new project with actionhero, or jumping into another actionhero project, has everything laid out the same way and I do not need to worry about it. Another win! Personal favorite concept of organizing code with actionhero is thin Actions and fat Initializers - the concept works so well in practice.
Features Included
Many of the other web server frameworks pride themselves in being "light" (Restify, Express) which is good, and then I'm spending lots of time choosing logging frameworks, middleware, websockets, config environments, scaling, etc. Flexibility is great, but the outcome of my choice was probably not vital, plus would have cost the time of research and integration.Actionhero has some opinions and I'm content at the extent they are chosen. When a html app needed events pushed to it, actionhero already had a chat system and WebSockets. When a client did not want WebSockets in their Unity3D app, actionhero already handled every HTTP action via a TCP server. When I needed a dev, test and production environment for our system, a simple config controlled each one. A large list of common features to any production Node system are "built in", and while certain pieces are very opinionated, there is a lot of flexibility for everything else.
Documentation and Community
Final thing worth mentioning were the docs, which I've linked to a few times already. They are well written and comprehensive . . . most any answer I looked for could be found there first. And since just enought is included with the framework, and my code stays organized, I find myself writing more useful code than figuring out how to write the code.Also, the community of actionhero is top-notch. This is due to actionhero's creator and top-contributor, Evan Tahler, who runs a great project. It's tested, documented, and evolving - and has been the past few years. The Slack channel is particularly useful these days, even over Stackoverflow or Github issues.
Shortcomings
Just to list these, these are my two short comings with actionhero worth mentioning.- Redis is required. At least to utilize the chat or scalability (different server-nodes communicating) features. While a caching database isn't a terrible idea anyway, it's one more piece in the cloud infrastructure (usually one of more costly pieces) and there is not a choice if you'll only use some other similar DB. For me, Redis is awesome anyway and until you need nodes to scale, it's not even necessary for a single-server-node (or server-node independent system).
- Ecosystem is small. When compared to Express, probably the most popular Node web server framework, there are far fewer plugins, blogs, examples, stackoverflow questions, and everything else for actionhero. Just not as many people use it, though due to documentation and community I have not found this to be a problem. Also, due to code organization, I know how to wire some npm package into the framework, and can use that package's documentation to figure out any issue there.
If this is your first node project ever, follow along a blog for Express to make a HTTP endpoint respond "Hello World." If you want to make a full-sized web application server, and be ready for all those production issues and feature growth you aren't even thinking about right now, get started with actionhero. That's my go-to choice while working with NodeJS.
Thursday, January 12, 2017
Upgrading postgresql tools on Amazon Linux
Tools like pg_dump, pg_restore and psql.
I didn't find much help when trying to do this, so thought I would write it up here.
Our AWS RDS was Postgres 9.6.1 but the postgres tools on the EC2 instance from the default yum repos was 9.5.4. Can't `pg_dump` with the minor version mis-match!
These were my commands (lines starting with // are like commands, don't run those : )
// Start at yum.postgresql.org
// https://yum.postgresql.org/repopackages.php#pg96
// Reading through docs there, need epel repos enabled
I didn't find much help when trying to do this, so thought I would write it up here.
Our AWS RDS was Postgres 9.6.1 but the postgres tools on the EC2 instance from the default yum repos was 9.5.4. Can't `pg_dump` with the minor version mis-match!
These were my commands (lines starting with // are like commands, don't run those : )
// Start at yum.postgresql.org
// https://yum.postgresql.org/repopackages.php#pg96
// Reading through docs there, need epel repos enabled
sudo yum-config-manager --enable epel
// Now there are more postgresql packages listed, but not 9.6!
yum list postgresql*
// Need to install the matching rpm file with yum. Copy the link.
sudo yum install pgdg-ami201503-96-9.6-2.noarch.rpm
// Yep, can see the packages for 9.6
yum list postgresql*
sudo yum install postgresql96.x86_64
// there was an error. Uninstall the 9.2 package (how did that even get there?)
sudo yum erase postgresql92
sudo yum install postgresql96.x86_64
// All tools now report 9.6.1
pg_dump --version
pg_restore --version
psql --version
Friday, November 11, 2016
Everyone Has Good Ideas
Everyone has good ideas. At least someone thought enough to give the idea. And while some ideas are really not that good in the end, you do not know until you hear them. When building a software product, ideas come from everywhere.
The business-side will have some ideas and you know they will be good ones, because they are paying for everything! Amazing how ideas sound a little different from the person (with)holding the checkbook. Developers will have good ideas because they are creative and just finished reading medium.com, and are eager to try new framework/library/database because surely it will be amazing and solve all the things. Other people in the company, or even individual clients, will have ideas now and again, sometimes in a very niche part of the software. And those ideas are important to them, more important than your next major or minor release!
What to do?!! Blowing people off and just blazing ahead with your plan might turn out well, and you'll prove to everyone how right you were! But at best some people are not happy, with you or your processes. At worst, you stop receiving new ideas at all. (Let's not even consider ignoring others ideas and still sinking . . . uh oh for you!)
When it comes to receiving ideas, two things need to happen:
Feeling heard is just a quick discussion, and it is also helpful in clarifying the idea.
If you can repeat back the idea after you understand it, that person will feel valued.
All this will go into your backlog of choice, whether its a spreadsheet, sticky notes in your dev's cube, or some tool that team uses. Ready to evaluate and enter planning (or cold storage : )
If you hear people's ideas and they have no way to get any feedback, their ideas just go into a blackhole and they have no clue if the idea is something to prepare for. We contracted on a team once where the Tech Lead wanted the business team to leave the dev team alone, constructed a wall, and ideas were tossed over (through him). Without any feedback from their meetings, the sales team were pitching one set of ideas to clients, the dev team was building another set of ideas, and everyone only found out how far apart they were at Milestone Releases! Contrast that with a company I've spoken with that has great intra-team communications, and ideas are flowing!
It does not matter whether this feedback is personally communicated or can be looked up at another time. It does matter why the resolution turned out the way it did.
People need to know what was good about the idea, and what was not. Maybe the idea was good, just not right now. Maybe the impact would not be worth the investment. Whatever the reason, it communicates the goals and schedules of the team, and will help shape better ideas in the future.
If people's ideas get feedback, but they are not heard, the people do not feel valued. Ever hear things like this?
The process your team implements can be adjusted, but both parts are necessary.
The existing meetings (Planning, Retros, "weekly team", etc) you already have are a good place to touch on these things. Keep using whatever tool you're using to manage tickets. With an attentive team lead (scrum master, whatever), even "being heard" can be accomplished remotely through the ticketing system; though starting that way may not have the right affect until people can trust the process. Even give rewards for good ideas. Whatever it takes for your specific team.
Everyone has good ideas, so work hard to find and keep the good ones, and ensure the next ones are brought in.
The business-side will have some ideas and you know they will be good ones, because they are paying for everything! Amazing how ideas sound a little different from the person (with)holding the checkbook. Developers will have good ideas because they are creative and just finished reading medium.com, and are eager to try new framework/library/database because surely it will be amazing and solve all the things. Other people in the company, or even individual clients, will have ideas now and again, sometimes in a very niche part of the software. And those ideas are important to them, more important than your next major or minor release!
What to do?!! Blowing people off and just blazing ahead with your plan might turn out well, and you'll prove to everyone how right you were! But at best some people are not happy, with you or your processes. At worst, you stop receiving new ideas at all. (Let's not even consider ignoring others ideas and still sinking . . . uh oh for you!)
When it comes to receiving ideas, two things need to happen:
People need to feel heard
People need feedback
Feeling Heard
Like I mentioned before, any idea someone brings up is important to them. If they do not feel heard or valued when giving their idea, they might become alienated to the team or just bitter. Could happen differently for different people, but the basic principle is to treat people well! We want good ideas, and we want people to give them.Feeling heard is just a quick discussion, and it is also helpful in clarifying the idea.
- "What were you thinking?"
- "Why is this important?"
- "Any timeframe the idea?"
- Maybe there's a quick drawing on a whiteboard.
If you can repeat back the idea after you understand it, that person will feel valued.
All this will go into your backlog of choice, whether its a spreadsheet, sticky notes in your dev's cube, or some tool that team uses. Ready to evaluate and enter planning (or cold storage : )
If you hear people's ideas and they have no way to get any feedback, their ideas just go into a blackhole and they have no clue if the idea is something to prepare for. We contracted on a team once where the Tech Lead wanted the business team to leave the dev team alone, constructed a wall, and ideas were tossed over (through him). Without any feedback from their meetings, the sales team were pitching one set of ideas to clients, the dev team was building another set of ideas, and everyone only found out how far apart they were at Milestone Releases! Contrast that with a company I've spoken with that has great intra-team communications, and ideas are flowing!
Giving Feedback
Often called closing-the-loop, any idea needs a resolution.- Is it happening this sprint?
- Is it up for future review?
- "Yes, though wait until Milestone 2 is over."
- Skip it, because...
It does not matter whether this feedback is personally communicated or can be looked up at another time. It does matter why the resolution turned out the way it did.
People need to know what was good about the idea, and what was not. Maybe the idea was good, just not right now. Maybe the impact would not be worth the investment. Whatever the reason, it communicates the goals and schedules of the team, and will help shape better ideas in the future.
If people's ideas get feedback, but they are not heard, the people do not feel valued. Ever hear things like this?
- "Why bother giving ideas, they just get rejected?"
- "Those tech guys don't know anything, this idea is necessary and will save the company!"
- "Yeah, I saw the demo. That was my idea, ya know?"
People that feel valued will contribute more, will stay with the company, will think of real ways to improve because they genuinely care. Good people are the greatest asset, and must be valued (of course, a principle in life and not just business.)
Now Do It
The process your team implements can be adjusted, but both parts are necessary.
The existing meetings (Planning, Retros, "weekly team", etc) you already have are a good place to touch on these things. Keep using whatever tool you're using to manage tickets. With an attentive team lead (scrum master, whatever), even "being heard" can be accomplished remotely through the ticketing system; though starting that way may not have the right affect until people can trust the process. Even give rewards for good ideas. Whatever it takes for your specific team.
Everyone has good ideas, so work hard to find and keep the good ones, and ensure the next ones are brought in.
Thursday, September 15, 2016
The Overly Technical Interview
Recently I started the interview process with a tech company that worked on some pretty cool software. That was their business, they recently went public, and were growing quickly. I applied as a Technical Lead (forget the actual title) and my background was a fit to get past the screening interview.
First step past the screening interview was a timed test at HackerRank. 75 minutes to answer 15 multiple choice and 3 programming problems. The multiple choice were a range of topics:
A great range of questions and topics. The only bad thing about multiple choice is second guessing yourself, like knowing the answer in 5 seconds and then talking yourself out of it for two minutes : )
The programming problems were pretty cool, and the testing tool allowed you to write and run in a large variety of languages. It even unit tested for you! My first question I got to a valid place to test and passed 2 of 5 unit tests, but didn't get to see the inputs or expected outputs of the tests. So I rewrote it a different way, and this time got 3 of 5 of the unit tests. And by this point time was running out, so I moved on.
In the end I ran out of time before completing every question. I did not see immediate feedback on my test (from the tool or company's recruiter) and was not sure how this would be scored. Was I intended to finish? Was this some kind of stress test? Do they only take those who can finish?
I guess my score was enough to move on and I had a one-on-one with another engineer. We talked about past projects of mine, and then did a coding exercise together, live on codeshare.io. The problem was to write Fibonacci in any language I wanted. I just started coding, though it did not feel natural because I haven't used the Fibonacci sequence since I learned about recursion in CS 101. I took a break from coding to explain where my head was at and explained a looping algorithm that would solve the problem by keeping track of an index and two variables. My interviewer showed a recursive sequence and asked it's pros and cons (algorithm complexity, stack size, etc) from the version I described. I asked about his views on the company and we were out of time.
The next day I got the "thanks but no thanks" response from my recruiter, which of course bubbles up the feelings of not getting picked. Everyone was nice and professional, and we're off our separate ways, wishing each other the best.
This interview did not lead to an offer, which is the most telling thing that can come from an interview process. In my view, something did not go right because I thought an offer was possible. It is why I applied!
Two takeaways from this experience. One for me, one for them.
Takeaway One: Study
For those tech companies that are asking the algorithm questions, and I've heard about it from a lot of the big names, one needs to study. No matter if you think the questions are "too basic" or "just facts you can look up on-line", this is the screening process. If you want to stand a chance with these types of companies, study! Know the tricks. Eat Fibonacci for breakfast, B-Trees for lunch and some Big O notation for dinner. Practice at HackerRank or some other coding problem site.
Also, I would have used algorithm design comments more than actual code, especially when I was going to run out of time in the test, or during the coding interview where code would not run. Partial credit in those situations would hopefully have shown I knew what needed to be done ("solved the problem") and just needed time to code it correctly.
In the end, this is the company's interview process and if I want to compete in that space, I need to hit the books!
Takeaway Two: Interview for the Position
I mentioned this was for a Technical Lead position, yet feel that every multiple choice question and especially my one-on-one problem solving interview, could have been solved by looking up StackOverflow or Wikipedia. Not a single question about managing a project timeline, following a software process, thoughts on testing, system design, choosing a framework or component architecture. Maybe there would have been more of that past this "screening technical interview", but if I were a team lead, one would think those items would be important.
Same goes for the timed test and code-sharing, to a degree. Was that an accurate measure of my technical knowledge? No time for design, because the test clock was running and we had 9 minutes left on our interview when we hit codeshare.io. HackerRank is a cool tool, but is coding without (more than one) test inputs or expected outputs very common? Speed coding might be fitting at a hack-a-thon, but "just start typing" is not a typical way to get the best results at the office. The concern is while these tests/reviews might be good for screening, is it relevant to your actual work?
Other interviews I have participated in required a homework assignment with a relevant problem to what the position was for. Time was not stressed. Code was not forced/constrained by a tool. We could discuss the work result, and how I got there. To me, though it is more time invested, feels more relevant to the job at hand. Perhaps that is seen more with smaller companies, but the big ones that are hiring 2-20 people a month, let alone screening 5x-10x that, just don't have the bandwidth for more. Though I wonder if turnover has any correlation to the interview process chosen.
Interviewing is its own set of skills, and I'd better stay sharp : )
The Test
First step past the screening interview was a timed test at HackerRank. 75 minutes to answer 15 multiple choice and 3 programming problems. The multiple choice were a range of topics:
- What CSS style would be applied to this element?
- What is the correct SQL query for generating this table output?
- What would this code output on the console?
- Where is the programming mistake in this (pseudo) code?
- Which algorithm is more efficient?
A great range of questions and topics. The only bad thing about multiple choice is second guessing yourself, like knowing the answer in 5 seconds and then talking yourself out of it for two minutes : )
The programming problems were pretty cool, and the testing tool allowed you to write and run in a large variety of languages. It even unit tested for you! My first question I got to a valid place to test and passed 2 of 5 unit tests, but didn't get to see the inputs or expected outputs of the tests. So I rewrote it a different way, and this time got 3 of 5 of the unit tests. And by this point time was running out, so I moved on.
In the end I ran out of time before completing every question. I did not see immediate feedback on my test (from the tool or company's recruiter) and was not sure how this would be scored. Was I intended to finish? Was this some kind of stress test? Do they only take those who can finish?
The One-On-One
I guess my score was enough to move on and I had a one-on-one with another engineer. We talked about past projects of mine, and then did a coding exercise together, live on codeshare.io. The problem was to write Fibonacci in any language I wanted. I just started coding, though it did not feel natural because I haven't used the Fibonacci sequence since I learned about recursion in CS 101. I took a break from coding to explain where my head was at and explained a looping algorithm that would solve the problem by keeping track of an index and two variables. My interviewer showed a recursive sequence and asked it's pros and cons (algorithm complexity, stack size, etc) from the version I described. I asked about his views on the company and we were out of time.
The End
The next day I got the "thanks but no thanks" response from my recruiter, which of course bubbles up the feelings of not getting picked. Everyone was nice and professional, and we're off our separate ways, wishing each other the best.
Takeaways
Two takeaways from this experience. One for me, one for them.
Takeaway One: Study
For those tech companies that are asking the algorithm questions, and I've heard about it from a lot of the big names, one needs to study. No matter if you think the questions are "too basic" or "just facts you can look up on-line", this is the screening process. If you want to stand a chance with these types of companies, study! Know the tricks. Eat Fibonacci for breakfast, B-Trees for lunch and some Big O notation for dinner. Practice at HackerRank or some other coding problem site.
Also, I would have used algorithm design comments more than actual code, especially when I was going to run out of time in the test, or during the coding interview where code would not run. Partial credit in those situations would hopefully have shown I knew what needed to be done ("solved the problem") and just needed time to code it correctly.
In the end, this is the company's interview process and if I want to compete in that space, I need to hit the books!
Takeaway Two: Interview for the Position
I mentioned this was for a Technical Lead position, yet feel that every multiple choice question and especially my one-on-one problem solving interview, could have been solved by looking up StackOverflow or Wikipedia. Not a single question about managing a project timeline, following a software process, thoughts on testing, system design, choosing a framework or component architecture. Maybe there would have been more of that past this "screening technical interview", but if I were a team lead, one would think those items would be important.
Same goes for the timed test and code-sharing, to a degree. Was that an accurate measure of my technical knowledge? No time for design, because the test clock was running and we had 9 minutes left on our interview when we hit codeshare.io. HackerRank is a cool tool, but is coding without (more than one) test inputs or expected outputs very common? Speed coding might be fitting at a hack-a-thon, but "just start typing" is not a typical way to get the best results at the office. The concern is while these tests/reviews might be good for screening, is it relevant to your actual work?
Other interviews I have participated in required a homework assignment with a relevant problem to what the position was for. Time was not stressed. Code was not forced/constrained by a tool. We could discuss the work result, and how I got there. To me, though it is more time invested, feels more relevant to the job at hand. Perhaps that is seen more with smaller companies, but the big ones that are hiring 2-20 people a month, let alone screening 5x-10x that, just don't have the bandwidth for more. Though I wonder if turnover has any correlation to the interview process chosen.
Interviewing is its own set of skills, and I'd better stay sharp : )
Fast and Slow Questions
I like going to art galleries and am genuinely impressed by at the skill and creativity of the artists showing their works. I'm typically drawn to the more technical works that, in my mind, highlight ability over expression. Photorealistic pieces are my favorite. Sometimes I like the abstract or minimalist, but that's just less often. Everyone has different tastes, because we are all a little different, and that's great!
The one thing about art galleries is that it does not take me more than five seconds to know if I like a piece or not. I do not need to, or care to, stand and ponder. When it comes to engineering projects, there are fast questions and there are slow questions. Certain times or certain clients might require one over another, and the questions you are asking will drive the outcome.
A typical slow question might be "What do you want?" or "What do you need?" Generally this could be called brainstorming, and whether that session takes an hour, or even more sessions, the question is slow. The feedback takes times to think about. The big picture is not fully formed. Everyone has different ideas and goals in mind.
Sometimes slow questions are needed. Requirements need to be generated. Technologies and processes need to be evaluated. Requirements need to be updated. 3rd Parties need consulted or included. Maybe it becomes painfully slow! Yet by the end, you have a well designed system and everyone is on the same page with the outcome expectations.
Fast questions have fast answers. "Yes or No?" "What don't you like?" The fast question will demand fast feedback, and is often iterative. This is not a single question and then everything is done, but one question leads to the next iteration and the next fast question, yet things keep moving and people remain engaged.
Experience plays a huge factor in being able to ask a fast question. Knowing what is out there, and how to apply tools or technologies. Knowing what has worked and what has not. Proof-of-concepts with a demo project. This type of experience allows for questions that can be answered and acted upon quickly.
If you work with the DoD or for a large enterprise, often you'll be asked (or asking) slow questions. A lot of people, risk mitigation and contract preparation needs to be set up prior to the work. It can feel slow, yet often is necessary.
Smaller teams and those trying to get an edge (first to market or finding new business) cannot afford the slow questions. Either a client is not willing to pay for the perceived delay or they do not have the answers to your slow question anyway ("What do you need?"). Having a prototype could be key for faster situations, because it allows for a fast response. "Is this what you meant?" "What changes before we go live?" These are fast questions and can accelerate development and interest.
The types of questions we ask are the types of answers we will receive. At the art gallery, I'll still ask the fast ones.
The one thing about art galleries is that it does not take me more than five seconds to know if I like a piece or not. I do not need to, or care to, stand and ponder. When it comes to engineering projects, there are fast questions and there are slow questions. Certain times or certain clients might require one over another, and the questions you are asking will drive the outcome.
Slow Questions
A typical slow question might be "What do you want?" or "What do you need?" Generally this could be called brainstorming, and whether that session takes an hour, or even more sessions, the question is slow. The feedback takes times to think about. The big picture is not fully formed. Everyone has different ideas and goals in mind.
Sometimes slow questions are needed. Requirements need to be generated. Technologies and processes need to be evaluated. Requirements need to be updated. 3rd Parties need consulted or included. Maybe it becomes painfully slow! Yet by the end, you have a well designed system and everyone is on the same page with the outcome expectations.
Fast Questions
Fast questions have fast answers. "Yes or No?" "What don't you like?" The fast question will demand fast feedback, and is often iterative. This is not a single question and then everything is done, but one question leads to the next iteration and the next fast question, yet things keep moving and people remain engaged.
Experience plays a huge factor in being able to ask a fast question. Knowing what is out there, and how to apply tools or technologies. Knowing what has worked and what has not. Proof-of-concepts with a demo project. This type of experience allows for questions that can be answered and acted upon quickly.
What Questions Are You Asking?
If you work with the DoD or for a large enterprise, often you'll be asked (or asking) slow questions. A lot of people, risk mitigation and contract preparation needs to be set up prior to the work. It can feel slow, yet often is necessary.
Smaller teams and those trying to get an edge (first to market or finding new business) cannot afford the slow questions. Either a client is not willing to pay for the perceived delay or they do not have the answers to your slow question anyway ("What do you need?"). Having a prototype could be key for faster situations, because it allows for a fast response. "Is this what you meant?" "What changes before we go live?" These are fast questions and can accelerate development and interest.
The types of questions we ask are the types of answers we will receive. At the art gallery, I'll still ask the fast ones.
Subscribe to:
Posts (Atom)