How do software engineers/devs/etc "stay in shape" for technical interviews? Let's say I wanna switch jobs and the first hurdle to cross is inevitably algorithms and data structures (for dev-centric roles) or something like operating systems/networks/whatever. How does one stay sharp on those _fundamental_ skills on a regular basis while working on a job, to avoid cramming everything in one week before the interview?
People suck at technical interviews
91–100 of 177 posts
Re: People suck at technical interviews
#92I'm not sure I agree with the "team fit" thing. I get his point - most people don't understand what team fit is or can't separate it from personal bias. But here's my counter-argument. Every company and team has different core values. "Team fit" means matching company and team values. For example, I work on educational software for teacher and students. My definition of "team fit" (for this particular team/company) i…
When I did it my top role was plant and the course leader assumed I worked at BT Labs which was flattering (US equivalent would be Bell Labs).
Re: People suck at technical interviews
#93Earlier quoted context omitted.
I'd probably fail that from lack of experience, but it does seem to be a great approach for someone a bit more seasoned. That shows a lot more about someone's software engineering capabilities than short tricky problems.
Some one more seasoned would not work for free at a weekend.
See, I can play that game too.
Besides, this was a contrived problem. If you want to say "I refuse to solve any coding problems while interviewing for a software position", then fair enough. Good luck finding one. I think this was a total of perhaps 3 hours of my time, and was good enough to get an onsite? And it was time I -enjoyed-. Unlike most phone screens, timed interviews, etc.
Re: People suck at technical interviews
#94Earlier quoted context omitted.
That kind of question can actually be useful as a proxy for experience with the language, and whether you're the type of person who digs into understanding your tools. If you say "I'm a rockstar Javascript dev", it's very hard to prove it; but if you've never been bitten by some of Javascript's type conversions, and/or have never really looked into some of its intricacies on your own, you probably aren't. It's just o…
I find it hard to believe anyone has spent a bunch of time writing js and never been bitten by a type conversion. Am I wildly off base? I do data science, but everyone who writes R has been bitten by it's scoping rules, which are definitely not mainstream. Everyone I know who writes java or python has been bitten at least once by the pass object references by value (is there a better name for this?) function argument…
Re: People suck at technical interviews
#95Instead of technical interviews, I would love to just pay a potentially great candidate to come in and work for the day. Not only would it give them an opportunity to demonstrate what they know and show off their other skills, it would give our team a chance to see if they're a good fit. And, there would be some real financial incentive for them to give us a try. But, trying to get management and HR to change from th…
The biggest problem with a "work there for a day" interview IMO is that there's no time to do anything useful. You can't get familiar with a codebase of any size in a day.
This works outside of programming. Over a decade ago when I was doing network stuff, I did "pair router work" with a couple people. You don't give a noob enable CLI on a production router on his first day, or during an interview, either. Even if on paper, or in reality, he is better at this than you are.
If you hire them, you'll be spending the first couple days like this, anyway, unless you go all sink or swim.
Re: People suck at technical interviews
#96This is a really excellent post. It talks about a bunch of things that are hobby-horses of mine (I help run recruiting for a large software security firm), and I find myself agreeing with more of it than I disagree with. I would go a little further than Laurie does. I think several of the goals he sets up for his process are not in reality achievable in an interview process. Starting axiom: job interviews are among t…
I take the opposite approach. I want you to succeed. I want you to be the best candidate I've seen so far. I want you to be awesome. In fact, I want to hire you right now and never have to do another interview again. I'm in your corner, and I'm rooting for you every step of the way. There's no need to be nervous -- just be yourself.
My explicit goal is to hire someone -- not reject a candidate. I have a high bar, yes, but I start off with the assumption that you can pass it, or I wouldn't have brought you into my office to begin with.
It may be semantics, though. Your implicit understanding is that the glass is half empty, and mine is that the glass is half-full. We're both measuring the glass to see how much is actually there, and if it's not half-full, then that's not good enough. But at the end of the day, I'm on your side.
Having said that, I come from an acting background. I understand how casting works. I'm a tall, dark, lean male that can appear anywhere between 25 and 45 years of age. When I go audition for a role, I'm competing against other tall, dark, lean males that can appear anywhere between 25 and 45 years of age. Depending on the number of other actors auditioning, it may simply be a crap shoot. It may simply be that we were all good in our own way, and they just went with THAT guy because he was the last one in the room, or because he wore that one funny shirt that made him stand out just a bit more.
When you come in for an interview, you're one of dozens of people we've phone screened, and you're one of a half-dozen people that we bring into the office. You've already made it past the first round. Now you're competing with the best of the best that we've talked to. If you don't get the job, it doesn't mean you suck, it simply means that we went with someone else. And if you do get the job, it may not necessarily mean that you're the best -- just that you're one of the best.
Kind of something to keep in mind here.
But again, at the end of the day, I'm rooting for you. I want you on my team, or I wouldn't have brought you into my office. Try to relax a bit, be yourself, and show me that I'm right. After all, I love being right. :)
Re: People suck at technical interviews
#97This is a really excellent post. It talks about a bunch of things that are hobby-horses of mine (I help run recruiting for a large software security firm), and I find myself agreeing with more of it than I disagree with. I would go a little further than Laurie does. I think several of the goals he sets up for his process are not in reality achievable in an interview process. Starting axiom: job interviews are among t…
> job interviews are among the most hostile experiences professionals endure in our industry I don't find being questioned during an interview hostile, although I do feel I need to be prepared to be tested. The most bothersome part for me is companies asking for me to list several references, often specifically asking for previous managers. I am usually given a standard application form to write their names, phone nu…
Re: People suck at technical interviews
#98Re: People suck at technical interviews
#99For my first job out of uni, I was asked to write pseudocode on a whiteboard to solve a simple scripting problem (call an executable repeatedly, changing the command line args). My background is nuclear engineering, and I was interviewing at a cloud/networking business, so I was already slightly outside my experience comfort zone[0]. I was explaining my thought process while writing on the whiteboard, trying my best…
Re: People suck at technical interviews
#100I disagree with author about coding question. In my experience if somebody is not able to code quickly a simple task (like fizzbuz, reverse a string), it's a terrible sign. It's a simple objective test that filter out a lot of candidates. Yeah they may be able to be productive in some specific environment (e.g. deep in some framework, writing templates), but in general they likely don't have solid programming foundat…
That is exactly the problem. Your experience is biased and by definition not transferable to hiring in general. This is why thousands of academic articles exist about research practices and good indicators for future performance, as tokenadult's post nicely highlights.