4 ms·
Interesting read. I don't know the author, but it seems he practiced a lot yet fumbled some. Which can be normal, as writing code in a whiteboard is just not
by ardit33 18y ago
Interesting read. I don't know the author, but it seems he practiced a lot yet fumbled some. Which can be normal, as writing code in a whiteboard is just not natural. To test raw coding skills, it would be a better idea to provide or have candidates come with a latop with their favorite dev enviroment/IDE/editors so they can code in a more realistic situation, the way they do every day.
It is always a good idea to get a good refresh of CS basics, and algorithms, and more advanced stuff as data graphs, but at the end of the day, (if the interviewers are good), your raw skills will show up. Just like math, skills are built in top of each-other and show with time, an you can advance more if you internalize low level abstractions (pointers, linked lists, hashtables, etc). You can't just pick a book and learn these things in few days.
But a 9.5 hrs interview is grueling and a tad exessive, also tells something about the company that you are joining. If they like interviews that long, means that have some huge bureocratic internal processes. Interviews by 3 technical people, and one manager/product manager should be more than enough to spot a good a candidate, within a 4hr time-frame.
Anymore than that, it is just a waste a time.
- rantfoil 18y ago9.5 hours is actually just thorough. Hiring is the #1 thing any engineering org has to do right. Remember, a false positive will cost you far more in dollars, time, and effort than a false negative. Microsoft is a huge company. The best thing it can do to improve its odds in the marketplace is to put enough process around hiring such that they can significantly reduce the false positive rate. I'd argue more people should do full day interviews than less. You wouldn't marry someone after knowing them for only 4 hours, so why should a company hire someone after getting to know them for less than a day? ;-)
- timr 18y agoYou wouldn't marry someone after 9.5 hours, either. The problem is, if you insisted that every first date lasted ten hours, you'd rarely get a second. The ones who did make it though your screen would probably be neurotic and weird.
- rantfoil 18y agoIf every first date lasted TEN HOURS. Well, if you're cooking breakfast in the morning, maybe a second date might be expected. ;-)
- ardit33 18y agoi hope you are not really equaling marriage and a job. The average person stays about 2 years in a job, and they go thru about 10.5 jobs before age of 40. Most people get married once or twice in their lifes, and expect their marriage to last forever. Nobody expects that from a job. You might want to equal getting a job with dating and sleeping with a new girl, but not getting married ;)
- timr 18y agoI'm not making the comparison. I'm making fun of it.
- rantfoil 18y agoWell, not quite. But who you get married to will determine a huge amount of how happy you are, possibly for the rest of your life if you're so lucky. =) Similarly, for a startup (or engineering team), each hiring decision is so important that in aggregate it will pretty much determine how happy/productive you are... and possibly in the case of a startup, for the rest of your life as well. The time scales may be different, but the impact is similar.
- babul 18y agoIf I was to work for a company, it would probably be one that had rigour in its employment practice. Those that hire carefully, fire carefully, and you can actually learn a lot about a company from the interview (as much as they can learn about you). If that takes a 9 hours or a 9 days, then so be it. At least then I'd know I would be working with people I can respect and learn from and would enjoy being around.
- pchristensen 18y agoExactly. A long, thorough hiring process is insurance that your future coworkers hired after you will be high quality.
- biohacker42 18y agoI am very skeptical about these interviews. All I am ever interested in is a code sample. That will answer all coding questions. It can not even be compared to forcing a nervous candidate to code by writing on a white board. It also can not be compared to a quiz on topics in programming. Get a code sample, read it, ask a few questions about it, that is all. As to if a person would "fit' on a team, it takes roughly 3 seconds to figure that out. So have each team member meet with the candidate for 1 minute, that's plenty of time. Then do a background check, call references and that's all there is to. Everything else is just smoke and mirrors BS. It selects for people good at interviewing, not good hackers. And lastly you can always fire people, if they lied about their code sample or whatever. So lets stop acting as if hiring someone is irreversible. In America at least, firing people is still easy. There's one thing to note about large companies. Large companies can't trust one good developer to evaluate a code sample. So that's bad, and they then fall back on a day long dog and pony show. And then they usually have huge, ugly, crufty code bases, that means that they can't even tell if someone is good or bad until AFTER they grok the code base. And groking the code base often takes a LONG time. So to pay someone for months only to then fire them and start again is expensive. And the moral of the story is: Stay away from big companies.