Candidates with active TS/SCI/Polygraph in the following areas and interested in joining Deloitte please send me a private message:
Financial Accounting, Systems Administrator, Software Engineer, Java Developer, Human Capital, Full-Stack Java Developer, Change Management, Business Intelligence Analysts, Oracle DBA’s, C++, JavaScript, Python, Data Analytics, Computer Forensics, Supply Chain, Workforce planning. I will refer you and send your resume directly to the Deloitte recruiter.
Go simple and flawless. If you go into rough waters unnecessarily, you're going to cause me a late night and extra turns unnecessarily when you're on my team.
You have to make a judgement call for the domain, fair. You should present the simplest possible approach that allows me to evaluate you for the position. For a statistical data scientist (versus computer visions or NLP), just show me a basic regression or time series projection and your interpretation of business implications.
For software engineering, show me something simple that elegantly addresses the ask, rather than flexing your knowledge of 387437 different styles and architectures.
It depends, it’s an interview!
If lower position - I like seeing the more difficult solution as that helps me understand they’ve got vision and a pulse on what is to come in the market.
If higher position - the more simple solution as people management comes into play. I’d expect them to explain why they turn down the more complex one.
I would rather someone walk through a flawless analysis but identifier where they would further develop it with something more advanced.
Mentor
Flawless analysis usually would require lots of domain knowledge. Unless this is a role requirement, such an expectation is usually unjustified.
Personally, I would rather look for the thought process and have a conversation around a project person has done- understand his/her decision drivers and technical understanding/complexity/coverage. Majority of personal DS projects these days are just copy paste and lack of understanding is clearly recognisable.
Bowl Leader
Define requirements, meet requirements with MVP, iterate MVPs to be better if there's time/money. If you can't meet long run requirements with MVPs, you don't have requirements defined correctly (ignoring scaling comes to mind)