As with every new season there comes a new set of fashion trends. Once reserved for weddings and proms, satin shoes are now in styles suitable for everyday wear. Here are some of favorites:
Pedro Garcia Onora Satin Wedges
Bottega Veneta Satin Ballet Flat
For a long time I have been addicted to crime shows like Law and Order. Perhaps this was because I find the psychology of criminals very fascinating. I think this fascination arose when I took a self defense course. It was an interesting course and consisted of several ex-police officers telling a group of unsuspecting girls gruesome stories about serial killers, rapists, and many other of the sadistic marvels of modern society. The goal of the course was to scare you so badly that if you ever were attacked you would think back on all these terrible tales and fight for your life.
Anyway, there is a new type of blog for web sleuths that try to solve real crimes and surface their findings online. The one I find most addicting is True Crime Diary. It tells the story of these modern villains and it is a whodunit story the rest of us can enjoy reading.
As a hiring manager I have done a lot of interviews. As you talk with other hiring managers about hiring engineers there seems to be this debate about whether candidates should write code in an interview. I believe that any candidate who expects to work on my team better be able to write code on a whiteboard in an interview. I am not talking perfect code, and I am not even saying the code has to be written in a specific language—but in order for a candidate to be hired into a software engineer on my team that is a minimum bar. I am sure some people are thinking, well that means that you might miss out on the good candidates—so I will elaborate as to why I do not believe that to be the case.
For any person in a software engineer role, I would expect that a substantial amount of their time would be spent writing code. I am not going to get into the philosophical argument about design time versus coding time (I can save that for another entry), but I will say that building their piece of the product is a basic I expectation. And in the case of my team, our product is software, and that means any engineer better be able to write code and make their contribution. So I believe it is fairly clear the ability to write code is a job requirement and therefore should be tested, measured, or quantified in some way during the interview process.
There are a series of objections one typically hears about coding in interviews:
It is a true statement that if a person can write code at their computer it is much different than standing up nervous in front of a whiteboard. That is also why I don’t ask people to implement a metrics system in an interview. I ask them to solve simple problems—most of which can be solved in one white board (so not more than 20 lines of code max) to illustrate how they translate their thought into code (I promise to post some of my favorite interview questions at some point). If they can algorithmically solve a problem, and have a solid understanding of data structures, then isn’t it important that they be able to turn those solutions into something that can be compiled?
Sometimes people are concerned that the standing up thing throws people off their game and hurts their performance, which is why I adapted the write the code on a pad of paper approach. This is also great because I can take their code sample into our debrief meeting and discuss their approach with the other interviews. The questions that are asked in these coding interviews do not involve complicated libraries—they require the syntactical knowledge that most students receive in an Introduction to Programming course. Furthermore, I will encourage students to write it in the language we use to do development (because then you can also assess at a basic level that person’s knowledge and style with a particular and relevant technology) but I always let them pick their language (I do try to make it object oriented though, since that is the type of development we do here) and I do not fault them on choice. This also allows them to be comfortable and be able to perform the best they can on a problem. But as an interviewer it means sometimes brushing up on languages you don’t love to use (for me that would be Python and Ruby).
As for resources, if a person wants to use a library but can’t remember the syntax (as is often the case for hash tables in interviews) I tell them to write out the APIs as they would implement them in the library. This means that the candidate doesn’t get blocked on the fact they can’t remember the parameters to pass into some API they barely remember, which allows you to focus on the problem at hand—but it also demonstrates how they might design an interface. Often times, senior candidates can even articulate all the interesting aspects of interface design and what are the pros and cons of their approach. Another thing you can ask candidates is where they might go to find information. Resourceful people are the type of people I want on my team. In other words, the resources aspect of the argument is easily overcome if you are a savvy interviewer and make sure to remove this as an obstacle for your candidate.
And finally, regardless of what a resume says, you should always approach candidates with the assumption everything isn’t always true. It sounds mean to assume that people would lie—but many do, and many more embellish. Understanding what is on the resume and how it translates to your business and your team is an important and necessary part of the interview process. Plus, if worse comes to worse you can compare what all those accomplishments really mean in comparison to other candidates and your own team on a set of baseline problems. In my opinion there is never a reason a candidate shouldn’t be able to write code. Your job as an interviewer is to set the stage in such a way so they can clearly demonstrate their ability and put their best foot forward.
Another stylistic thing I do is I almost always ask them (once they are completed with their first pass at the code solution) to explain it to me (since being able to explain your code is an important skill). Then if there are bugs I try to see if they will catch them, if they don’t I will suggest they walk through an example, if they still don’t I will let them know there is a bug. I like to see that people can identify and fix their own mistakes with a little help (since this is a reality in the life of a software engineer—everyone should know the basics of debugging). I then follow up with a question about testing. Good software engineers should have some basic ideas on how they would test their solution. And then finally, since the code is usually messy (because of the medium), I ask them what they would do if it were production code (some people say comments, formatting, moving methods around etc.). A lot of people will also delve into running time, performance, space usage, etc—all informative lines of questions that can help you understand more and more about the candidate, their approach to problems and their experience thinking about their code.
There is a ton of value in doing this line of questioning. I would not judge a candidate on these type of questions alone (since it takes a lot more than being able to write code to be a successful engineer), but I believe any good software engineer should meet a minimum bar.
Over the years one of the skills I have managed to hone is my ability to negotiate. People do not always realize almost anything in life has prices and terms that are set in stone. Today we were negotiating a contract and one of my colleagues on the email thread was musing at my response haggling with their rate. I told him “In life you have to look at everything as negotiable.” He then proceeded to tell me about how even chain stores like Best Buy and Circuit City are training their employees to haggle on prices on merchandise.
Having worked a retail job in the past, I have known that most employees have the ability to lower prices (usually around 10-20%) without even consulting their manager. The only times I have really realized these discounts though, is when I was super nice and sweet to an employee and they did me a favor. Often times my friends referred to this discount as the “cute girl discount.” In my single days I became a master of this tool—I had free daily lattes (the cup would appear at 7:40am on the edge of the coffee shop counter with my name on it—I always left a dollar where the cup was and went on my way), free lunch, discounted dry cleaning, and I rarely paid full price for any meals or drinks in restaurants. I don’t employ this discount the way I used to though, perhaps it is because I am older and not as cute, or maybe it is because I just don’t spend money they way I used to, but regardless the idea of negotiating everyday things sounded appealing to me (hey, every girl loves a bargain!).
So here is what I discovered:
See the NY Times article for more anecdotal stories.
One of the questions I have considered, and seem to revisit annually, is whether or not to get an MBA. I once had a mentor who asked me the question of what do you learn in an MBA that you can learn in a job? It is a great question. And at the time I had two recent MBA graduates from top programs working for me—and asking me to help them with their careers. It definitely makes you question if getting an MBA is really worth the time and money (or even more importantly the opportunity cost of doing something different). Regardless, it is still a question I consider and I may end up in one of those executive MBA programs in the not so distant future.
In the meantime though, I came across this web site: Personal MBA. It is a really cool site with member forums and book list, and it emphasizes the importance of self education. I have read a lot of the books already, but I have already ordered a few more off of Amazon.com to put in the giant stack of books next to my night stand (it is so tall now it moved off the night stand and onto the floor).
One of the most frustrating things is sitting in a poorly run meeting. It seems obvious of what makes a good meeting however I have sat through more poorly executed meetings, than good meetings. In the effort to make sure we use time as efficient as possible I came up with this blueprint that works well for meetings on my team.
Simple, no? Sometimes having a basic framework is helpful to get people in the right frame of mind. In addition this will make you look organized to show that you put some thought in ahead of time.
This is the start of my blog. Stay tuned….
